Design Features behind Success of the Ecosystem Management Decision Support System and Future Development

Abstract

The Ecosystem Management Decision Support (EMDS) system is an application framework for designing and implementing spatially enabled knowledge-based decision support systems for environmental analysis and planning at any geographic scale(s). The system integrates state-of-the-art geographic information system, as well as knowledge-based reasoning and decision modeling, technologies to provide decision support for the adaptive management process of ecosystem management. It integrates a logic engine to perform landscape evaluations, and a decision engine for developing management priorities. The logic component: (1) reasons about large, abstract, multi-faceted ecosystem management problems; (2) performs useful evaluations with incomplete information; (3) evaluates the influence of missing information, and (4) determines priorities for missing information. The planning component determines priorities for management activities, taking into account not only ecosystem condition, but also criteria that account for logistical concerns of potential management actions. Both components include intuitive diagnostic features that facilitate communicating modeling results to a broad audience. Features of the system design that have figured in its success over the past 20 years are highlighted, together with design features planned for the next several versions needed to provide spatial decision support for adaptive management under climate change.

1. Introduction

The Ecosystem Management Decision Support (EMDS) system is an application framework for constructing decision-support systems (DSS) [1] for integrated, multi-scale environmental analysis and planning (http://emds.mvbg.org). It supports landscape‑level analyses through logic and decision engines integrated with the ArcGIS^® 10.2 geographic information system (GIS, Environmental Systems Research Institute, Redlands, CA, USA). The logic engine evaluates landscape data against a logic model designed in the NetWeaver Developer^® system [2] to derive logic-based interpretations of complex ecosystem conditions such as watershed condition, wildfire potential, and landscape integrity. (The use of trade or firm names in this publication is for reader information and does not imply endorsement by the US Department of Agriculture of any product or service). Logic modeling in this context refers to a form of knowledge-based reasoning in which expert or tacit knowledge is used to construct a representation of how to think about and solve a problem [3]. In the EMDS context, in particular, logic is used to reason about the meaning of environmental states (e.g., given the observed data on a watershed, what can we infer about watershed condition with respect to providing suitable habiat for aquatic species?). The decision engine evaluates outcomes from the logic model, together with additional management-oriented data related to environmental consequences, feasibility, efficacy, performance and opportunities, against a decision model for prioritizing landscape treatments. EMDS decision models are built with Criterium DecisionPlus^® (CDP, InfoHarvest, Seattle, WA, USA), which implements the Analytical Hierarchy Process (AHP; [4]), the Simple Multi-Attribute Rating Technique (SMART; [5]), or their combination. The AHP belongs to the general class of multi-criteria decision models (MCDMs) [6], while SMART derives from the closely related field of multi-attribute utility theory (MAUT) [7]. Engines that implement MCDM solutions in particular have become increasingly common in contemporary DSS architectures for environmental decision support, beginning about 1995, either as stand-alone MCDM solutions or as MCDM components of larger systems such as EMDS. In contrast, the use of logic engines in environmental decision support is far less common in contemporary systems. However, logic processing has remained at the core of EMDS functionality since 1995 because of its capability to model the relatively large, complex, and often abstract problems associated with decision support for ecosystem management and adaptive management [8].

As background on applications of EMDS in environmental analysis and planning, the recent volume on EMDS by Reynolds et al. [8] presents a set of nine case studies, spanning a range of application areas, including watershed analysis [9], forest restoration [10,11], managing wildfire hazard [12], ecological reserve planning [13], forest conservation planning [14], wildlife habitat management [15], urban growth and industrial development [16], and biological sustainability of salmon [17]. In submitting chapters for the volume [8], the editors asked authors to address to questions, based on their experience with applying EMDS in their problem area: (1) in what sense(s) did the system work well in addressing the problem, and (2) in what ways could EMDS be improved to better support the analysis. Answers to the first question are a primary source for Section 3, below, while answers to the second question were used by Reynolds et al. [18] to assess how well the new versions of EMDS would address user requests for system enhancements as described in Section 5, Section 6 and Section 7, below (see next paragraph). The basic conclusion from this analysis was that the forthcoming capabilities planned for the next versions of EMDS addressed virtually all of the user requests suggested in the case studies.

In the next three sections, we present a brief history of EMDS in Section 2, and discuss elements of its design that have accounted for success of the system over nearly 20 years in Section 3, and a few key experiences with its design and use in Section 4. Section 5, Section 6 and Section 7 then look at features of EMDS Version 5 and beyond (5+), beginning with a less technical overview in Section 5, and followed by a more technical discussion of design objectives in Section 6, and system architecture in Section 7. In Section 8, we conclude with some implications for delivering decision support for adaptive management under climate change.

2. History of EMDS

EMDS was initially developed by the Pacific Northwest Research Station (US Department of Agriculture, Forest Service). System design was initiated in 1994, and implementation began in 1995. Through Version 3 (2002), the system was implemented by the Environmental Systems Research Institute (ESRI) under federal government contract. Since 2005, EMDS development has been directed by a private, non-profit development consortium. The current version (4.3) was released in September 2014. Since its initial production release in 1997, numerous applications have been developed, spanning a broad array of topic areas, spatial scales, and geographic context (for a fairly comprehensive compilation of published accounts see [19]). Reynolds et al. [8] recently published the first comprehensive reference work on EMDS, covering its conceptual and technical foundations, case studies spanning the array of application areas to which the system has been applied over the years, and a detailed look at design specifications for the next few generations of the system [20].

3. Success factors behind EMDS

The following five factors have been critical in the success of the EMDS system, and deserve careful consideration in the design of decision-support systems for natural resource management in general. The following characterization of success factors behind EMDS is primarily drawn from the nine case studies discussed in Section 1.

3.1. Generality

EMDS is a framework within which developers can design applications that implement logic and decision models to address many different kinds of questions related to natural resource management, and at whatever spatial scale(s) may be relevant to associated questions. Because of its implementation as a general framework, EMDS has been used in numerous natural resource applications around the world since 1997, as noted in the previous section. The design of EMDS as a general solution framework accounts for much of the success of the system since its introduction in 1997 in terms of the number and diversity of applications as documented at [19].

3.2. Transparency

Rational and repeatable processes are part of an essential foundation for effective decision support, but are not sufficient by themselves in terms of achieving maximum effectiveness. EMDS design also has placed a premium on transparency from the beginning, and this, we would argue, has been another key ingredient in the relative success of the system as a tool for decision support. Transparency has two important dimensions. First, models should be fully self-documenting in terms of revealing data limitations, underlying assumptions, particulars of model constructs, etc., and this information should be fully accessible to users via the system interface. Second, and at least as important, the engines (e.g., logic and decision processors in the case of EMDS) should be able to fully explain the derivation of answers in an intuitive user interface so results can be effectively transmitted to stakeholders who may have limited technical expertise in the subject area. As an example, EMDS solutions have been used to address important national issues in the US precisely because senior agency officials were able to effectively communicate results to Congress or federal oversight agencies.

3.3. Simplification

The logic and decision models in an EMDS application complement one another. A logic model focuses on the question, “What is the state of the system?”, whereas a decision model focuses on the question, “Given the state of the system, what can be done about it?” Logistical issues of significance to managers are not pertinent to the first question, but they are very important to the second. One consequence of separating the overall modeling problem in EMDS into two complementary models has been that each model is rendered conceptually simpler. The logic model only evaluates the status of landscape attributes, whereas the decision model primarily considers attributes of special interest to resource managers. In addition, a logic model can be used as a preprocessor to a decision model, better handling some of the abstractions and complexities of modern natural resource decision support in the process, and as discussed more next.

3.4. Abstraction and Complexity

Logic-based approaches to environmental analyses have proven useful in EMDS for accommodating the levels of abstraction and complexity commonly encountered in contemporary decision support contexts. Abstraction is an issue even in problems that are predominantly biophysical in nature. For example, watershed analysis, wildfire potential, and landscape integrity are all examples of decision-support topics that are both inherently abstract and complex, but essentially biophysical in scope. The application of logic to such problems has been at least reasonably successful in EMDS because the only key limitation to use of logic is that one must be able to reason about solutions in terms of chains of conclusions and underlying premises. The case for logic-based solutions becomes, if anything, still more compelling when the complexity of the problem increases with the need for integrated analyses spanning biophysical, social, and economic dimensions.

3.5. Spatial Scales

Many, and perhaps most, contemporary decision problems in natural resource management cannot be adequately addressed at a single spatial scale. For example, watershed analysis may require analysis of both stream segments within watersheds and watersheds per se [21]. Similarly, a national forest-fuels analysis may require analysis of forest units and regions [22]. Other types of problems may suggest the need for three, or even more, scales of analyses that need to be integrated across spatial scales. EMDS projects support multi-scale analyses to the extent that multiple scales of analysis can be accommodated within a single project, but this functionality could be developed further because currently it is left to the user to manage integration across scales. However, it is not difficult to conceive of a wizard feature that could assist with scale integration.

4. Experiences in Design and Use

At Version 4.3, EMDS is a fully operational decision-support framework for environmental analysis and planning, but, by design, it remains a work in progress. The original vision for the system was that it ultimately should provide complete support for the full adaptive management process, but complete specification of such a system following concepts of waterfall design was considered impractical, and the development team opted instead to implement an incremental and evolutionary approach to system design, following the principle of “build a little and test a little.” Based on logic-based processing, Versions 1 and 2 in effect implemented support for monitoring and evaluation. However, as these early versions were put into application by users, we soon observed that users were attempting to simultaneously evaluate environmental conditions and derive priorities for management (e.g., planning), and that such approaches created considerable confusion about how to model the problem. Only after some reflection on such use cases, did it become apparent that providing for a separate but complementary decision component might have significant potential to simplify an integrated approach to evaluation and planning. Subsequent experiences with Version 3 and later, which added a decision engine to explicitly support planning activities, have confirmed the utility of the solution.

Much more recently, in 2009, EMDS analyses to support budget allocation for forest-fuels management for the US Department of Interior led to recognition of another opportunity by which to improve and extend the functionality of the system. Between 2007 and 2009, solutions had been designed by Department scientists, technical specialists, and mid-level managers to set priorities for level of effort with respect to fuels treatment. The set of models was primarily oriented toward biophysical considerations, but included some additional socioeconomic factors as well. Nevertheless, senior managers were primarily interested in using the modeling results to allocate budgets to agencies and regions of the Department. Conflating these two rather different purposes could easily lead to very undesirable outcomes because the existing solutions did not account for explicit economic and institutional factors necessary to support budget allocation decisions. Discussions around this apparent dilemma eventually lead to the realization that an additional layer of decision models, that consumed results from the existing decision process, was necessary to adequately address the multiple purposes for which solutions were being developed.

5. A Less Technical Overview of Version 5+

In the following two sections, users of earlier versions of EMDS will hopefully get a good sense of the major advancements that Versions 5 and beyond represent in terms of the power and flexibility to do environmental analysis and planning in a spatially enabled decision-support framework. Whereas Section 6 and Section 7 provide a more technical explanation of the new features and functionality of EMDS Version 5+, here we provide an introduction in somewhat simpler language, and in terms of the practical implications for the user experience.

The new workflow architecture moves EMDS from a static, one-size-fits-all, analysis paradigm to one virtually without limit. The new architecture allows the chaining together of any of the supported engines, in any order, to build very complex, maintainable workflows. The user is supported through a powerful workflow editor with the capabilities to flexibly create, maintain, and reuse existing workflows and their constituent workflow activities. EMDS 5+ will support users new to the system with a library of workflow activities, lessening the experience necessary to build a solid EMDS application. Now, EMDS 5+ will adapt to the user’s process model rather than enforcing its traditional process model on the user.

EMDS 5+ adds support for the popular relational database management systems Oracle^® (Redwood Shores, CA, USA) and SQL Server Spatial^® (Microsoft Corporation, Redmond, WA, USA), among others. Through services, data will be able to reside independent of the EMDS deployment. Now EMDS will be able to use corporate data sources directly without the need to import the data into the stricter and harder to maintain EMDS format.

By using web services, EMDS 5+ will move from being a strictly desktop application to one with great deployment flexibility. EMDS will still be available as a desktop application, but it will also be available in a server version in which EMDS clients communicate with the EMDS server to provide EMDS access to many remote users concurrently. Data storage and processing reside on the server, while the user interface can be another desktop application or even a web browser. In this context, EMDS modeling software can be developed and maintained centrally where the resources are, and applied where it makes most sense.

Through provenance tracking, EMDS application development and use will be much more interactive and will facilitate developing and using alternative workflow sequences. The utility is akin to having “go back” and “go forward” buttons on your web browser.

Coding in EMDS makes extensive use of the software technique of abstraction, which combined with the layered systems architecture, will make EMDS 5+ easier to maintain and much more “plug and play,” in that new features will be much easier to add. The technique of abstraction refers to the hiding of implementation details from the end user, and exposing a representation or interface that is easier to interact with. For example, if a new analysis engine is found that would enhance EMDS usability, it would not require changing the architecture of EMDS. It would, for the most part, require only writing the appropriate wrapper code (a generally small amount of code that translates “engine-speak” to “EMDS-speak”) to talk to the new engine. Other external issues such as licensing may exist. Now though, EMDS will be easily extendible to add new technologies and data sources.

6. Design Objectives of Version 5+

Over the course of Versions 5 to 7, a major goal of the EMDS consortium (we, for brevity) is to transform the current desktop technology into a complete design, analytical, and dynamic scenario-planning framework that informs decision makers by presenting scenarios that combine known or assumed facts with other plausible future conditions to explore the implications of alternative future states of a system. Additional goals aim to:

• Enable EMDS to support one or more analysts and managers to work on one or more projects concurrently across a wide variety of clients (a client is the part of an application, generally remote, that the user sees and interacts with). The current desktop implementation allows for a single user to work on a project, and there is a limited import/export feature to allow another user to view or alter the current project.
• Allow more flexible analysis for EMDS users. Over the years, we have received many requests to add flexibility to the EMDS workflow. For example, users often wanted to create a spatial selection and then run just a CDP analysis. In another case, preprocessing or any further geoprocessing done on the results was done outside of EMDS without any tracking. With the new framework, we will allow the end user to select from a common set of pre-defined workflows to perform a much wider variety of operations than is possible with EMDS 4.3.

We will be migrating from a traditional desktop architecture to a distributed service-oriented framework. This framework for Version 5 and beyond will be of Type II as defined by the SEI team (i.e., the Carnegie Mellon Software Engineering Institute, SEI). Type II frameworks are “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” (Phase 1: Strategic Analysis of Problem; SEI team; [23]). Future versions will move toward a Type III architecture to give additional flexibility to the systems. Type III architectures are “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” (SEI team; [23]).

The new framework will support true provenance tracking, which formally documents the ownership(s), origin(s), uses and transformations of computerized data. Provenance tracking is of particular concern with electronic data, because data sets are routinely modified and copied without citation of the originating data set or further documentation of data modifications. This functionality allows programs to expose each step of the process and to change conditions dynamically and then view the results. Scientific provenance tracking is defined as having the knowledge of all the steps in producing the result—from design through acquisition of data, manipulation of data, analysis performed, and any additional manipulations. From this information, a user will be able to reproduce a given result consistently, regardless of the complexity of the process. With the new EMDS framework’s provenance subsytems, we will be able to track all this information, excluding the model design, which is independently captured in the model building software, and the raw data acquisition.

In addition, the framework will support multiple users and will be multi-thread safe. In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler. A piece of code is thread-safe if it only manipulates shared data structures in a manner that guarantees safe execution by multiple threads at the same time. Multiple threads can exist within the same process (i.e., the running application) and share resources such as memory, while different processes do not share these resources. This allows for client applications to be written as standalone applications, ESRI ArcMap add-ins, or as web clients.

A defined application programming interface (API) is planned that will allow for extending the framework with additional data formats or analytical and modeling engines by the end user. An API specifies how software components need to interact with each other. In practice, an API is embodied as a code library that includes specifications for routines, data structures, object classes, and variables. A workflow editor will allow the end user to perform some changes to the execution steps within the EMDS client. This workflow editor will be the same editor we use to create the pre-defined workflows, and will display all the relevant higher level activities the end user selects. This will allow for user-defined workflows for users. These workflows can be added to the pre-defined workflow library. All these changes will transform EMDS from being solely an ArcMap add-in into a true suite of products supporting multiple platforms.

Current planned enhancements for EMDS Versions 5 through 7 include the following objectives:

• Workflow Foundation. The EMDS Framework will be powered by workflows, based on the Microsoft Windows Workflow Foundation^® (WF). Windows Workflow Foundation is part of the Microsoft .NET Framework and was introduced in Version 3 of the framework. WF is a workflow engine, programming model, and set of tools that allows developers and end users to build workflows that coordinate people and software [24]. Windows Workflow leverages the concept of activities, which can be simple, with only one activity to execute, or complex, and composed of multiple simple activities. One or more activities can be combined to form a workflow, which is the actual entity passed to the workflow engine. In this new workflow architecture, each functional unit of the EMDS framework will be engineered as one or more WF activities, enabling users to organize their analyses as customized process chains. Each engine (NetWeaver^® (North East, PA, USA), Priority Analyst^® (Seattle, WA, USA), and potentially others) will have a standardized, pluggable wrapper that will be exposed within the EMDS Framework as a series of workflow activities. Pluggable functions (aka “plug-ins”) let the user extend the core functionality of an application via software components that add specific features otherwise not present in the application. When an application supports plug-ins, it enables customization and extension. A default set of pre-defined workflows will support traditional EMDS process patterns (e.g., Project > Assessment > Analysis > Scenario > Prioritization). A library of pre-built workflow activity templates will also be provided to enable users to create their own customized analytical process chains with a minimal amount of coding. A workflow editor will enable users to create, save, and re-use workflows. Provenance metadata will be recorded for each workflow activity, enabling users to undo, redo, and pivot from any step and move along an alternate workflow sequence. All workflows will support both synchronous and asynchronous interfaces. Synchronous operations require the software to wait for the called operation to complete before the current process continues whereas asynchronous operations allow the program to continue doing other things while the asynchronous operation runs. Asynchronous operations generally are more complex to implement, as the program must be notified of their completion so that the program can update accordingly. In addition, all workflows can be exposed as web services, accessible by both desktop and web clients. The workflow platform will be integrated with Microsoft’s Project Trident^® workbench [25]. Translators, which convert data and/or programming calls from one convention to another, may be built to facilitate integration between Trident and third-party modeling packages such as the IBM Web Process Server.
• Pure Microsoft .NET^® Implementation. The EMDS core and the integration of the NetWeaver^® and Priority Analyst^® engines will be re-engineered in NET^® to improve system performance and stability.
• Multi-core CPU. To speed up in-memory calculations and operations, EMDS will be updated to support hardware systems with multi-core CPUs.
• Relational database management system (RDBMS) support. Currently EMDS supports SQL Server, Microsoft Access, and SQL Server Compact edition. EMDS 5 and beyond will add support for Oracle and Postgres, while supporting the use of Oracle^® and Microsoft SQL Server Spatial^® RDBMSs.
• Graphical User Interface Tools. The next generation of EMDS will have a new Project Manager component for adding, deleting, and updating project metadata, and for importing/exporting multiple projects. A Report Manager tool will enable users to create, select, and re-use reports, including support for auto-updating the data behind reports and sending reports on a pre-determined schedule. A new web-based user interface component will enable users to view existing EMDS projects and modeling results in tabular, graphical, and spatial formats.
• Actions that change the state of the system. For end users, actions that change the state of the system will be one of the biggest additions to the framework. Supporting actions will allow for running scenarios that are based upon some activity or action that modifies the state of the current system—through altering analytic models, data, or both—and then re-running the analysis to see how it affects analysis outcomes. New map comparison tools will be provided to evaluate the change in systems wrought by such actions. For example, an EMDS project is created to analyze a set of watershed conditions. After running the models, a possible action is to reforest selected segments of stream bank. This would lower the water temperature, which is an effect on the model because it includes temperature. Fish species may be affected due to this change, and the watershed condition may be improved. Another example is a model for forest-fuels management. After running the analysis, one possible action is to remove underbrush from specific areas. If this is done, the particular areas could be expected to have a reduced fire danger.

7. Architecture of EMDS 5+

The new architecture of EMDS will transform the platform from a simple ArcMap add-in to a complete multi-faceted platform that supports modeling, analysis, actions and scenario-based planning. With the new architecture, instead of a single monolithic application, the work of the EMDS system is now broken into discrete parts set within a systems framework (Figure 1). There are two low level sections of the framework, which are the Engine Services Tier and the Data Services Tier.

Figure 1. Overview of the EMDS 5 service-oriented architecture.

Figure 1. Overview of the EMDS 5 service-oriented architecture.

7.1. Engine Services/Wrapping Tier

For the analysis and modeling engines, we will now have a layer between the rest of the framework and the individual engines (Figure 2). For each engine type, we have abstracted out a common set of functions that each engine supports and have a query-able interface to call engine-specific functionality via .NET wrappers. In computer programming, a library is a collection of subroutines, usually external to the application. Wrappers are sparse amounts of programming code that translate a library’s existing interface into a compatible interface. This is done to allow code or data formats to work together which otherwise cannot, or to enable cross language or runtime interoperability. The wrappers provide the generic interface for each engine, as well as a queuing service and work-ID management facilities to handle multiple user requests, even for engines that do not support multi-user or are not thread safe. All calls for analysis and processing of models will go through these interfaces. EMDS will support spatial, temporal, ontological, (Ontologies allow for the organization of entities, concepts about entities, and relationships between entities. This means we can describe the world or a portion which we wish to deal with in an agreed upon formal vocabulary that allows other people to have the understanding that the original creator of the ontology meant. Once the ontology is created, an ontology engine can be used to infer logical consequences based upon the facts contained within the ontology) scheduling, logic, and multi-criteria analysis engines as default components within the new framework.

Figure 2. Engine Services Tier. NET wrappers provide the interface to each engine in this tier.

Figure 2. Engine Services Tier. NET wrappers provide the interface to each engine in this tier.

7.2. Data Services Tier

With the Data Services Tier, all data storage functionality is hidden behind services and objects with which the Business Logic Tier (see next section) and Presentation Logic will interact (Figure 3). For EMDS 5+, we plan to support spatial, traditional data sources, and ontological data sources. Initial database support will be SQL Server, SQL Server Compact, and Oracle. For spatial storage, we will support file geodatabases, ArcSDE, SQL Server, and AllegroGraph. For ontological sources, initial support will be for Allegrograph, with future support of Oracle already planned. These are mapped to the Data Services and Spatial Data Services.

The key changes to the EMDS database structure will be driven by the need to fully support provenance recording, with assistance from the EMDS Logger service, and the fact that we need to support a more flexible structure than the old Project > Assessment > Analysis workflow process when we add the actions capability and the workflow engine. There will be a predefined set of analytical workflows, one of which will match exactly the existing EMDS 4.3 workflow, along with several other optional workflow process paths to assist in analysis and what-if processing beyond the current limits of the system. Therefore, the database will not only need to keep track of the map and attribute data, but must also include additional metadata to allow the system to handle each of the different workflows within the same schema. The database schema is also being modified to allow for multi-level undo functionality within the system along with ability to view the history of the data changes.

Figure 3. Data Services Tier. Data storage functionality is hidden behind services and objects that are accessed by the Business Logic Tier (Figure 4).

Figure 3. Data Services Tier. Data storage functionality is hidden behind services and objects that are accessed by the Business Logic Tier (Figure 4).

7.3. Business Logic Tier

Both the Engine Services Tier (Figure 2) and the Data Services Tier (Figure 3) will interact with the Business Logic Tier (Figure 4). The Business Logic Tier will expose a series of Windows Communication Foundation (WCF) Representational State Transfer (REST) Services [26] and Workflow Activity libraries to allow end applications to easily tap into the power of the engines and database. The EMDS Base Activity Library will contain the low level workflow activities (Low level workflow activities are the granular operations of the framework. Examples of these include reading and writing from the database, submitting queries to the ontology engines, running an ArcGIS Server service, or routing of messages between tiers) and WCF REST Services to perform fine grain operations, such as create a new project, do a spatial union, or query for a subset of provenance information. This library of activities works along with the EMDS Base Data Activity Library, which handles the low level interactions for data access. These metadata on activities are saved inside the database, which can, in a future update, leverage a reasoning engine such as Allegrograph or LPA, and dynamically create a complex workflow based upon these activities and based on information stored in ontologies (Reasoning engines, which include Ontology Engines and Inference Engines, take a set of facts that is defined as the knowledge model of the system and given a set of conditions. The engine will then infer a logical conclusion or consequence of the action. LPA (Logic Programming Associates) is a Prolog based Inference Engine system, in which you define several facts and the rules that are applied to it. From this, LPA can evaluate a query that is submitted to the system. LPA has a visual editor called VisiRule to allow for a graphical representation of facts. Allegrograph, an Ontology Engine, takes a standard ontology and allows you to create SPARQL queries to perform the evaluation of facts against).

7.4. Workflow Implementation in EMDS

Activities are chained together using Windows Workflow Foundation to create a complete workflow that is exposed in the EMDS Business Logic Activity Library and EMDS Spatial Workflow Foundation Library. An example would be the Run Priority Analyst Workflow defined in the EMDS Business Logic Library. This multi-step workflow is defined as follows:

Figure 4. Business Logic Tier. The Business Logic Tier exposes a series of REST Services and Workflow Activity libraries that allow applications to easily tap into the power of the engines and database.

Figure 4. Business Logic Tier. The Business Logic Tier exposes a series of REST Services and Workflow Activity libraries that allow applications to easily tap into the power of the engines and database.

• The CDP model is loaded via the EMDS Base Activity Library.
• Another activity is called in the EMDS Base Data Activity Library, which returns the records for the particular dataset.
• A SendandReceive activity in the EMDS Base Activity Library calls the Multi-Criteria Decision Analysis service in the Engine Services Tier. It is called and passes the model and dataset, and waits until the processing is completed and a dataset is returned.
• The EMDS Transaction Controller updates the provenance information.
• The result set is returned to the calling application.

The EMDS Transaction Controller is the main sub-system that allows the system and end user to access and manipulate the provenance information. This service handles undo requests, workflow branching due to actions, a true history of work done, user and application state, as well as handling any errors within the Business Logic Activity Libraries. The EMDS Scheduler handles the loading, editing, and processing engine for workflows. This component reads the activity workflows from the other activity libraries and runs the Windows Workflow Engine to perform the actual tasks.

8. Discussion and Conclusions

Implementation of the first of the EMDS 5+ versions, EMDS 5.0, will have been completed shortly after this paper goes to press. Looking ahead, we turn to some practical issues of how this and the next few generations of EMDS, as well as other modern systems delivering similar functionality, may be able to provide improved decision support for the rather challenging problem of adaptive management under climate change. In the following, we focus on the specific features of EMDS as described in the previous sections, but suggest that these observations are broadly relevant to the provision of improved decision support for adaptive management under climate change.

8.1. Logic for Interpretation and Synthesis

As discussed in the most recent report from the Intergovernmental Panel on Climate Change [27,28], numerous simulation systems (i.e., MC1 [29]) are being employed around the world to predict changes in vegetation structure and function globally, regionally, and locally in response to projected changes in climate. The simulation products from such systems are high dimensional in the sense that they typically address numerous facets of both ecosystem structure and function. Assuming that predictions are reliable, there are, though, still fundamental questions about what the changes mean. For example, what do all the predicted changes mean in terms of altered ecosystem resilience [30] or the ability of ecosystems to provide ecosystem services [31]? These and similar questions strongly suggest the need for interpretation and synthesis, for which logic has proven a powerful tool [1,8], considering the size, complexity, and abstractness of the problems being modeled. On the value of logic in the context of understanding and responding to climate change, efforts at all levels of government are taking place in a highly charged political and public environment in which maintaining the transparency of decisions and associated public policy will be essential to constructive debate and action. Logic has repeatedly proven its value in this respect as well [8].

8.2. Prioritizing Landscape Units

Simulation models that predict vegetation response to climate change and logic models that can interpret and synthesize results to address important questions about topics such as ecosystem resilience and delivery of ecosystem services offer important capabilities for addressing climate change, but these tools are not sufficient by themselves because, beyond understanding the state of ecosystems altered by climate change, there is still the problem of what to actually do about this information in terms of strategic and tactical responses. Multi-criteria decision models (MCDM) are a useful complement to simulation and logic models in this context because they can incorporate the possibly many logistical considerations such as feasibility, efficacy, and social acceptability that are also essential for well informed decision making [32]. For example, just because a particular landscape element evaluates as being in extremely poor condition with respect to resilience, does not necessarily mean it should be a top candidate for adaptation or mitigation measures. A more circumspect evaluation that includes critical concerns of managers as represented in an MCDM may well suggest a lower priority given practical logistical considerations such as feasibility or efficacy of management actions.

8.3. Using Actions to Design Strategic Alternatives

In addition to prioritizing landscape elements for management actions as discussed in the previous section, strategic alternatives are also often developed as part of an adaptive management process, whereby each alternative is represented by a set of management actions to be implemented and that are expected to transform the current landscape into some new future condition, represented by alterations in the values of current landscape elements in a spatial database. Such a transformation process is typically time consuming and complex, requiring major interventions by GIS specialists, and thus represents a major bottleneck in the overall decision-support project. Indeed, one of the more common requests for enhancements to EMDS in recent years has been for methods to automate the effects of strategic alternatives on the landscape so that the spatial realization of the alternatives can be critically evaluated relative to each other. The availability of the workflow editor in later versions of EMDS has the potential to substantially automate these kinds of landscape transformations, with the potential to dramatically reduce the time and effort needed to create landscape realizations of strategic alternatives. Of course, developers will have to design the requisite workflows, but, as with other kinds of data modeling, there is also the potential to share these workflows with, or adapt them to, other projects. Workflows shared in this way thus represent a kind of institutional knowledge that might be built up and used by a community of practice concerned with decision support for adaptive management under climate change.

8.4. Adaptive Management

In the previous discussion topics, we have touched on various aspects of adaptive management. In this final section, we turn to one of the central themes of adaptive management, which is a scientifically sound approach to learning “as we go” [33,34]. In other words, having settled on implementation of a specific management alternative to be applied to a landscape, we need to be able to pose and answer a few basic questions such as, “How well did we do at improving landscape resilience?” or, “If landscape resilience did not improve as expected, in what sense did we get it wrong?” Both of the latter questions require the ability to compare outcomes on the landscape over time. EMDS already has an inherent capability to address these types of questions, because multiple assessments, representing evaluations of the same factors over time are easily implemented in the framework of the system, but full support for comparing landscape outcomes over time is currently lacking because the system lacks the explicit methods or tools for a statistical analysis of change. Interestingly, though, this hallmark of the adaptive management process could, in principle, easily be added to the EMDS framework, taking advantage of a workflow editor. This last example is just one of the many possible ways in which integral support for workflows in a decision support framework such as EMDS could enhance the power of decision support systems for adaptive management under climate change.

8.5. Revisiting the EMDS Success Factors in Relation to EMDS Version 5+

In Section 3, by way of introduction to earlier versions of EMDS, we described five factors that have contributed to the success of the system up to the present time. Here, we conclude by considering in what respects Version 5+ continues to build upon those factors.

• Generality. Use of logic and decision engines in the EMDS framework has historically allowed developers to successfully address a broad range of problems in environmental management, but of course there are many other types of engines (e.g., Bayesian and Prolog engines) that could be brought to bear either to address additional issues such as scheduling management activities, or to provide alternative solution methods that a user may prefer. Version 5+ extends the generality of EMDS solutions by making it relatively easy to add new tools into the Engine Services Tier of the framework (Figure 2) via the workflow editor. Thus, for example, having identified the top 20 watersheds most in need of restoration in a planning region using the logic and decision engines, a Prolog engine might now be invoked to optimally schedule treatments. In a similar fashion, additional generality is introduced via the Data Services tier (Figure 3), which now simplifies the process of extending the data source options of the system.
• Transparency. A first order consideration under the topic of transparency has been the transparency of the logic and decision models per se. In Version 5+, we extend this concept to the transparency of the overall solution produced by an application (e.g., a second order consideration) via provenance tracking as implemented in the Business Logic Tier (Figure 4).
• Abstraction and complexity. In Section 8.1, we discussed the role of logic as one approach to dealing with the complexity of large, complex, abstract problems. Decision support for adaptive management under climate change could arguably be the “poster child” for complex decision support applications. Thus, another aspect of complexity concerns the evolving complexity of decision support applications as they are put into practice. For example, in EMDS, a project may span multiple spatial scales of assessment, assessments may involve multiple logic-based analyses with multiple what-if scenarios, and each such analysis might have multiple decision models associated with it. In other words, an EMDS project can quickly grow to be quite large, especially as application developers explore multiple possible pathways for evaluating ecosystem condition and developing and testing alternative management strategies. Provenance tracking in Version 5+, as discussed earlier, provides an effective mechanism both for accountability and basic project management. With respect to accountability, provenance tracking provides a mechanism for thoroughly recording the complete evolution of a project, making it possible to fully document and replicate even very large and complex analyses. The overall analytical process may often be adaptive in nature, with new pathways being explored as the analysis unfolds. In this context, provenance tracking also provides a mechanism to backtrack along a pathway and pivot along new sub-paths, thus adding support for adaptive analysis.
• Simplification and spatial scales. Closely related to the last point, EMDS has historically always had an inherent capacity to design applications for environmental analysis and planning that span multiple spatial scales by virtue of developers being able to design assessments for each required spatial scale and passing analysis results from (typically) finer to broader scales of analysis. In earlier versions of EMDS, it was left to the application developer to execute all the geoprocessing steps necessary to support such cross-scale analyses. At Version 5+, however, these same tasks are greatly simplified by automation in workflows. A similar point has already been made about simplifying simulation of management actions through work flows.

In conclusion, we believe that it is fair to conclude from the above points that the next generations of EMDS remain faithful to those original set of success factors presented in Section 3, while greatly enhancing system capabilities with new technologies that, we hope, advance decision support for adaptive forest ecosystem management in the face of the challenges posed by climate change.