National Wildfire Coordinating Group (NWCG)
Equipment and Technology Branch
Information Technology Committee (ITC)

About Us

iRWIn - Data Centralization/Warehouse Description:

The Data Centralization/Warehouse (DCW) is an architecture model that provides for both data storage and for the flow of data from existing Systems of Record to other decision support environments. The DCW provides the means to load, retrieve, and manipulate both data and metadata and to manage a data dictionary. Since all the data is in one place, the DCW implicitly supports the use of business intelligence tools that facilitate reporting and analysis.

In the assumed implementation, the DCW does not subsume existing Systems of Record operational databases. However, the DCW would become the preeminent Authoritative Data Source (ADS) for wildfire reporting by mirroring the data base contents of all of the local ADS providing Systems of Record.

The DCW consists of the physical infrastructure and hardware that stores the electronic data along with the software that organizes and processes that data. The DCW is an “Off line Data Warehouse” in that it requires a deliberate push/pull to receive data from the Systems of Record. The DCW stores the data in a data structure designed to facilitate reporting. Operational data storage remains with the Systems of Record.

DCW architecture based on a top-down design approach using normalized data structures. In a top-down design, data is stored at the lowest level of detail in the data warehouse. The DCW organizes data so that all the data elements relating to the same real-world event or object will link together. The DCW tracks and records changes to the data so that it can produce reports showing changes over time. The DCW does not over-write or delete data. Once committed, the data is static, read-only, and retained for future reporting.

The DCW obtains data from all the Systems of Record. The DCW uses a set of database normalization rules. The normalization process organizes the data storage and makes the data consistent by applying conformance rules. The normalization and conformance process permits other applications that “know the rules” to pull data from the warehouse.

The DCW can make data required by a specific System of Record separately available through a structure called a Dimensional Data Mart. The Dimensional Data Mart structure holds only the data used by a particular application, its dimension. This helps speed the delivery of time sensitive data to Dispatchers and other Wildland fire stakeholders requiring information for decision-making or reporting.

The DCW links to each System of Record through an operational database access layer. The operational database access layer is one or more layers of software code that extracts, transforms, and loads (ETL) data into the DCW from the System of Record. The access layer is implementation specific. It could be as simple as an additional output device and format line for a System of Record “write” command, or it could require deeper coding and access to the System of Record operational database.

A Metadata layer creates detailed data directories for the entire DCW and for the System of Record specific Dimensional Data Marts. The DCW can support additional information access layers for business intelligence, enterprise reporting, or data analysis. The DCW builds these layers through three software development efforts broadly defined as ETL, DCW frontend, and reporting tools.

Under the iRWIn DCW, the existing Systems of Record will retain their operational databases, data entry, and reporting functionalities. The DCW provides for a push/pull data transfer scheme that could be fully automated or occur at the discretion of the System operator or Dispatcher. Hence, the individual Systems of Record and applications may require modifications to their look and feel representing the implementation specific data transfer functions.

When a Dispatcher initiates a fire-reporting event, their CAD interface will appear unchanged from its pre-iRWIn legacy configuration with the exception of these added functions. Upon updating the user interface screen or page, the Dispatcher may need to execute an additional send function. Depending on the particular application, the DCW may be able to co-opt an existing data entry keystroke or internal command as the send function. This action transmits the completed data record, via the CAD integration server if CAD initiated, to the DCW for assimilation.

The legacy data record, stored in the System of Record operational database will remain unchanged. The DCW front-end’s normalization rules will process the new data and execute the conformance rules. The data submitted is serially stored. Serial storage facilitates the subsequent time-line reporting of events.

When Dispatchers or other users thereafter report or query to a wildfire event, they will be able to request any previous remotely reported authoritative data elements from the DCW via their existing interface. The DCW will receive the request and reply per its Business Rules with the most recent and authoritative data available. The DCW sends and receives data fields when a user requests or submits or at predefined alert thresholds or time settings.

The DCW is a hub and spoke configuration that offers no additional connectivity among Systems of Record beyond the consolidation and redistribution of submitted data records. Legacy Systems of Record, when disconnected from the DCW, operate as before. Unsent database updates remain in queue. Major changes to Systems of Record may affect the DCW to varying degrees depending on the implementation and system. The DCW serves as the single authoritative data source, helps populate “boiler-plate” reports, and eases the production of enterprise level analysis.

back to the top

Advantages/Disadvantages:

1. System Scalability and Performance – The DCW possesses a highly scalable hardware infrastructure. Because it operates under a push/pull customer driven concept, there may be the need for operator action to retrieve the most recent data. The DCW uses traditional hub-and-spoke, integration-broker technologies that can rely on intermittent “burst” communications.
2. Capability Development - The DCW uses Commercial off the Shelf (COTS) hardware and database management software. COTS business intelligence or other enterprise analysis and reporting software packages easily integrate into the COTS database management backbone. However, all Systems of Record will require tailored coding to interface with the DCW. The payoff from the data consolidation of a properly architected DCW comes from the relative ease with which the DCW provides for enterprise level reporting and data standardization.
3. Computer and Network Management - The DCW uses an Ethernet like connectivity to provide permanent data storage, data standardization, and enterprise reporting capabilities. The DCW provides a permanent backup to Systems of Record and ensures data integrity through robust standardization and normalization rules. The DCW can serve as the Authoritative Data Source and primary System of Record for network consolidation. The use of a Dimensional Data Mart structure provides both an operationally useful data backup and a path to network consolidation.
4. Standards, Laws, and Degree of Government Regulation Compliance – The DCW does not initially support the Service Oriented Architecture goals of the National Wildland Fire Enterprise Architecture (NWFEA), but provides opportunities for system consolidation and the evolution of abstraction layers towards service bus architectures. Properly implemented, the DCW allows for movement towards a SOA and the creation of a single architecture.
5. IT Security – The DCW supports consolidated access and identity management technologies. The database administrators can fully encrypt the contents of all or part of the DCW. As an independent physical entity, this solution directly provides for the physical security of the data warehouse.
6. Data and Database Management - In the DCW, data management is a primary mission. The DCW takes ownership, normalizes, and makes available the "single version of the truth" authoritative data. However, opportunities for concern remain. For example, suppose that a CAD unit forwards data to the CAD integration server. Then this central CAD sends the forwarded data on to the DCW. If the DCW receives updated information from a non-CAD System of Record and forwards it to the CAD Integration Server at the same time a local CAD is updating information, then there could be an overlap of authoritative updates. The DCW implementation or CAD integration server must be robust enough to sort out any redundant reporting.

The DCW provides for a broad spectrum of implementation options and schedules. One can connect applications and systems serially or in parallel. The use of commercial communications and the pay for what you use severability means there is no single compelling implementation approach. While opportunities for consolidation of operational databases into the DCW are obvious, the program office must balance the risk of making the DCW a single point of failure against the desire to reduce costs and redundancy enterprise-wide.

[print - iRWIn - Data Centralization/Warehouse Description (PDF FILE)]

iRWIn 5 Minute Presentation

iRWIn (Integrated Reporting of Wildland-Fire Information) is an NWCG sponsored project to develop an “end–to–end” fire reporting capability that provides an integrated and coordinated process for collecting and reporting incident/event data.

In today’s environment, data is input into many unique systems. Often, basic fire information like location, size, environmental conditions, and resources are repeatedly input into these stand-alone systems as a foundation for their capabilities. As conditions change over the life of an incident, more timely and accurate information is input into operational systems, while the original, outdated data remains in the supporting systems.

An example is location of a fire (latitude/longitude). A 2008 interagency efficiency report identified that an interagency dispatcher may have to enter this piece of data in up to 26 different systems. Once they have received what they need from each system, they do not go back and update each system when better info becomes available.

When questions arise about individual fires or national views, there are often multiple answers depending upon where one goes for the answer. While all of the answers may be valid in their specific context, we presently cannot give a single, authoritative answer without accessing multiple systems and declaring caveats as to the timeliness and accuracy of the data. This presents a challenge for both the interagency fire community and line management at all levels of our agencies and departments.

By interconnecting these systems, new and updated information would automatically propagate to the different interagency systems. For some systems, we anticipate that data will be pre-populated and validated instead of manually being re-input.

Goals of the iRWIn capability:

• Allow consistent reporting of data
• Reduce, if not eliminate, the duplicate entry of data
• Speed access to data located in diverse source systems
• Increase data accuracy
• Increase the availability of data and,
• Identify authoritative sources

Presently, we have identified 13 primary systems, and 9 secondary systems as candidates for interconnection. These systems include: Computer Aided Dispatch, decision support, incident management, financial management, situation analysis, weather, public information, and final fire reporting.

The internal customers to these systems include: fire management and operations, fiscal managers, line officers, resource specialists, researchers, and planners. The external customers include: affected and/or interested public; local, county, and state governments; other Departments and federal agencies; international parties; Congress; and the Administration.

We want to provide a scalable capability to interconnect existing and future interagency systems, not create a new, single, monolithic system to replace all existing systems. Some of the existing systems are technologically capable of interconnecting today, while others (like our current Computer Aided Dispatch system – WildCAD), will need a technological refresh.
iRWIn is envisioned to provide both the capability for our interagency systems to interconnect and the ability for some of our systems to mature.

Where we are today: A high level business case, including a cost/benefit analysis, was completed September 2009. The business case has been re-introduced into the interagency IT Investment process for consideration, and the Data Warehouse alternative has been selected as the preferred alternative.

The NWCG recognizes that selection of an alternative is approval of an overall architectural concept (a Data Warehouse in this case), and that actual implementation will also leverage existing investments already made by the interagency partners. This hybridization will enable the iRWIn project to take the best capabilities of existing efforts (e.g. existing Data Warehouse, Enterprise Service Bus, and LANDFIRE Web Services) and efficiently meet the needs of the interagency fire community.

Are there any questions about the iRWIn project?

Background info:

Alternatives analyzed included:

1. Current condition
2. Federated Query with Enterprise Service Bus
3. Data Warehouse
4. Web Services without Enterprise Service Bus

Primary Systems: FS Data Warehouse, FireCode, FIRESTAT, FMIS, InciWeb, I-Suite, LandFire, ROMAN, ROSS, Sit 209, WFDSS, WFMI, WildCAD, and WIMS
Secondary Systems: ASCADS, FACTS, FBMS, IBDB, ICBS, IQCS, NFPORS, WFAS

[print - iRWIn 5 Minute Presentation (pdf file)]

back to the top