An overview of UPDM ñ A Unified Profile for DoDAF/MODAF

By	Matthew Hause Artisan Software Tools

The goals of UPDM are to significantly enhance the quality, productivity, and effectiveness associated with enterprise and system-of-systems architecture modeling, promote architecture model reuse and maintainability, improve tool interoperability and communications between stakeholders, and reduce training impact due to different tool implementations and semantics. Using the UML XML Metadata Interchange (XMI) interchange format, virtually all UML tools will be able to exchange models. Standardization of views means that both tool vendors and industry can provide models in a single format. Customized views can still be created, but they are based on core UPDM rather than requiring bespoke development. Finally, the UML/SysML foundation will improve the integration between Architectural Framework modeling and system modeling to support post-acquisition life-cycle design and implementation.

It is important to stress that UPDM is not a new Architectural Framework. Instead, it provides a consistent, standardized means to describe DoDAF and MODAF architectures in UML-based tools as well as a standard for interchange. We will provide an overview of UPDM development, views unfamiliar to DoDAF modelers, and our future goals.

Background to UPDM

Model-based engineering is at the heart of the Architectural Framework approach to modeling. A model of the system is created using different views to denote different stakeholder interests, and to provide a means for evaluation and report generation as well as to simplify maintenance. In the desire to "walk our talk," UPDM is also being developed using a model-driven approach.

In terms of the UPDM work process, a Domain Metamodel (DMM) was created using UML Class models to represent the concepts in DoDAF and MODAF. The DMM was the requirements model for UPDM, and traceability links between the DMM and the UPDM model were created. Concepts common to both DoDAF and MODAF were captured in a core package. The DMM concepts were then mapped to corresponding stereotypes in the Profile, which was analyzed and refactored to reflect language architecture, tool implementation, and reuse considerations. The conformance levels were finalized including mapping to SysML, the Profile diagrams, stereotype descriptions, and documentation were added.

Finally, the specification and XMI document were generated from the Profile model. This model-based approach allowed the team to concentrate on architecture issues rather than documentation production. Consistency was automatically maintained by the UML tool. With every stereotype linked to the DMM element, the UML tool also enabled requirements traceability to be maintained between the Profile and the DMM.

Architectural Frameworks used in UPDM

The core views in DoDAF - All Views, Operational, Systems, and Technical - have been used successfully to define military architectures for some time now. However, system architects found that these views did not go far enough. Although these views are aimed at getting the "big picture" and were sufficient for managing large projects, practitioners found that DoDAF was not actually big enough to properly counter the issue of "stovepipe development". This is where military procurements are developed in isolation from each other rather than in a coordinated manner, resulting in the creation of incompatible and redundant systems, resulting in higher development costs, unnecessary expenditures, and inefficient military operating procedures.

One example of this was a ground support helicopter deployed with a communications system that was incompatible with the ground troopsí radios. This meant that all communication had to be routed through the command base. They also found that DoDAF lacked the breadth necessary for effective program management, where the goal is to specify multiple projects in order to develop compatible capabilities.

Meanwhile, MODAF kept compatibility with the core DoDAF viewpoints in order to facilitate interpretation of architectural information with the U.S. However, MODAF v1.1 added two new viewpoints: the Strategic and Acquisition Viewpoints. These were added to better contribute to MOD processes and life cycles, specifically the analysis of the strategic issues and dependencies across the entire portfolio of available military capabilities within a given timeframe. In MODAF v1.2, Service Views were added to support the development of Service Oriented Architectures (SOA).

In the same way that the DoDAF views are integrated into UPDM, MODAF views are as well. For example, UPDMís Acquisition Views specify when the capabilities defined within the Strategic Views will become available. Capabilities can be associated with capability configurations that define the systems, organizations, and people necessary to achieve the capability. Detailing all of the new views is a task for a book, and not an article. Consequently, we will simply give you an overview of views unfamiliar to DoDAF modelers, and some examples of these views. The following example pertains to a Search and Rescue (SAR) set of capabilities - such as mountain SAR, maritime SAR, battlefield SAR, and so forth - and covers the Capability/Strategic View, the Acquisition View, and the Service-Oriented View.

Capability/Strategic View

The Strategic View provides a high-level view of the enterprise capabilities and their relationships, enabling Capability Management, for example, capability introduction, integration, realignment, and removal. A capability is the ability or capacity to achieve specific objectives. Examples include Search and Rescue, effects delivery, transportation, and so on. A single Strategic View can be defined that will have a number of Architecture Descriptions. Each Architecture Description may then have multiple Operational, System, Technical Standards, and All Views. UPDM comprises six Strategic Views.

The StV-1 Enterprise Vision defines Enterprise Goals and Visions relating to a time-based Enterprise Phase. For example, Figure 1 describes the strategic context for a Search and Rescue (SAR) project. It outlines the vision for a capability area over a specified period of time. It also describes how high-level goals and strategy are to be delivered in terms of capability.

Figure 1 (click graphic to zoom by 2.5x)

The StV-2 Capability Taxonomy defines capabilities for current and future enterprises in a hierarchy and the environmental conditions associated with the different capabilities, while the StV-3 Capability Phasing view shows when capabilities will be available and/or decommissioned over specific periods of time and how they relate to projects. StV-4 Capability Dependencies describes the capabilities in logical groups and the dependencies between the capabilities, and StV-5 - Capability to Organization Deployment Mapping - shows how capabilities map to organizations and the capability configurations that will achieve the capability. Finally, StV-6 Operational Activity to Capability Mapping shows which Operational Activities map to which capabilities.

Acquisition View

The Acquisition View describes project details and dependencies between projects and capability integration. This helps to guide the acquisition and deployment processes. The views are as follows:

• AcV-1 Acquisition Clusters View - This enables the user to model the organizations and projects. It shows the dependencies between the actual organizations that own projects.
• AcV-2 Program Timelines View - This view defines project timelines and their relationship to Capability Configurations. It supports acquisition and deployment including the management of dependencies between projects and the integration of the Defense Lines of Development (DLOD) to achieve a successfully integrated military capability. The DLOD are training, equipment, personnel, information, concepts and doctrine, organization, infrastructure, and logistics. Figure 2 shows AcV-2 Program Timelines View for the SAR project. It details the milestones along with a pie chart showing the DLOD levels of completion.

Figure 2 (click graphic to zoom by 2.5x)

Service-Oriented View

The Service-Oriented View is a description of services needed to directly support the operational domain as described in the Operational View. A service is described as a unit of work through which a particular Resource provides a useful result to a consuming Resource. UPDM services may include standard Web-based services, but also define effects deployment, logistics support, and even cooking meals for hungry soldiers. The resource provides the service, and the consuming resource makes use of it. The Services Views are the following:

• SOV-1 Service Taxonomy - This view describes services in a generalization hierarchy, showing services that are types of other services.
• SOV-2 Service Interface Specification - Describes the provided and required interfaces for services, such as what they will do and what they need.
• SOV-3 Capability to Service Mapping - Displays how services support capabilities. Figure 3 shows a SOV-3 Capability and Service Mapping diagram. It defines the interfaces that will provide access to the services for SAR.

Figure 3 (click graphic to zoom by 2.5x)

• SOV-4a Service Constraints, SOV-4b Service State Model, and SOV-4c Service Interaction Specification - These describe service policies, state-based behavior, and interactions for a service in general.
• SOV-5 Service Functionality - Describes functions and operations that the service will perform.

Future direction of UPDM

The UPDM specification 1.0 was delivered to the Object Management Group (OMG) on August 25, 2008, and was voted on and accepted during the OMG September meeting. Comments from OMG members and the public in general can be sent to the OMG. Once these comments have been addressed, the specification will be voted on again during the OMG December meeting. It will then go through a Finalization Task Force, which will address any problems found during the three-month evaluation period. After this work is complete, it will be voted on to possibly become an adopted specification. Tool vendors, including Artisan Software Tools, have already started implementing UPDM in the expectation of its approval. Implementation will vary, but the intention will be to allow the Profile to provide DoDAF, MODAF, and UPDM compliant models.

However, the work of the UPDM Group will not stop with DoDAF 1.5 and MODAF 1.2. A new initiative will be launched as soon as it is complete to cover other Architectural Frameworks. DoDAF v2.0 will be released in 2009, and the intention is to create a new version of UPDM to maintain exchange compliance. The NATO Architectural Framework (NAF), which is very similar to MODAF v1.2, will also be addressed. Finally, the Security Views in the Canadian DNDAF will be included. While exclusive users of DoDAF may think that this information is irrelevant, they should be aware that many of the views in UPDM will be included in DoDAF v2.0.

For more information on UPDM, visit the Artisan website (www.ArtisanSoftwareTools.com) the UPDM website (www.UPDMGroup.com), or the OMG website (www.OMG.org).

Matthew Hause, chief consultant at Artisan Software Tools and co-chair of the UPDM Group, has been developing real-time systems for almost 30 years. He started out working in the power systems industry, and has been involved in process control, communications, SCADA, distributed control, and many other areas of real-time systems. His roles have varied from project manager to developer. His role at Artisan includes mentoring, sales presentations and training courses. He has written a series of white papers on project management, systems engineering, and systems development with UML, SysML, and Architectural Frameworks. He has been a regular presenter at INCOSE, the IEEE, BCS, the IET, and other conferences. Matthew studied Electrical Engineering at the University of New Mexico and Computer Science at the University of Houston, Texas. He can be contacted at Matthew.Hause@ArtisanSoftwareTools.com.

Artisan Software Tools
+44 (0) 1242 229300
www.ArtisanSoftwareTools.com