1.1Semantic Model - Architecture Specification Model

MP 06W0000001
MITRE TECHNICAL REPORT
Tailoring DoDAF For Service Oriented Architectures
A recommended guide for Describing Service Oriented Architectures
January 2006
Huei-Wan Ang
Christopher Bashioum
Fatma Dandashi
William Kirkman
Sponsor: / NII / Contract No.: / ContractNumber
Dept. No.: / W010 / Project No.: / 0706C040NA
Derived By: / N/A / Downgrade To: / N/A
Declassify On: / N/A
The views, opinions and/or findings contained in this report are those of The MITRE Corporation and should not be construed as an official Government position, policy, or decision, unless designated by other documentation. / This document was prepared for authorized distribution only. It has not been approved for public release.
2004 The MITRE Corporation. All Rights Reserved.
Corporate Headquarters
McLean, Virginia

Abstract

This paper describes how to tailor DoDAF for describing an SOA. Beginning with the semantic model used to define our terminology, this paper describes specific SOA characteristics that must be represented in DoDAF products to gain the benefits that SOA will enable. The product descriptions presented in this paper define artifacts useful to enterprise architects who are managing net-centric operations and, consequently, will use terminology best suited for SOAs. It does not apply to all architecture endeavors at all times, and making it that generic would most likely result in some loss of its expected value.

Table of Contents

1Introduction

1.1Semantic Model - Architecture Specification Model

1.2Tailoring the DoDAF Structure

1.2.1Public Key Infrastructure Example

2All View

2.1Overview and Summary Information (AV-1)

2.2Integrated Dictionary (AV-2)

3Operational View

3.1High-Level Operational Concept Graphic (OV-1)

3.2Operational Node Connectivity Description (OV-2)

3.3Operational Product Exchange Matrix (OV-3)

3.4Organizational Relationships Chart (OV-4)

3.5Operational Activity Model (OV-5)

3.6Operational Activity Sequence and Timing Description (OV-6)

3.6.1Operational Rules Model (OV-6a)

3.6.2Operational State Transition Description (OV-6b)

3.6.3Operational Event Trace Description (OV-6c)

3.7Logical Data Model (OV-7)

4Systems View

4.1System Interface Description – (SV-1)

4.2Systems Communication Description – (SV-2)

4.3Systems-Systems Matrix (SV-3)

4.4Systems Functionality Description – (SV-4)

4.5Operational Activity to Systems Function Traceability Matrix – (SV-5)

4.6Systems Data Exchange Matrix – (SV-6)

4.7Systems Performance Parameters Matrix – (SV-7)

4.8Systems Evolution Description – (SV-8)

4.9Systems Technology Forecast – (SV-9)

4.10Systems Functionality Sequence and Timing Descriptions – (SV-10)

4.10.1Systems Rules Model – (SV-10a)

4.10.2Systems State Transition Description – (SV-10b)

4.10.3Systems Event-Trace Description – (SV-10c)

4.11Physical Schema – (SV-11)

4.12Systems Services Definition – (SV-12)

5Technical View

5.1Technical Standards Profile (TV-1)

5.2Technical Standards Forecast (TV-2)

List of Figures

Figure 1. DoDAF for SOA perspective description

Figure 2: DoDAF for SOA perspective to DoDAF product matrix

Figure 3: OV-1 for PKI Architecture

Figure 4: OV-2 (R) showing logical groupings of operational processes and known needlines

Figure 5: OV-4 (R) showing various offices responsible for issuing certificates

Figure 6: OV-5 Context Diagram using IDEF0 Notation.

Figure 7: OV-5 Diagram showing decomposition of the main operational process

Figure 8: OV-6b for Certificate Management Authority

Figure 9: OV-6c showing several process flow diagrams for PKI Administration

Figure 10: OV-7 Showing information entities and relationships

Figure 11: SV-1 (S) showing groupings of human processes and services by physical locations

Figure 12: SV-2 Showing DOD PKI Systems Communication – NIPRNet

Figure 13: SV-4(S) Showing four services for PKI

Figure 14: SV-4 (S) showing the human processes and services that interact with them for registering an applicant

Figure 15: SV-4(I) showing a breakdown of the Register Subject service and Create Token service

Figure 16: SV-4 (I) that shows a Verify Subject service

Figure 17: SV-4 (I) that shows a Revoke service

Figure 18: SV-10b (I) showing valid states for the Verify service

Figure 19: SV-10c (S) Showing human and service registration thread

Figure 20: SV-10c (I) showing details of the Register service thread

Figure 21: SV-10c (S) diagram of the Verify service

Figure 22: Alternative SV-10c (S) diagram of a the Verify service, using sequence diagram notation

Figure 23: SV-10c (I) Showing a Verify service thread

Figure 24: SV-10c (S) of the Revoke service thread

Figure 25: SV-10c (I) Showing a Revoke service thread

Figure 26: SV-12 showing a generic structure for an SDF

List of Tables

Table 1: OV-3 for PKI example

Table 2: Table showing excerpts from relevant PKI standards documents

Table 3: Example OV-6a showing rules for Certificate Management Authority

Table 4: SV-5 (S) showing Operational Processes and corresponding Human Process or Service

Table 5: SV-5 (I) showing Human Processes or Services and corresponding Resources

Table 6: SV-10c implementation rules for Verify Service

Table 7: TV-1 Showing DOD PKI Technical Standards Profile

1Introduction

With acceptance of Network-Centric Warfare (NCW) and “net-centricity” [NCW], the Department of Defense (DoD) is moving towards operational and systems designs based on dynamic producer/consumer models consistent with Service Oriented Architecture (SOA). Further, the underlying model of an SOA is a departure from the point-to-point, system-to-system integration that has tended to dominate DoD (and industry) designs during the past decade. The SOA context changes several of the previously accepted fundamental enterprise integration assumptions, and consequently, the architecture views that we create and the frameworks that describe them must be re-examined, and in some cases redefined. The DoD Architecture Framework (DoDAF) [DoDAF 2004] does not prescribe any particular methodology or process (SOA or otherwise) for creating the actual architecture model, but only the elements and relationships that any given methodology would use. Tailoring of the DoDAF elements and relationships, which DoDAF allows, is necessary to meet the SOA paradigm shift.

AnSOA“is an approach to defining integration architectures based on the concept of a service. It applies successful concepts proved by Object Oriented development, Component Based design, and Enterprise Application Integration technology. The goal of SOA can be described as bringing the benefits of loose coupling and encapsulation to integration at an enterprise level.” [IBM 2004] SOA is a methodology applied when defining architecture primitives or elements, specifically processes and other elements that enable the modular use of human processes and Information Technology (IT) services. SOA presents one approach for defining an architecture, in contrast to defining a particular set of architectural elements that might be used for describing (or presenting) that architecture. This difference allows DoDAF to effectively describe an SOA. However, because DoDAF terminology and descriptions are not defined for SOA, some tailoring is required to better support SOA design patterns within the DoDAF. This tailoring involves some restructuring of DoDAF views. Further, some of the products are labeled essential to describing an SOA, while others are considered “supplementary.”

The following statements frame our general approach:

SOA will become widely adopted throughout organizations in both government and industry. A standardized methodology for applying the DoDAF needs to be established to ensure that these different organizations will develop enterprise architectures that are interoperable.
An architecture framework can be adapted for the decisions it will be used to make. Adapting the DoDAF to accommodate SOA does not violate the rules outlined in DoDAF, nor does it impede interoperability between SOA and non-SOA enterprise architectures.
The general outline of the All View (AV), Operational View (OV), Systems View (SV), and Technical View (TV) is still applicable for SOA. However, we recognize that SOA requires that we apply the principle of "separation of concerns" by defining products in terms of both specification and implementation, and that both of these can be included together in the same architecture description. Therefore, each product was allowed the possibility of having both (although not all architecture descriptions require both).
Examples of DoDAF products tailored for SOA have been developed by these authors for Public Key Infrastructure (PKI) architecture. The example products are for demonstration purposes only and are not intended to be a complete description of the PKI administration architecture as it is being implemented within DoD.

The product descriptions presented in this paper define artifacts useful to enterprise architects who are managing net-centric operations and, consequently, will use terminology best suited for SOAs. It does not apply to all architecture endeavors at all times, and making it that generic would most likely result in some loss of its expected value.

1.1Semantic Model - Architecture Specification Model

The first step toward reliable, mature practice in any discipline is the definition of the fundamental vocabulary, semantics, and models upon which the practice is built and shared. The vocabulary used in this paper comes from the Architecture Specification Model (ASM). ASM [ASM 2005] is a semantic model, which we use as a baseline to tailor DoDAF for SOA. ASM provides a common set of concepts, meanings, or semantics for use by architects in understanding and communicating about architectures. Before entering into our tailoring methods, it is essential to review the terminology we will be using and explain exactly how these terms should be interpreted. We have adopted ASM concepts but created SOA aliases to better align with common SOA terminology. Further, we list here the key terms that are essential to this paper.

Operational Process – An organizational function; the functions supporting the organization’s lines of business. An Operational Process can be comprised of HumanProcesses and/or Services.

Resource – An entity with an ability to accomplish an operational process. The entity can be people and/or equipment.

Human – The resource that performs a Human Process, a person(s).

Asset – The resource that performs a Service, any resource that is not a person, e.g., machines, hardware, software, etc.

Human Process – A sub-category of an Operational Process, those processes performed by Humans

Service – A sub-category of Operational Process; those processes performed by Assets.

Operational Process Specification – The functional requirements of the Operational Process.

Human Process Specification - The functional requirements of the Human Process.

Service Specification - The functional requirements of the Service.

Product: Somethingproduced by human or mechanical effort or by a natural process.

Effect – A change in a condition, behavior, or degree of freedom as a result of an Operational Process.

Node: A logical and/or physical grouping of resources and operational processes.

1.2Tailoring the DoDAF Structure

The most significant tailoring required is to adapt the DoDAF structure to SOA. To accomplish this, we divided both the Operational View and the Systems View into two perspectives. This allows the possibility for the DoDAF products within the Operational and System views to have two distinct parts (although only one may actually apply to a specific product).

The All View will not be impacted by SOA, the Overview and Summary Information (AV-1) and Integrated Dictionary (AV-2) will remain the same as in DoDAF v1.0.

The Operational View focuses on requirements associated with operational processes. These requirements can be grouped into two perspectives, the Functional Specification perspective and the Resource Specification perspective:

The Functional Specification perspective captures the requirements for the “how,” or desired behavior.
The Resource Specification perspective captures the resources responsible for ensuring the behavior is accomplished (as opposed to the resources that actually accomplish the behavior). Note that in this perspective, resources are not differentiated between humans and machines.

The Systems View focuses on the solutions required to accomplish the operational processes. Like the Operational View,the solutions associated with the Systems View can also be grouped into two perspectives, the Solution Specification perspective and theSolution Implementation perspective. Note that in the Systems View, we have expanded the definition of System to include both human and machine (consistent with IEEE 1471), as opposed to limiting System to include only machine as previously defined in DoDAF v1.0.

The Solution Specification perspective captures the allocation of functional requirements (“how”) to the human processes and/or services included in a particular solution, and how the human processes or services satisfy the functional requirements.
The Solution Implementation perspective identifies the human or asset that accomplishes a human process/service, i.e. “who” actually does the work and what human or machine characteristics are actually used to satisfy the requirements.

The Technical Standards View will not be impacted by SOA, the current and emerging standards products will remain the same as in DoDAF v1.0.

Figure 1 specifies DoDAF views and describes the perspectives relevant to each.

Figure 1. DoDAF for SOA perspective description

Because the Operational and Systems views are divided into perspectives, Figure 2 shows which perspectives apply to which DoDAF products within each view (those marked with an “X”). A DoDAF product without an “X” means that the perspective does not apply to that product. A Gray cell means the product is not defined for that view.

Figure 2: DoDAF for SOA perspective to DoDAF product matrix

In an SOA approach, some DoDAF products are essential, while others are supplementary. The following sections describe the products in each of the views and identify them as essential, supplemental (if not specified as essential), or not applicable.

1.2.1Public Key Infrastructure Example

Throughout this paper, we will be using the Department of Defense Public Key Infrastructure (DoD PKI) Architecture as the recurring example of what DoDAF products tailored for SOA should resemble. Example product artifacts will only exist where required to illustrate our tailoring methods. Examples will not necessarily include an entire product, but will include enough detail to properly demonstrate the scope, depth, and breadth of a product.

2All View

Two products are defined in the All-Views section, Overview and Summary Information(AV-1) and Integrated Dictionary (AV-2).

2.1Overview and Summary Information (AV-1)

The Overview and Summary Information provides executive- level summary information in a consistent form that allows quick reference and comparison among architectures. AV-1 includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture.

AV-1 serves two purposes. In the initial phases of architecture development, it serves as a planning guide. Upon completion of an architecture description, AV-1 provides summary textual information concerning the architecture.

2.2Integrated Dictionary (AV-2)

The Integrated Dictionary contains definitions of terms used in the given architecture. It consists of textual definitions in the form of a glossary, a repository of architecture data, their taxonomies, and their metadata (i.e., data about architecture data), including metadata for tailored products, associated with the architecture products developed. Metadata are the architecture data types, possibly expressed in the form of a physical schema. In this document, architecture data types are referred to as architecture data elements.

AV-2 provides a central repository for a given architecture’s data and metadata. AV-2 enables the set of architecture products to stand alone, allowing them to be read and understood with minimal reference to outside resources. AV-2 is an accompanying reference to other products, and its value lies in unambiguous definitions. The key to long-term interoperability can reside in the accuracy and clarity of these definitions.

3Operational View

The Operational View is important to SOA because it shows the business or mission justification for IT investment, and identifies specific business processes that can be automated via services in a SOA. One of the promises of SOA is that it allows for better alignment of IT with business processes. In order to accomplish this alignment, SOA requires that the business processes be both well defined, and defined at a granular enough level to be able to map directly to the services in the Systems View. One of the changes to DoDAF that this document proposes is to rigorously define what goes into the OVs to better enable this alignment.

DoDAF defines the Operational View (OV) as a description of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. DoD missions include both warfighting missions and business missions (processes). The OVs consist of graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges.

Traditionally, the Operational View shows the static information flows between activities and nodes (information exchanges, or IERs). There is no mention of dynamic, ad-hoc information exchanges between activities/nodes based on changing warfighter needs. In SOA, static information flows are of value in that they definea-priori the operational mission and identify some percentage of the mission needs. However,in the Net-Centric world one cannot know ahead of time all possible mission needs. When a pre-defined mission is actually carried out, changes in the operational landscape may dictate information needs that were not known beforehand – perhaps a known operational process needs to occur at a new node, or a given operational process at a given node acquires information from a new information source. The Operational View documents the known business needs that can support a services-oriented paradigm. The Systems View depicts how the known business needs are supported and can also demonstrate the potential/ability to support undocumented/ad-hoc business needs.

The next subsections describe how each of the OV products may be tailored to SOA. For each OV product two perspectives may apply, the functional specification and resource specification perspectives.

3.1High-Level Operational Concept Graphic (OV-1)

The High-Level Operational Concept Graphic sets the context for the architecture being described in the remaining products. It does this by describing a mission and highlighting the main operational nodes (see OV-2 definition) and any interesting or unique aspects of operations. It provides a description of the interactions between the subject architecture and its environment, and between the architecture and external assets. A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary architecture data.