In an effort to open the lines of communication among the Navy’s modeling and simulation community and to standardize how models from multiple development teams could be integrated into one or more simulation tools, the Office of Naval Research established the Torpedo Enterprise Advance Modeling and Simulation (TEAMS) program. The TEAMS initiative adopted The Open Group Architecture Framework (TOGAF) as its architecture method and The Object Management Group’s (OMG’s) model-driven architecture (MDA) specifications to standardize how models from multiple development teams could be integrated into one or more simulation tools. This article describes the use of these two very popular and complementary standards that define and implement business integration processes and requirements and discusses the business and IT-level benefits achieved via aligning TOGAF and MDA. As part of this, it will also address the following:

 

  • What benefits does enterprise architecture provide to the business?
  • Is there a proven method for building an effective enterprise architecture practice that is widely adopted?
  • How can IT actively engage the business to deliver ongoing business value?
  • How can IT enable rapid adaptation to continual changes in business and technology?
  • How can an organization support a sustainable enterprise architecture practice using industry standards and appropriate tools?

Several organizations have a long history of developing and continuing to evolve modeling and simulation tools for the U.S. Navy that are used to develop systems and evaluate system performance in a variety of business and technical scenarios. While these organizations developed comparable tools with similar components to satisfy their sponsors’ modeling and simulation needs, there was very little interaction between them as to what tools were available and under which conditions they were best applicable. In addition, several components with similar functionality but varying fidelity were developed in parallel, with no forethought of how to integrate a lower fidelity version with a higher fidelity representation if a sponsor were to desire more realism in a business scenario demanding a system simulation.

 

The Office of Naval Research established the Torpedo Enterprise Advance Modeling and Simulation (TEAMS) program (TEAMS, 2007) to open the lines of communication among the Navy’s modeling and simulation community, and to standardize how models from multiple development teams could be integrated into one or more simulation tools.

 

Two organizations participating in the TEAMS program, the Applied Research Laboratory of The Pennsylvania State University (ARL/PSU) and the Naval Undersea Warfare Center, Division Newport, were tasked to establish an Undersea Warfare M&S Consortium. The Consortium would be responsible for defining and developing a cross-enterprise, collaborative undersea warfare modeling and simulation environment, while utilizing reusable components that can be composed into highly integrated simulations. The simulation environment would be driven by an open systems architecture framework that would result in the sharing and leveraging of both legacy and new-development resources. It would support both the development of modeling and simulation tools and the application of these tools across the lifecycle of undersea weapons.

 

TEAMS and TOGAF

 

Because the Naval Undersea Warfare Center, Division Newport, and ARL/PSU did not have experience developing a collaborative working environment among multiple organizations, they investigated the existence of other consortia to possibly leverage lessons learned. Their search brought them to The Open Group.

 

In the process of learning about Consortium management, the Naval Undersea Warfare Center, Division Newport, and ARL/PSU learned about TOGAF architecture development methodology (ADM). They quickly realized this process was essential to achieving the architecture goals of the TEAMS program.

 

Figure 1, illustrates TOGAF 8.1’s ADM. Details of how TEAMS used this process are provided in subsequent sections.

 

 

TEAMS and MDA

 

The TEAMS consortium used TOGAF ADM as a guideline for developing a conceptual model, taxonomy structure and standard interfaces for models used by the torpedo modeling community. This provided the “how” that TEAMS needed to frame their problem and potential solutions. But they were still missing the “what” to provide the specific representation of the artifacts needed to represent the architecture. TEAMS was dealing in a situation where the concept of “separation of concerns” was immediately evident. There were several specific torpedos (the fired platforms) that needed to be considered. However, the acoustic environment could be identical for each of the torpedo platforms. This led TEAMS to OMG and the separation of concerns concepts inherent in MDA. TEAMS realized that MDA provided an ideal mechanism to map between conceptual models, platform independent models, platform-specific interface implementations and working code. Figure 2 outlines the artifacts necessary to transform from computation independent models to working code.

 

  

The OMG Standard Unified Modeling Language (UML), Software Process Engineering Metamodel (SPEM), and System Modeling Language (SysML) enabled TEAMS to capture detailed descriptions of static and dynamic class relationships, interface requirements, key data types and components needed to create a standardized Undersea Weapon engagement simulation framework. This has facilitated TEAMS developing and integrating reusable components of different acoustic models, torpedo models and simulations.

 

At first, TEAMS primary focus was to only represent their technology architecture using MDA. They used TOGAF to discuss business processes and strategic drivers, but never formally captured the information other than in text. After becoming involved in the TOGAF/MDA synergy project, they quickly realized that several OMG specifications for business models would be invaluable for tracing business requirements through technology description to final software deployment.

 

TOGAF/MDA Synergy Project Background

 

MDA is a model-based, standards-based and tool-supported software engineering approach to developing, manipulating, storing and sharing precise business, technology, services and data models that can eventually result in working systems. Based on years of industry practice and research, MDA is an effort led by the OMG to develop the software specifications necessary to support model-driven business process and software development. In turn, vendors are developing tools based on these specifications that make this approach a reality. MDA offers the standards guiding tool development – the “what” – when developing enterprise architectures but does not address the methodology – the “how” – of developing such architectures. An MDA approach is independent of development methodologies as well as technology. This separation of business functionality from computing technology and methodology preserves a company’s core software assets in the constantly changing world of IT. However, MDA, by design, offers little guidance to the practitioner as that is not its intended purpose.

 

TOGAF is a detailed method for developing an enterprise architecture. Adhering to the definition of framework, TOGAF provides a taxonomy for relating the concepts that describe the real world to the concepts that describe an information system and its implementation. The TOGAF ADM explains how to derive an organization-specific enterprise architecture that addresses business requirements. The ADM provides a reliable, proven way of developing the architecture; architecture views that enable the architect to ensure that a complex set of requirements are adequately addressed; linkages to practical case studies; and guidelines on tools for architecture development. Hence, TOGAF ADM specifies the process – the “how.” While classes of tools are discussed, ADM does not specify how tools are used to derive specific work products nor, more importantly, offers any specifications for the content of the architecture deliverables.

 

After publishing a paper that described and promulgated the enormous synergy that exists within the industry if these concepts are used effectively together, the TOGAF ADM – MDA Synergy Project was formed.

 

TOGAF/MDA Modeling

 

The Synergy Project’s Modeling Work Group has built a formal process model of TOGAF v8.1 ADM using the Software Process Engineering Metamodel (SPEM) version 1.1, an OMG specification for capturing development methods and processes.

 

The SPEM process model is the foundation of many of the Synergy Project’s fundamental objectives, including:

 

  • To map every ADM work product (identified in the SPEM process model) to one or many OMG specifications (and very precisely to specific elements within each specification).
  • To demonstrate the viability of using OMG specifications (such as MDA, UML, SysML, SPEM, Business Motivation Model (BMM), etc.) to describe Open Group standards (i.e., TOGAF and ADM).
  • To identify errors, inconsistencies and gaps in TOGAF 8.1 and opportunities for improvement in future versions of TOGAF.
  • To identify inconsistencies, gaps and errors in OMG specifications and thereby offer improvements in future versions of the specifications.

People applying TOGAF on enterprise architecture projects in the real world want to know:

 

  • “Is there an industry standard specification for the work product I’m trying to produce?”
  • “If so, which specification and which piece of the specification?”
  • “Which tools implement the specification (so I know where to put the work product and in what form)?”
  • “If this work product changes, what ADM activities might we need to revisit (because the work product is used as an input to other activities)?”
  • “What is the relationship between this work product and other ADM work products?”

SPEM Model

 

The foundation of the ADM SPEM model was started by identifying all ADM work products that are represented as inputs and outputs for each phase. These were captured as classes in the SPEM model using its UML profile. Then the behavioral model was built using UML activity diagrams. The ADM SPEM model has detailed activity diagrams for each phase showing the corresponding steps. After the activity diagrams were created, each work product was mapped to one or many OMG specifications and then to one or many specific metaclasses in the respective specification(s). The implied traceability relationships between each work product were determined by analyzing the inputs and outputs of each phase and the mapping of each work product to the selected OMG specification. These traceability relationships were also captured using UML class diagrams.

 

TEAMS Work Products

 

TEAMS architecture vision is “To develop a common technical architecture for torpedo modeling and simulation, including methodologies, tools, standards, and building blocks to build interoperable components, compose simulations quickly at reduced cost, and to support concept assessment, software development, test and evaluation of systems, training, and tactics development.” The scope of the TEAMS technical architecture for a torpedo simulation is limited to “launch-to-hit.”

 

TEAMS’ business goals include interoperable simulation components, documented standards and interface requirements. Paramount is realizing a cost-effective process for achieving interoperability and composability among the Navy’s modeling and simulation tools.

 

The business goal of achieving interoperable simulation components fostered several business processes. The TEAMS Consortium must perform systems engineering to achieve composability, and must implement architecture governance to ensure components generated in the systems engineering process conform to TEAMS open standards for interoperability. As a further example, the business process of simulation must support a torpedo’s ability to be launched, search for and acquire a potential target, home on the correct target and eventually kill, within a realistic acoustic environment. These and the remaining business process, procurement, become the basis of the target business architecture.

 

TEAMS’ technology architecture is the full systems engineering model of a torpedo system, as well as the simulated environment a torpedo model must interact with to satisfy the business requirements for launch-to-hit engagements.

 

Business Driven Integration – TEAMS Integrated Solution

 

The ability to integrate simulation models is exactly what TEAMS was tasked to demonstrate to the torpedo modeling and simulation community. Three models and data sets, developed using non-standard formats by three independent development teams, needed to be integrated into a fourth organization’s simulation to evaluate the effect that a shallow water environment of interest would have on torpedo performance. Models included an ocean environmental data set from the Naval Oceanographic Office, an upgraded model for Ocean Bottom Reflection Loss developed at APL/UW, and a propagation algorithm developed by the Naval Research Laboratory. These three entities are currently being integrated into ARL/PSU’s simulation tool. In addition, Naval Undersea Warfare Center, Division Newport, developed a generic torpedo model from the TEAMS system definitions captured in SysML and UML. TEAMS will also demonstrate that this generic torpedo, based on standard data and application interface definitions, can quickly be incorporated into a simulation tool to assess an ocean environment’s impact on performance.

 

TEAMS’ architecture principles include allowing modelers to develop code in their choice of computer language, allowing model implementers to have a choice of platform-specific implementation options, and ensuring standard interface specifications that TEAMS defines for model components are platform and language independent. For the TEAMS integration task, the environmental data is being delivered through Web services in a compatible format that the simulation tool expects.

 

Going through the exercise of mapping TOGAF ADM work products to elements of OMG specifications was invaluable to TEAMS. The project team gained insight into their requirements, which they were able to formally capture and articulate to stakeholders with multiple views. They also could provide complete requirements traceability from their architecture vision, business processes, and data and applications architectures down to the technology architecture that was developed to demonstrate component interoperability for the torpedo modeling and simulation community.

 

Performing the mapping also provided valuable feedback to the OMG regarding the need for specification support in defining new UML diagram types and in identifying gaps in OMG modeling standards.

 

By using TOGAF ADM to capture architecture vision, principles and requirements, and using OMG specifications to formalize TOGAF’s business processes, data and applications architecture work products, TEAMS produced a roadmap for developing a modeling and simulation technology architecture.

 

As a result, The Navy’s torpedo modeling and simulation community now has a repeatable process for achieving integrated simulation capability, documented using OMG standards. Benefits to the Navy include reduced development time and cost to assess torpedo capability and performance, and a collaborative environment from which to leverage the best technology available. TEAMS is also leaving behind a business model for future cross-organization modeling and simulation-funded efforts outside of the torpedo community whose objective is to achieve interoperability within their modeling and simulation domain area.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access