red fire engine parked in the grass displaying the Idaho City logo on the door.

IFTDSS Background

The interagency Joint Fire Science Program (JFSP), through both formal and informal interactions with its partners and clients, became convinced in 2006 that one of the more pressing problems facing fire and fuels managers is the confusion and inefficiency associated with the many existing software systems intended to help fire and fuels managers. These systems have proliferated in the last decade in response to various funding initiatives without any central control or vision. Managers are left with an assortment of unconnected systems in various stages of development with little guidance concerning the strengths and weaknesses of the various systems, and no framework for integration and fusion of data and outputs from these systems. One of the principal voices articulating this problem has been the Fuels Management Committee. Acting in concert with the Fuels Management Committee, the JFSP initiated the Software Tools and Systems (STS) Study in 2017.

(read more/less)

In Phase I (April 2007- March 2008), we studied the problem identified by the fuels specialist user community - software chaos. In Phase II (April 2008 - March 2009), we developed a solution path - a conceptual design document, a software architecture design document, and the focus on building a service oriented architecture based, distributed framework named the Interagency Fuels Treatment Decision Support System (IFTDSS). In Phase III (April 2000 - May 2010), we implemented the proof of concept version of IFTDSS. All of the many varied products we have published along the way may be found on this web site. In particular, we call your attention to the JFSP Fire Science Digest dated December 2009 entitled "A Powerful New Planning Environment for Fuels Managers: The Interagency Fuels Treatment Decision Support System" (pdf).

It is absolutely critical to understand that IFTDSS is not another new fuels treatment system. It is a framework that organizes and makes available a large number of pre-existing software models. It provides access through the Internet and provides users with a single user interface to multiple software tools.

Phase IV began the full implementation of the software framework. IFTDSS version 1.0 (Jan. 2012) has been released. This version contains support for data preparation using LANDFIRE data, prescribed burn planning and analysis, preparing a prescribed burn plan and hazard analysis of current conditions for a user defined area of interest. The next version, 1.2, is scheduled for March/April 2012 and will add a risk assessment workflow for current condition data.

Phase I: Strategic Analysis of Problem (2007-2008)

The Joint Fire Science Program (JFSP) Governing Board became convinced that one of the most pressing problems existing in the field of fire and fuels management from an interagency perspective is the confusion and uncertainty around the many existing software systems. This conclusion was reached in 2006, as a result of numerous "user sensing" activities conducted by members of the JFSP. In 2007, the JFSP organized a project entitled "The Software Tools and Systems Study" and contracted with the Carnegie Mellon Software Engineering Institute (SEI) to perform a strategic analysis of this problem. The strategic analysis was completed in March 2008 and the SEI submitted a written report to the JFSP [Palmquist, 2008 (pdf)]. One of the key SEI findings that addressed the plethora of software tools and systems was, "The wildland fire and fuels management community needs a platform and approach that supports distributed collaboration."

(read more/less)

"Because of the variety of operational contexts, it is impossible to centrally predict or resource the exact sets of models, tools, or data sets needed for each situation. This requires collaborative tools supporting net-enabled methods of analysis. This flexible and extendable integration framework (what we call framework architectures) will allow tool developers or sophisticated users to rapidly configure, calibrate, or extend Web-enabled capabilities to meet needs of a specific operational situation" [Palmquist, 2008 14 (pdf)].

The SEI team identified three types of Framework Architectures [Palmquist, 2008 17-26 (pdf)]:

  • Type I - typified by service-oriented architecture (SOA) infrastructure providing services (i.e. functions) with well-defined behaviors such as on-line banking systems. Users have no say in the type of services offered or in the way solution processes are configured.
  • Type II - typified by allowing users to customize services in a finite number of commonly understood ways based on shared, community-wide assumptions about what is needed.
  • Type III - typified by supporting the customization of services by users for specific, unique operational situations that may or may not be shared, community-wide ways of solving a particular problem.

Type III architectures were identified by the SEI strategic assessment as the key tools to adequately address the fuels software systems management problem.

The SEI identified the BlueSky architectural framework as a leading example of modularizing and connecting scientific models and a likely candidate for creation of a web-based, Type III collaborative architecture system [Palmquist, 2008 (pdf)].

Based on this result, the JFSP funded a proposal submitted by the BlueSky lead scientist, Dr. Sim Larkin entitled "Conversion of BlueSky Framework into collaborative web service architecture and creation of smoke modeling application" [Larkin, 2008 (pdf)]. The starting date for this project was June 2008 and the projected end date is May 2009. Larkin enumerated specific advantages of collaborative architecture systems (CSA):

  • The development of scientific models is separated from user interfaces (UI's).
  • UI's are integrated and capable of driving multiple models.
  • Faster development of models and UI's is possible.
  • Direct comparison between similar models is supported.
  • Faster transition between developed models and operational applications is possible.

The question still remained whether the BlueSky approach to collaborative system architecture (CSA) was sufficiently generic to support the development of software solutions outside the smoke management domain. The JFSP Board decided to focus Phase II of the Software Tools and Systems Study on resolving this question.

tree branches fully engulfed in flame.

Phase II: Designing the Solution Process (2008-2009)

Phase I of the JFSP Software Tools and Systems (STS) study ended in March 2008. The contractors for Phase I, members of the Software Engineering Institute of Carnegie Mellon University, completed a report which represented a strategic analysis of the problem: fire and fuels managers are faced with an assortment of unconnected software systems in various stages of development with little guidance on how and when to use them and no framework for integration and fusion of data and outputs. The JFSP came to understand through its interactions with SEI that a platform that supports distributed collaboration includes certain key components:

  • A software framework architecture that facilitates use and integration of data and scientific models, including a common user interface and shared data structures
  • The flexibility for users to select and compose their own data and chain of models to help solve their own specific problems
  • A clearly articulated set of standards so that software developers can develop models and modules that will function within the software framework architecture
  • A lifecycle management system with processes to set priorities for software system development, training, and retirement

(read more/less)

Mike Rauscher, the project manager of the STS study for JFSP, was engaged in April 2008 to manage Phase II. The primary objective of Phase II was to design a collaborative system software architecture that could be used to Pilot Test the effectiveness of the strategic elements identified above. The Fuels Management Committee identified the fuels treatment analysis and planning problem as the management concern of highest priority for the STS Pilot Test. A new contractor, Sonoma Technology Inc. (STI) based in Petaluma, CA, was engaged to perform the architectural design and began work in July 2008. Tami Funk was assigned project manager for the STI part of the study. A 12 member advisory board, consisting of representatives from research and management across DOI agencies and the USDA Forest Service, was convened to help guide Phase II.

Progress in Phase II has been rapid as can be seen by viewing the Timeline of Major Accomplishments (see below) and the Goals of the IFTDSS Project
Work in Phase II has been organized into three elements:

  • Design and Test a Software Life Cycle Process
    • Design and test a Software Life Cycle Process that all communities (Fire Directors and Staff; scientists, system developers, and science administrators; and system users and fire/fuels managers) can support. Ideas on how to move forward in this element are still evolving as of February 2009. Current thinking is that the IFTDSS Phase III prototype project will be used as the concrete test case for the NWCG IT Investment Management Process.

A briefing concluding Phase II of the STS Study was given to the Joint Fire Science Board on March 31, 2009 in Boise, ID. The annotated powerpoint presentation used for that briefing is provided. The Development of an Interagency Fuels Treatment Decision Support System

  • Phase II Timeline of Major Accomplishments
    • May 2008 Phase II project meeting with Advisory Board in Boise, ID held to plan how to complete objectives. Michele Tae was engaged as a contractor to help put together the Conceptual Design Document for the IFTDSS.
    • July 2008 Sonoma Technology Inc. (STI) came on contract.
    • August 2008 Publication of the Interagency Fuels Treatment Decision Support System (IFTDSS) Conceptual Design document. Reviewed by fire and fuels managers and scientists, August - November 2008. Review comments consolidated and returned to reviewers as a response to their ideas, January 2009. Final revised document completed, January 2009.
    • July - November 2008 Conducted an email based survey of fuels treatment field specialists to assemble a list of currently used software support tools for fuels treatment analysis and planning. Survey completed and results published with 49 respondents covering all agencies and all geographic sections of the United States. Results will be communicated back to this group in January 2009 and they will be asked to participate in Phase III of this study and function as the representatives of the target audience to test and guide the development of the IFTDSS.
    • October 2008 completed an analysis of the data issues which surround the development and use of the IFTDSS. A data issues summary for public consumption and consideration is available. STI completed a review of the existing software systems and summarized their findings in a document entitled "Findings of the Current Practices and Needs Assessment for the IFTDSS Project."
    • November 2008 STI completed a review of existing collaborative platform frameworks in order to understand what has been done and how it has been done. STI summarized their findings in a document entitled "The Application of Service Oriented Architectures in the Fuels Treatment Community."
    • December 2008 Second and last Phase II project meeting in Boise, ID. STI presented their findings and the implications of those findings for the design process of the IFTDSS. The Advisory Board approved of the plans for finishing Phase II on time in March 2009.
    • January - February 2009 The IFTDSS architectural design will be crafted.
    • March 2009 The IFTDSS design document will be completed and the Phase II project will be reported at a Joint meeting of the JFSP Board and the NWCG in Boise ID the last week of March. This accomplishment will mark the end of Phase II activities.
firefighters in helmets and yellows hiking across a meadow

Phase III: Implementation of a Proof-of-Concept Version of IFTDSS (2009 - 2010)

Phase II of the JFSP Software and Tools Systems study ended in March 2009 with a strategic level architecture design document for the proposed Interagency Fuels Treatment Decision Support System (IFTDSS). JFSP subsequently decided to fund the development of a proof of concept (POC) version of the IFTDSS to ensure technical feasibility and test early adoption by users. Sonoma Technology Inc. was awarded the contract for implementing Phase III. Tami Funk is the STI Project Manager and Mike Rauscher was retained as JFSP Project Manager.

(read more/less)

Phase III consists of the following tasks:

Task 1 - Project Planning:

Task 1 involved scoping and planning for the IFTDSS software development effort. Planning activities included assembling the project team, scoping out and scheduling the work to be performed in Tasks 2 through 6, and preparing a project plan.

Task 2 - Confirm the Functionality of the Proposed IFTDSS POC and Continued Engagement with the POC User Test Group:

Task 2 involved confirming the proposed functionality of the IFTDSS POC and the workflow scenarios that it will address with field practitioners. This involved assembling a group of fuels treatment specialists and soliciting their review and input on the use cases and the functionality proposed for the POC. Based on feedback provided, we refined the conceptual design of the POC and prepared a report discussing the revised proposed POC specifications, workflow scenarios, and specific questions/functions that the system will address.

Task 3 - Develop the user interface design, and web-based graphical user interface mock-ups and the IFTDSS POC design specification:

Prior to implementing the IFTDSS POC, a software system design specification document was developed. The design specification document is based on the strategic architecture design produced in Phase II of the STS Study. The IFTDSS POC design specification includes detailed technical specifications that will be followed during implementation, including the back-end system design and the graphical user interface design. The graphical user interface will be designed and developed in parallel with the IFTDSS POC system. As web-based user interface mock-ups are developed, they are shared with the user community for review and feedback in parallel with the development of the IFTDSS back-end system. The web-based GUI will serve as a development platform and as a mechanism to engage the user community early.

Task 4 - Implementation of the IFTDSS POC:

Upon acceptance of the design specification document (Task 3), STI will implement the IFTDSS POC. We propose to use a phased, rapid-POC approach during application development. Conceptually, rapid-prototyping involves dividing the system implementation into discrete elements so that individual processes and/or modules can be developed, rapidly tested, and refined during the implementation process. When a process or module is acceptably functional, it can then be connected to its neighboring processes. The benefit of rapid-prototyping is that individual system components can be made accessible and tested during early development to ensure that the components are functioning properly from technical and user perspectives. At the onset of implementation, a small group of fuels treatment specialists will be identified and asked to periodically review system components throughout the implementation phase.

Task 5 - Testing and Quality Assurance of the IFTDSS POC:

Upon completion of the IFTDSS POC development, STI perform in-house unit and system quality assurance and software testing. Following the in-house testing, STI will make the system available via the Internet to a group of fuels treatment specialists who will test and provide feedback on system performance and/or possible refinements to the system.

Task 6 - Document the IFTDSS POC System:

In parallel with the implementation of the IFTDSS POC system, user documentation and help pages and technical system documentation will be developed.

Task 7 - User Community Development:

It is axiomatic that a large, multi-faceted software product such as the IFTDSS can only be used effectively if a well organized community of interested stakeholders exists. During Phase II of the STS Study, five stakeholder groups were identified: 1) the Governance community, 2) the Developer/Database community, 3) the Field User community, 4) the IT and System Maintenance community, and 5) the System Transition community. During Phase III, we will further define the five communities of stakeholders, describe the roles that members of each community should play, and form a core group of stakeholder participants that will actually perform these roles as they interact with developing the IFTDSS POC system.

Phase IV: Implementing the Fully Functional IFTDSS (2010 - 2012)

In June 2010, the Joint Fire Science Program Board authorized a new 2 year contract to expand the proof-of-concept version of IFTDSS produced in Phase III of the project to the full functionality envisioned in the Conceptual Design (pdf) document. Sonoma Technology Inc. was awarded the Phase IV contract and Tami Funk continued as the STI project manager. John Cissel is the Project Manager, Becky Jenison is the Contracting Officer's Representative, Erik Christiansen is the Business Steward, and Mike Rauscher is the Application Steward.

(read more/less)

Phase IV consists of the following Tasks:

Task 1 - Project Planning:

Planning activities include organizing the project team, scoping out and scheduling the work to be performed, and preparing a project plan.

Task 2 - Stakeholder Interaction and Community Development:

A large, multi-faceted software product such as IFTDSS can only be used effectively if a well organized community of stakeholders exists to both use and contribute to the improvement of the tool. To keep IFTDSS improving over time, updates of existing modules and entirely new software applications need to be incorporated into IFTDSS. We developed a Developer's Guide to explain precisely how science software developers can modify existing code or build new code to directly link into the IFTDSS framework system. A detailed evaluation of all aspects of the IFTDSS project will be reported on in Phase V.

Task 3 - Software Implementation:

As of October 2012, IFTDSS version 2.0 has been available for examination, testing, and evaluation.

  • Task Three Deliverable
    • IFTDSS 2.0

Task 4 - Software evaluation and accreditation:

IFTDSS is organized around 6 major problem solving functions called workflows. These workflows are: data acquisition and preparation, prescribed burn analysis and planning, current condition wildfire hazard assessment, spatially explicit placement of fuels treatment, evaluating fuels treatment effectiveness over time, and risk assessment.

Task 5 - Software Documentation:

The IFTDSS software tool has an internal, online user help documentation. A getting started video and the online help system may be accessed by going to the IFTDSS software application homepage.

  • Task Five Deliverable
    • IFTDSS Online Help Documentation
sunset across a smoke filled sky with trees visible in the forefront

Phase V: Evaluating the IFTDSS project and software implementation (2012 – 2013)

On April 23, 2012 an interagency group of individuals organized by Jim Douglas, representing the DOI agencies, and John Phipps, representing the USDA Forest Service, met in Boise, ID to review the status and future plans for the Interagency Fuels Treatment Decision Support System (IFTDSS). It was decided that IFTDSS V 2.0 needs to be completed and further development work funded by the JFSP should stop. An independent evaluation of IFTDSS should be performed. The IFTDSS service integration framework should proceed through the newly created software acceptance process of the interagency Wildland Fire Information and Technology (WFI T) program.

(read more/less)

The IFTDSS version 2.0 service integration framework web-application was completed in October 2012. This internet link brings users to the IFTDSS home page. From the home page, users can (1) sign in if they already have an account (2) request an account for a new user (3) view an introductory video of how to use IFTDSS and (4) view the detailed online help for IFTDSS. On the home page, viewers will also find a succinct explanation of what IFTDSS is and information on the latest functional capabilities. For the time being, no further IFTDSS development work will be funded by JFSP. A project ending final report was written and contains a detailed description of IFTDSS V 2.0 (Haste et al., 2012)

Also in 2012, the JFSP engaged the Software Engineering Institute (SEI), a Federally Funded Research and Development Center (FFRDC) operated by Carnegie Mellon University to perform an independent evaluation of how well the IFTDSS service integration framework succeeded in addressing the "software chaos" problem. After an extensive evaluation, the SEI concluded that IFTDSS (1) significantly improves the quality and efficiency of the fuels treatment planning process for the majority of user needs; (2) provides a concrete demonstration of one way to implement the four key WFI T solution concepts above; (3) enables standardized, risk-based fuels management planning for a large part of the fuels specialist community; and (4) is near-ready for operational use. The evaluation concluded that if fielded as part of a comprehensive governance strategy, IFTDSS can be a major step in bringing order to the “software chaos” problem (Bennett et at.,)

An interagency analysis and review of the current state of information technology investments, governance, and capabilities in the wildland fire programs of the four Interior fire bureaus and the USDA Forest Service was conducted in order to provide a sound information base for designing a plan to implement the broad strategic recommendations of the NWCG NWFEA Modernization Blueprint. This review provided another independent confirmation that the “software chaos” problem identified earlier by the JFSP existed and that it was indeed a serious and growing concern to senior leaders of the Forest Service and the DOI. The interagency action plan entitled "Wildland Fire Information and Technology: strategy, governance, and investments" appeared a year later . The recommended solution strategy of the WFI T strategy closely mirrors the solution strategy of the IFTDSS project: web-based SOA approach as the enabling software technology; computer platform independence; available to users regardless of location or agency; integrated data environment; software modules linked in a framework as services; sharing of work between users; mission requirements drive the application; services organized to reduce workflow complexity to users; and research and innovation focused on enhancing business mission accomplishment.

The intent of these actions was to have a comprehensive assessment of the effectiveness of IFTDSS V 2.0 and the implications of deployment for operational use by June 30, 2013 so that an informed decision can be made by the WFI T interagency leadership board regarding operations and maintenance and future improvements of IFTDSS. Should the WFI T interagency leadership board decide to operationalize IFTDSS, JFSP will assist in every way possible, including funding research to address specific science needs to support continued improvements to the science underlying the software.

A final report was written to complete the public documentation of the JFSP funded Software Tools and Systems study and the IFTDSS software. The objectives of this final report are to (1) describe the existing "software chaos" problem in the business mission of wildland fire and fuels management in the land management federal agencies of the United States; (2) describe the design of the solution the Joint Fire Science Software Tools and Systems study produced to ameliorate the "software chaos" problem; (3) present the IFTDSS service integration framework software architecture and functionality; and (4) discuss the results of an independent evaluation of the IFTDSS software in addressing the "software chaos" problem.