Enterprise Architecture Modeling

Enterprise Architecture Modeling of Ground Systems

James N. Martin

Aerospace helped NASA gain a better understanding of the complex relationships among various research and operational satellite missions. This new conceptual framework will help planners delineate the practical outcomes of enterprise-level program decisions.

NASA's Earth-Sun System Science division, part of the agency's Science Mission Directorate, explores the complex and dynamic relationship between the sun and Earth. The goal is to observe, understand, and model the Earth system to discover how and why it is changing. This is done through characterizing, understanding, and predicting change in major Earth processes and by linking models of these processes in an increasingly sophisticated manner.

Within this division, the Applied Sciences Program has the primary goal of providing Earth science information and technology to support the operational missions of partner agencies. For example, the National Weather Service is responsible for providing up-to-date, accurate weather forecasts throughout the United States. NASA performs much of the basic research that allows the National Weather Service to achieve that mission.

The Earth-Sun System Science division has six main areas of focus, each competing for a limited amount of funding. Some of these focus areas include things like weather, climate variability and change, and the water and energy cycle. It is not always easy to determine the best investment strategy that will guide proper research activities and produce the most benefit for society. Aerospace is helping NASA develop an enterprise architecture to guide investment and help scientists and engineers plan for system development. The architecture is being used to understand the interactions of the many elements that make up NASA's Earth Science enterprise.

Why would an organization like NASA need an enterprise architecture? An architecture helps an organization assess the current state of its affairs and explore possible future states to determine how best to change the way it does business. For example, if NASA were considering migrating some sensor functions to a different satellite, or discontinuing them altogether, how might that affect the data products and the partner agencies that depend on them? If a partner wanted lower data latency, could NASA supply it using existing resources? Are some agencies not taking advantage of information that would be useful to them? Are different divisions unwittingly duplicating each other's work? These are the types of questions that can be answered with an enterprise architecture.

The Integrated System Solutions Architecture shows how the basic elements of the Applied Sciences Program are connected. The decision-support tools help NASA's partners make policy and management decisions.

Priorities and Benefits

NASA has identified 12 application areas of national priority, each of which has a suite of support tools for use by decision-makers at partner agencies. These tools are provided with environmental predictions from NASA models, which in turn receive raw and processed data from many sensors on space-based and ground-based platforms around the world. The flow from observation to model to prediction to decision to societal benefit is known as the Integrated System Solutions Architecture. For example, an Earth-observing satellite might provide data on land and sea surface temperature, which would be used in models to predict hurricane strength and direction. Using the decision-support tools tied to these models, the National Weather Service would decide when to issue a hurricane warning, and local governments would decide when to issue evacuation orders. Similarly, the Federal Emergency Management Agency would decide how best to prepare for and mitigate the impacts of such a hurricane. The societal benefit of these decisions can be clearly seen in terms of property loss averted and human lives saved.

The United States Interagency Working Group on Earth Observations has identified nine major areas of societal benefit, ranging from better weather forecasting to closer management of energy resources. The mapping between societal benefit and types of Earth observation is relatively complex. The purpose of the enterprise architecture is to capture the details of these relationships in such a way as to facilitate analysis and assessment.

Enterprise Architecture Development

NASA is following the same six-step process that Aerospace used to help develop the enterprise architecture for the National Oceanic and Atmospheric Administration (NOAA). The six steps are: problem framing, metamodel development, data collection, model development, architecture deployment, and architecture assessment.

The first step—problem framing—is the most important because it sets the stage for all subsequent efforts. Starting with the wrong problem definition is often the cause of inadequate results when the "solution" is implemented. Problem-framing techniques have been quite beneficial in avoiding rework and getting more useful results. The problem-framing step can take up to 30 percent of the total architecture project effort.

Problem framing starts with a business analysis that involves three core requirements: identify the purpose of the architecture, identify the business questions to be addressed by the architecture, and establish the business priorities. It is usually difficult to define the purpose of an architecture because few people have had experience with a "good" architecture. Often, people develop an architecture because of a government mandate or an organizational directive. Aerospace assists by proposing many possible purposes and helping clients choose the one that is most appropriate for their particular situation. Having helped various organizations in the past, Aerospace can show example architectures from other projects and explain how they helped in each case. This helps clients understand better what is meant by the "purpose" of an architecture.

Business questions lead to a conceptual schema

Business questions identified during problem framing lead to a conceptual schema like the one shown here. The blocks in this diagram represent entities inside the model, while the lines represent relationships between the entities. (View larger image.)

The best way to get at a clearly defined purpose is by formulating the business questions. In the case of the NOAA architecture, for example, program managers initially said they wanted an "inventory" of their observing systems. When Aerospace started asking what they would do with this inventory, it became clear that an inventory would not be adequate. Instead, Aerospace helped them zero in on the real problems they were trying to resolve and demonstrated various ways to address them.

They wanted to know, for example, what environmental parameters were being measured by each observing system, where and when these measurements were taken, and whether these measurements met the requirements for environmental observation. Given these needs, an observing system architecture was clearly called for. But Aerospace subsequently discovered that NOAA also wanted to know what strategic goals were supported by each observing system, which users were being served by each, and what key science questions were being addressed. This led Aerospace to conclude that they really needed an enterprise architecture that included the observing system architecture as one layer in the overall structure. Additional layers would be needed to deal with strategy, business practices, applications, and infrastructure.

Some of the relevant business questions for NASA's Earth-Sun System architecture include: How does NASA's Earth-sun research help partner agencies meet their operational needs? How is the replacement of aging systems or the establishment of new sensors prioritized? How does each component of the Integrated System Solution Architecture contribute value to society? What are the potential outcomes? How can NASA's research assets contribute to meeting the needs of the Global Earth Observation System of Systems (GEOSS)?

Business questions identified during the problem-framing step lead to the conceptual schema. The results of conceptual analysis based on this schema are then converted into a formal metamodel using the Metis architecture modeling tool. The metamodel takes a few weeks to develop, primarily because it is not common to find an existing metamodel that fits the architectural situation. Sometimes, it is possible to find a metamodel template that is close to what is needed, requiring only minor modifications, but often it is easier to start from scratch.

Both the NOAA and NASA metamodels were customized to a large degree. Aerospace was able to use a few standard building blocks in the architecture, such as organizations, personnel, goals, objectives, and information needs. But other elements were needed pertaining to the observatory, instrument, measurement, application area, science question, data handling system, decision support tool, and stakeholder. One of the biggest challenges was not in identifying the necessary elements but rather in deciding what to call each element.

Aerospace developed this enterprise architecture for NOAA. The layered structure serves to partition the architecture into separate domains or special areas of concern that can be managed by separate groups or individuals.

For NOAA, Aerospace spent considerable time discussing the difference between an environmental phenomenon and an environmental parameter. For NASA, the major challenge was how best to categorize the parameter types. There is no industry standard for environmental parameter categories, nor even a standard for the names of these parameters. Aerospace helped NOAA and NASA create a standard taxonomy of names for the environmental parameters.

For the next step, data collection, NOAA identified 3000 architectural elements involved in environmental observations and used them to populate the Metis tool. Aerospace developed a Web-based survey with 160 questions to facilitate the data gathering process. While collating the data, Aerospace performed quality checks to ensure the information was adequate for the task and, where necessary, helped the domain experts fill out the survey. The resulting model includes 100 current and future NOAA observing systems with 250 sensing elements. The sensors take 350 different types of measurements of 200 different parameters.

The final two steps of the process involve deployment of the architecture tool to intended users and using the architecture to assess the business situation. The architecture tool is sometimes deployed to a central server for access across the Internet, and in other cases it is placed on a CD for installation on a user's laptop computer. Making the tool readily accessible to users greatly increases its value for making good business decisions. After assessments are performed, users often think of additional business questions that ought to be addressed. To handle this, the architectural engineers go back to step one and do more problem framing. This might then require a change in the metamodel, more data collection, and further model development.

Architecture in Action

An example of the enterprise elements involved in hurricane prediction will help illustrate how the model is used. Of the 60 spacecraft identified, two look at different factors of tropical cyclones (i.e., hurricanes) to help generate forecasts. The first, TRMM (Tropical Rainfall Measuring Mission), focuses on the intensity of tropical rainfall, which is indicative of whether a cyclone is weakening or strengthening. It also is valuable in improving hurricane track forecasting through the integration of its rainfall measurements into hurricane forecast computer models. The second, QuikSCAT, contains a scatterometer that measures both the speed and direction of winds near the ocean surface.

The figure shows how the elements of a hurricane prediction mission thread interact. This thread only deals with determination of intensity and tracks of hurricanes and typhoons. Many other observatories, models, and decision-support tools are involved in disaster management.

It is often the case that spacecraft are examined to determine whether they should remain in orbit for an extended mission life. Suppose an analyst were examining the TRMM and QuikSCAT satellites and needed to determine which elements were related to these missions. Within seconds, the model would present the information in a manner that allows the user to investigate the data products generated by each satellite and how these affect Earth-system models downstream. As it turns out, there are nine decision-support tools involved with these two missions. The analyst can determine the potential outcomes from making decisions with these tools and identify the expected societal benefits. The model also addresses particular science questions, and this information can be extracted and exported.

This visualization greatly enhances the suitability of this information in addressing enterprise management issues and provides a rationale to support solid business decisions such as funding for a new spacecraft, modification to ground processing algorithms, or different data archiving schemes. The visualization shows the operational requirements from other government agencies that can potentially use the results of NASA research. There is a research-to-operations initiative that will use this tool to determine how best to transition research results to operations.

Summary

Enterprise architecture tools and techniques are useful for helping high-level managers understand the elements of the enterprise they manage. Systems engineering traditionally operates within system development projects; however, based on its normal toolbox of techniques, systems engineering has much to offer at the enterprise level, too. Of course, systems engineers must learn to look beyond their traditional mind set of gathering requirements and allocating these to system components. The "system" of interest in this case is the entire enterprise, and often this enterprise can truly be global in scale.