 |
 |
 |
 |
| |
|||||
|
|
|
|
|
||||
A New Approach to Analyzing Enterprise Architectures Paul Barr, Thomas J. Pawlowski III, and Steven J. Ring 
n times of crisis—whether a terrorist threat, an earthquake, or a battle—it is critical for organizations to share information quickly and securely. How effectively information is passed from the source to the user can often determine the outcome of the emergency or conflict. To help ensure the quick and efficient flow of information, most U.S. government organizations—including the Department of Defense (DOD) and Department of Homeland Security (DHS)—have created enterprise architectures, which must be constantly tested and refined. The idea of extending prototyping and experimentation approaches to architecture development is new and evolving. MITRE's goal is to help organizations analyze the information flow of complex systems-of-systems elements at the enterprise level, with the expectation that more efficient designs can then be defined at the software and hardware architecture levels. All government organizations must create enterprise architectures to understand their IT needs and support investment decisions. These architectures act as a kind of roadmap for the design, development, and acquisition of complex, mission-oriented information systems. Such an architecture describes all aspects of an organization: its mission, organizational structure, business processes, information needs, software applications, and underlying technical infrastructure. A change in one dimension may impact the other dimensions. And an enterprise architecture is a living document—changing along with missions, strategic goals, and emerging technologies. MITRE has a great deal of experience in creating enterprise architectures for numerous organizations, including the DOD and several of the DHS agencies. For example, we helped develop the DOD Architecture Framework, which all DOD organizations use as a basis for building and describing their own architectures so that they can be compared and related across organizational boundaries. The idea is that using the same framework to develop systems will help them achieve interoperability. Most DOD Architecture Framework products currently being developed provide "static" information (e.g., name, description, quantity) for operational, system, and technical views of an information system. The DOD Architecture Framework, however, also supports descriptions of dynamic or behavioral information in the form of models and descriptions of events. But there are no processes and tools to capture this dynamic information—tools that can validate an architecture and perform "what if" analyses. The tools available don't provide an adequate model for conducting detailed time-dependent behavior analysis of complex, dynamic operations and human and system resource interactions, which can't be captured with static operational models. In response, MITRE began a project to:
The result of our work was the Executable Architecture Methodology for Analysis (EAMA). An executable architecture is a dynamic model of sequenced events performed by humans and systems, for example, how troops share and access information on a battlefield. Some architectures provide only a "static" view of the systems they are simulating. A "static" view displays a system's capabilities but does not display how information is actually produced and used in real-time operations. EAMA is designed to provide a "dynamic" view. It displays how information is produced and used, by whom, and what resources they use in doing so. EAMA was developed to perform a dynamic analysis of the DOD's command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) information architecture. Recently we have also extended our EAMA work through an internal research project focusing on how multiple agencies respond to a crisis.
Dynamic analysis enables a user to assess the impact of change and determine measures of performance and effectiveness. To perform a dynamic analysis, we first chose a measurable objective. Next, we chose data with which to measure the objective. We fed the data into the simulation and measured the objective. Based on the results, the simulation was modified and rerun until the objective was met. In this case, based on our analysis of a simulation run, we recognized the bottlenecks of the information flow among the staff members in a battlefield environment. Performance objectives were achieved by altering the staff relationships and rerunning the executable architecture. By measuring multiple objectives, we can assess an overall operation under different conditions. To offer a complete analysis, dynamic models must simulate the relations among multiple systems as information is networked from source to user in crisis conditions. Federation of Simulations To achieve this simulation of system relationships, we incorporated within EAMA a federation of simulations that represent the three key components related to the mission objective. The first simulation component is the combat simulation model that provides the operational environment in the context of the flow of the battle. The second simulation component, the process model, consists of two views: an organizational view of human and material resources and a process view of the flow of information through these resources. The third simulation component models the communications network as it channeled the flow of information. How do EAMA's simulations perform? Key events in the combat simulation trigger business processes in the process model. As the process model plays out, it requests from the communications network model the amount of time it would take for information to pass from various source nodes to user nodes through the network. Homeland Security Working with MITRE's Ken Hoffman, we extended the EAMA work through an internal research project designed to examine the application of executable architectures to a case where multiple agencies were involved in a common mission. For the case study, we used a homeland security scenario called "Vigilant Sentry" that involved a mass migration from a Caribbean island into the southern United States. This scenario involved agencies in DHS, with the Coast Guard in the lead, and agencies in the DOD, State Department, and Justice Department, as well as state and local authorities. We narrowed the scope of the study to concentrate on the interdiction of migrant vessels by Coast Guard vessels and the reporting of the migrant information (name, gender, age, nationality, etc.) through command and control channels. Using the Vigilant Sentry operational plan and the architectures of several key agencies, we developed the scenario simulation using a Course of Action analysis tool called Joint Military Art of Command Environment (JMACE). We developed the key business processes in a process modeling tool called Bonapart. We also used a communications network modeling tool called NS-2 to represent the communications nodes involved in passing information among aircraft, vessels, and command and control centers. These tools were linked together and run as a federation of simulations. An example of the sequence of actions among the simulations follows. In JMACE, Coast Guard aircraft and cutters patrolled their assigned areas in the Atlantic Ocean, Straits of Florida, and Gulf of Mexico. When one of these patrols spotted a migrant vessel in the water, it would send a detection report. This event in JMACE would trigger the business process in Bonapart, causing the activities within that process to begin executing. Typically these were information processing and decision-making processes at the command centers, including, for example, determining which Coast Guard vessel would interdict the migrant vessel. As one activity was finished and passed information to another activity, Bonapart would request a delay time from NS-2. This delay time was the time required to send the information from the sending node to the receiving node based on the current load on the network. NS-2 would calculate this delay time and send it back to Bonapart, which would add it to the process time. When Bonapart completed the business process, an order would typically be sent back to JMACE instructing the appropriate U.S. vessel to interdict the migrant vessel. By running this federation of simulations, we were able to examine several different measures of effectiveness and performance. From JMACE, we could determine the number of migrant vessels interdicted and the number that were able to reach the United States. From Bonapart, we determined the processing time required to complete the various business processes. We also were able to determine the use of the available resources that were needed to execute the business processes. If one of these resources had become a bottleneck in the system, we would have seen the effect on processing times. From NS-2, we could determine if there were any bottlenecks in the communications network that resulted in significant delays in passing data through the network. The main focus of the case study was to extract insights and lessons learned about multi-agency executable architectures. We determined that multiple agencies working to achieve a common mission have many challenges, including the fact that many of their architectures lack the maturity and breadth to make them easy to integrate. But we have shown that by linking simulation components together, we can create an executable architecture with which to conduct dynamic analyses. We continue to enhance EAMA, for example, by adding functions to refine the resulting analysis. These functions include dynamic handling of stale messages and adding context-sensitive selection of resources. We are also addressing technical issues, such as EAMA's current inability to handle fault tolerance. The goal is for EAMA to gain the ability to examine how troops, or other groups, and their supporting processes consume resources over time. Our work provides the DOD and other organizations with the capability to better develop and analyze their architectures, support simulation-based acquisition, and support DOD and federal architecture communities. For example, it should be possible to improve descriptions of business processes, the activities behind those processes, and the information flow among the processes in enterprise architectures. The approach is consistent with the concepts of spiral development—which includes incremental iterations of planning, analysis, construction, testing, and release stages. A simulation-based architecture, or executable architecture, enables the creation of simulation-based or executable specifications for both existing and proposed systems. We have provided this methodology to the DOD community via demonstrations, conference presentations, and papers. This work could be useful to many of MITRE's other sponsors who are developing their own architectures and related products. We believe that EAMA can be an important component of an overall architecture-based strategy in which investment decisions are directly linked to mission objectives and their outcomes. |
|||||
| For more information, please contact Paul Barr, Thomas J. Pawlowski III, or Steven J. Ring using the employee directory. Page last updated: January 7, 2005 | Top of page |
|||||
Solutions That Make a Difference.® |
|
|
Download this issue [1.9 MB]