![]() |
|||||
|
|
|
|
||||
Using Interoperable Process Models in a Multi-agency Planning Toolkit for Enterprise and C4ISR Architecture Analysis David Payne, Kenneth Hoffman, Kangmin Zheng Increasingly, government initiatives such as e-Government, along with new governmental challenges such as homeland security, require groups of agencies to interoperate at the mission, activity, and organizational levels, as well as at the information system support level. The collaborating agencies typically have incompatible information or enterprise architectures at varied stages of development and sophistication. Key aspects of successful interagency collaboration depend on the interplay of human and IT and non-IT systems forming a work flow or activity network. Issues include timing, synchronization, priorities, bandwidth, systems compatibility, and agency-unique syntaxes. The syntax issues exist at both the data and information exchange levels, with information exchange syntax differences impacting both human and machine information exchanges. A MITRE research team is exploring the issues surrounding enterprise modernization planning in a multi-agency environment. Its objective is to support integrated mission and information technology planning covering enterprise strategic plans, performance management, investment plans, and information resource management plans through more detailed representations of mission and business processes that are coupled to the Enterprise Architecture (EA). The team is developing the Multi-agency Planning Toolkit, which will include use of process models developed in several commercial process modeling environments, as well as static information architecture products conforming to defined architecture frameworks. One of our goals is to find ways to easily move architectural and process information between the static architecture environments and the dynamic process model environments. A second goal is to explore environment to environment level interoperability of the process models built in different commercial-off-the-shelf (COTS) environments. This capability will support use of existing models from individual agencies as active components of a larger multi-agency planning environment. The work is being funded by MITRE's Center for Enterprise Modernization, a federally funded research and development center sponsored by the Internal Revenue Service. Planning Framework Specific multi-agency missions we are considering in the design of the planning framework include:
Planning and analysis for multi-agency missions covers:
Such planning is a significant challenge that requires a comprehensive base of information on mission objectives and the resources to be applied. Resource categories that must be addressed include the workforce, facilities, technology, and information. Much of the required information base for planning is provided through the significant effort devoted to enterprise architectures by individual agencies. Critical information on assets, processes, and location may be contained directly in the architecture or may be identified as an external information resource. The dynamic changes in technology and business practice have imposed greater pressures on many government agencies to provide faster delivery of more accurate and up-to-date information to customers and to all levels of their organizations. To tackle these challenges, the Office of Management and Budget has established a policy in its Circular Number A-130 requiring each government agency to develop and use an enterprise architecture as the primary mechanism for enterprise modernization. These architectures also form the principal basis for justifying and managing future information technology investments, as part of the U.S. federal budget process. Many agencies have already developed EAs, and most others are in the process of developing one. A complete enterprise architecture contains a number of specifically formatted information products depicting: the agency's concept of operations or business model; information flows within the agency and between external mission partners; dependencies and relationships among business activities; information systems; data elements; and the interconnections of the hardware, software, and telecommunications within the agency. The ability to represent and efficiently use EA data in a uniform way—regardless of the source, platform, and formats—is crucial for successful and effective multi-agency mission planning. Responding to the Challenge: The Planner's Workbench Our response to the multi-agency planning challenge is a research and development effort to produce what we call the "Planner's Workbench.” Our vision of this Planner's Workbench organizes and integrates a variety of analytical tools and methods that will provide planners and analysts access to process, geographical, and technical information pertinent to planning mission and support activities involving multiple agencies. The Workbench will integrate process models developed in several commercial process modeling environments with static information architecture products conforming to defined architecture frameworks. Our concept for the Planner's Workbench includes a toolkit, containing integrating tools to easily move architectural and process information between different architecture environments, different process modeling environments, and between the static architecture environments and the dynamic process model environments. The toolkit will also provide a data repository engine to store and exchange architecture data between the various architecture products and tools. A third component will be a geographic information system (GIS) interface that will allow the user to easily enhance architecture products with accurate geospatial information, keyed to a scenario timeline. The final component of the toolkit is a generic high level architecture (HLA) link for a COTS environment-to-environment level interoperability of the process models. This will support use of existing models from individual agencies as active components of a larger multi-agency planning environment. In addition to the toolkit, the Planner's Workbench will also provide a non-volatile architecture metadata repository to store information about the architecture products and their components. This repository can grow with use, enhancing and speeding future multi-agency architecture efforts by supporting reuse of agency specific architecture information. The Workbench will also have a detailed "Users Guide," in the form of a detailed multi-agency architecture analysis and improvement methodology. We hope to provide this methodology to users via a Web-based interface with links to the supporting Toolkit components. Toolkit The integration view of the toolkit along with the planning workbench and enterprise data is diagrammatically represented in Figure 1. Following, we discuss the core elements of the toolkit.
Figure 1: Multi-agency Enterprise Planning Framework Translators Translators are programs that take either the native file format or some supported export file format from one application or environment and convert to the native file format or some supported import file format of another application or environment. The Toolkit needs translators because there is no mandated or standard format for information architecture products. Architectures are often documented in a mix of document systems (often Microsoft Word or Adobe Acrobat), presentation or graphics systems (such as Microsoft PowerPoint or Visio), and spreadsheets (such as Microsoft Excel). Additionally, specialized architecting environments are becoming more common, and each has its own file format. Common architecting environments include Popkin System Architect, pTech, Rational Rose, and netViz. Finally, many process models built in process-simulation environments document key details of enterprise and information architecture and are, of course, useful for analyzing the static architectures depicted in the architecture tool files. A rich set of translator tools provides the means to rapidly get the information documented in a number of formats into a single format for additional analysis and development, and into an executable format for dynamic analysis through simulation. Our toolkit will attempt to leverage a MITRE-developed translator suite called ICAMS. To do so we will extend the capabilities of ICAMS, attempt to identify and use another translator tool or tools, or develop our own translator tools. Note also that many tools and environments support import and export capabilities, and when the export format of the source environment matches a supported import format of the target environment, no additional translator tool is needed. Architecture Environment and Repository We have selected Popkin System Architect (SA) as our target architecture environment, based on availability within MITRE and the fact that several of our MITRE sponsors have also chosen to use this environment. What we hope to do with SA, however, is to leverage architecture metadata to allow us to chain a number of architecture products either done in SA or translated to SA into one virtual, multi-agency architecture. We then intend to use this virtual multi-agency architecture to generate executable process models to first support benchmarking the current performance of the multi-agency coalition and then re-engineer the multi-agency process to produce a quantifiable predicted performance improvement. Finally, we will reverse the translation process to import the improved processes back into SA, modify or develop the rest of the "to-be" architecture package in SA, and then export the improved "to-be" architecture products into the native (that is, preferred) file formats used by the agencies in the coalition. These products will then support systems design, acquisition, systems modification or development, and integration of the new processes and information technology required to field the new multi-agency capability. We plan to leverage the repository capabilities built into SA for the initial version of the toolkit. Later on we hope to develop a full and open metadata repository that will serve correctly formatted data files to a number of architecture and modeling environments, all based on one common architecture repository. This will help ensure that the architecture data remains consistent and make it easily available to users regardless of the architecture tool they chose to use. GIS Location Tool Early in our exploratory research we noticed that many multi-agency missions, and hence the architectures that support those missions, are dependent on the geospatial location of the multi-agency nodes participating in a process or scenario. Moreover, this geometry changes over time. Existing architecture tools and the other applications commonly used to build architecture products all seem to share several common weaknesses in documenting node locations. The biggest problem is that the location attributes either provided (as in the architecture tools, which have a library of predefined entity types) or defined by the user (as in the non-specific applications used to document architecture) use general, subjective descriptions of nodes and node locations. What we need is a way to precisely describe locations in a recognized coordinate system. We believe we can use a GIS interface based on ArcView to allow users to precisely locate nodes in the world, relate their coordinates to other nodal attributes, and relate sets of interconnected nodes at specific times in mission scenarios or business cases. Providing Interoperability In addition to being a source of enterprise architecture information, simulations of key processes in member agencies of a multi-agency coalition often exist and offer a tempting opportunity to leverage past work. These simulations are typically executable process models built in a COTS modeling environment. The modeled processes typically take an input that would initiate in another organization or from the public, perform some internal work, and result in an output to another agency. The initial agency may eventually provide an output to the public (or other initiator), but the inputs and outputs to other agencies are typically limited and occur at discreet points in the simulation. Hence it is attractive to try to chain several process simulations together to model an entire end-to-end process. However, the component models may be built in different COTS environments, or the total process chain may overwhelm the capacity of the typical desktop or laptop computers supporting the models. So distributing the models across an interoperable federation is attractive to address either problem. Our toolkit will attempt to use the HLA simulation interoperability standard to link several COTS modeling environments at the environment level. Our intent is to ease the use of HLA for non-HLA users, such as the typical modelers and analysts using the COTS process modeling environments. Our current strategy is to design a federation object model (FOM) and a base object model (BOM) that will allow a standard, though limited, level of model interaction. The FOM will define the interchange objects and guide design of HLA gateways for COTS environments where they don't yet exist (at least one COTS vendor has already developed a gateway for its tool), and the BOM will serve as a template to build export and import components in the native form for each supported COTS environment. The COTS modeling environments we are targeting support component-based graphical modeling interfaces, so the idea of portal components should be easily grasped by the users of the COTS tools. We tentatively call this interoperability capability "COTSFed." COTSFed will help us make maximum use of existing process models, even if those models are implemented in different COTS simulation environments. Meta Data Respository The long range goal for the Planners Workbench is to build a capability to link inconsistent data, different technologies, and diverse EA application models for the multi-agency planning environment. In order to build such an advanced capability, we recognize the need to use the most current available technologies and industrial standards. The technologies considered include the OMG Model Driven Architecture strategy, providing platform-independent models that can be mapped to evolving technical platforms, and the HLA standard for simulation interoperability. We are also giving close attention to the impact of widely accepted standards and technologies—such as the Common Warehouse Model, the metadata model (MDF, XMI, JMI, and XML), software agent technology, data warehousing, EAI Technology, and electronic commerce—to address mapping data between diverse EA application models dynamically. Multi-agency Planning Framework Methodology The Multi-agency Planning Framework methodology is designed to plan and integrate:
The planning methodology is based on the concept of an Enterprise Work Breakdown Structure (EWBS) describing the multi-agency mission and support activities, and uses principles of Activity Based Planning and Management. Given a complete and precise EWBS, the architecture and supporting process models can be developed at the appropriate level of detail to provide a comprehensive knowledge base applicable to all of the above planning functions. The first step in integrating architecture from several agencies is of course to collect the architectures. If each agency has a recent architecture and it is accurate and complete, this is a trivial step. If not, then "step 0" is to collect and construct at least a minimal agency enterprise architecture. Several methods exist to do this, but this topic is outside the scope of this paper. The next step is to get all of the architecture products into a common format. This is where the translator tools in the toolkit will come into play. Our short-term approach is to translate the various architecture products from the various agencies into a set of equivalent System Architect products. Next we propose to link the various agency architecture products using a minimal "meta-architecture." This meta-architecture will consist primarily of pointers into agency architecture products, maximizing leverage of the existing products. Then the absolute minimum of additional linkages, information exchanges, and activities may have to be added to complete the multi-agency architecture. We plan to do the additional architecture work in System Architect, as well as devise extensions to it to support the linkage pointers into the component System Architect single agency architecture libraries. Architecture Analysis and Improvement At this point we will be able to export architecture products to build process models in an automated fashion, as well as link whatever existing process models already exist. The goal is to establish a dynamic test bed of the multi-agency enterprise, which will support performance benchmarking and quantify the effects of process changes. Typical metrics will include cycle times, queuing delays, the number of completed and missed actions, and a wide range of resource related activity-based costing (ABC) metrics. The specific metrics for a given multi-agency enterprise will of course be driven by the goals and objectives of the enterprise and the enterprise leadership. Process changes that improve overall mission accomplishment or resource efficiency, and pass return on investment tests, will make it into the so-called "to-be" process. The to-be process will in turn lead to a to-be architecture. We will then modify the System Architect meta-architecture and component agency architecture products to reflect the to-be architecture. Finally, we will again use the translator tools in the toolkit to generate agency to-be architecture products in the formats used by each agency. These to-be architectures will then support design, acquisition, and implementation of the new processes and information systems that will support the improved multi-agency enterprise. |
|||||
| For more information, please contact David Payne, Kenneth Hoffman, or Kangmin Zheng using the employee directory. Page last updated: November 12, 2003 | Top of page |
|||||
Solutions That Make a Difference.® |
|
|