Chapters 12 through 20 provide a detailed look at the DoDAF viewpoints and views and include example views based on our case study from Chapter 3. This chapter provides a quick overview of the DoDAF viewpoints and views that were introduced in Chapter 4, an introduction to the format and content of Chapters 12–20, plus some context for the case study examples. An introduction to the entities of the DoDAF ontology (the DoDAF Metamodel 2, or DM2) is also included to set the stage for view integration discussions that are included in Chapters 12–20. Most of these entities have already been introduced in Chapter 4.

Views, Models, Pictures, and Artifacts

In Chapter 1 we introduced the concept of pictures and drew the distinction between models and pictures. Pictures in themselves are not a universal means of communication, though they are often used to surmount the barriers of the spoken or written language. The symbols and the semantic objects that the symbols represent are not readily understood or obvious unless conventions are used to enforce commonality of interpretation. Architecture frameworks such as the DoDAF, FEAF2, and TOGAF recommend specific types of views to promote commonality of architecture representations. Because these frameworks also tend to be methodology agnostic (they do not prescribe use of any particular methodology that is specific to the framework), they offer a choice of methodologies for constructing the views. For example, enterprises are free to use Business Process Modeling Notation (BPMN) or ICAM Definition for Functional Modeling (IDEF0) to develop OV-5b: Operational Activity Models (DoDAF), a process flow diagram (TOGAF), or a business process diagram (FEAF2).

In Chapter 1, we also introduced the concept of architecture frameworks that comprise multiple viewpoints, each containing multiple views. Viewpoints and views serve to provide representations that answer questions for different groups of stakeholders. The views may also be overlapped to indicate related concerns between two different groups of stakeholders. In Chapters 12–19, we discuss in detail the viewpoints and views of the DoDAF as well as equivalent views within TOGAF and FEAF2. In Chapter 20, we discuss how the standard viewpoints and views within a framework can be extended to incorporate additional viewpoints and views that overlap with the elements of the existing framework.

Tailoring of Views

A view is an architectural representation that addresses the concerns of a specific type of stakeholder. Tailoring a view involves the following:

• Adding properties to specify items such as measures to support the intended analysis for the architecture

• Adding relationships that are required to provide a fuller picture than the basic scope of the view

The availability of a large number of views within an architecture framework discourages tailoring, where one type of view with tailoring may replace another existing view.

The DoDAF allows for definition of custom views, called Fit-for-Purpose (FFP) views that enable architects to combine architecture elements in a manner that serves to explain various aspects of the architecture. A FFP view is not intended to replace the standard views of the DoDAF, nor is it intended to violate the relationships between architecture elements as established in the DoDAF metamodel.

Review of DoDAF Viewpoints and Views

The DoDAF includes eight viewpoints, each of which contains two or more views. These viewpoints are listed here, together with the number of views they contain. The DoDAF also allows for FFP views that are constructed by combining one or more views to provide an aggregated or consolidated picture for stakeholder audiences. This list summarizes the material in Table 4-1 in Chapter 4.

• All Viewpoint   Provides overall information for the architecture, including an executive-level overview and detailed definitions of all terms used in the architecture. This viewpoint is used by all architecture stakeholders. Contains two views.

• Capability Viewpoint   Documents the desired or required capabilities of the enterprise, their relationships, delivery timing, and deployment context, as well as the relationship of capabilities to operational activities and services. This viewpoint is of primary interest to executive management. Contains seven views.

• Project Viewpoint   Documents project portfolios, project interdependencies, and relationships to the capabilities. This viewpoint is of primary interest to executives and business and portfolio managers. Contains three views.

• Operational Viewpoint   Documents both the structural aspects of operational processes and the behavioral aspects of operations in terms of scenarios, rules, and state transitions. This viewpoint is of primary interest to the business manager and operational personnel. Contains six overall views, with views 5 and 6 having subparts.

• Systems Viewpoint   Documents the enterprise’s systems, their functions, their dynamic behaviors, how they are interconnected, what resources they exchange, when they become available, and how they relate to operational activities. This viewpoint is of primary interest to IT personnel. Contains ten views, with views 5 and 10 having subparts.

• Services Viewpoint   Documents the business and IT services of the enterprise, including service functions, service behavior, service interfaces and service level agreements (SLAs), service interconnections, resources exchanged, and time of availability. This viewpoint is of primary interest to business managers (for business services) and IT personnel (for IT services). Contains ten views, with views 3 and 10 having subparts.

• Data and Information Viewpoint   Documents conceptual, logical, and physical models for shared, structured enterprise data. This viewpoint may be of interest to business managers, operational personnel, and IT personnel, depending on the level of detail included. Contains three views.

• Standards Viewpoint   Documents the enterprise technical standards including the systems or services these standards should apply to and the time frames within which the standards should be applied. This viewpoint is of primary interest to IT personnel and to business managers involved in acquisition. Contains two views.

The new Object Management Group (OMG) Unified Architecture Framework (UAF) will be covered briefly in Chapter 20. The new and different viewpoints it appears to contain are based on the ontology the UAF provides. This ontology supports DoDAF and other related defense frameworks, such as the NATO Architectural Framework (NAF), by using appropriate profiles.

Organization of the Viewpoint Chapters

Each of Chapters 12–19 covers a DoDAF viewpoint and contains examples, based on the RMN Airport Case Study, of all the views or subparts in that viewpoint. Each view example includes a discussion of what the view or subpart is used for, what sort of options or tailoring might be used with the view, and how the view should integrate with the other views in the architecture.

View Information at a Glance

A filled-in version of the following table is provided for each view in a viewpoint. The View Short Name area provides the code for the view, such as “CV-1” for the Capability Viewpoint first view, Vision. Remember that the ordering of the views within a viewpoint is arbitrary and has no hidden significance. The Other Names and Alternatives area lists alternative names for the views from DoDAF-related frameworks such as MODAF and similar views from other frameworks such as TOGAF and FEAF2. The Formal Modeling Methodology area provides information on the usual representation technique for the view, including any formal modeling techniques used. The contents of the Integration section is discussed in the following paragraphs.

View Integration

This notion of integration is key to achieving a useful architecture. Integration involves consistency: for example, if you see a view with system entities in it, then any time you see another view with system entities in it, the names of the system entities in both views should be the same or should align in a reasonable manner. If you have two views, say SV-1 and SV-2, and the system names are not the same (or cannot be identified as being the subsets of one another by looking in the AV-2: Integrated Dictionary), then the architecture is not integrated. Nonintegrated views depict disjoint representations of reality and identify a problem with the architecture; until the problem is resolved, the architecture cannot be used for decision-making.

You can use the integration relationships when reviewing architectures for consistency and completeness. When reviewing a specific view, check to see if it is integrated with the other views contained in the architecture as it is supposed to be. If the views aren’t integrated, then there is a consistency problem with the architecture. Similarly, if the architecture, or in some cases an overarching architecture (an enterprise- or segment-level architecture) does not contain any of the other views the specific view is supposed to integrate with, then the architecture is probably incomplete. In other words, the architecture contains at least one view that is not related to any other view in the architecture. The architecture needs to be integrated to present consistent and sufficiently complete information to support decision-making.

Review of Ontology Entities

We introduced the DoDAF ontology—DM2—in Chapter 4 through a series of diagrams (Figures 4-4 through 4-8), which showed the basic entity names and relationships. As a review, we provide a list the DM2 entities (types) here. Their relationships become clear through a study of the views.

The DM2 contains the core concepts of the DoDAF:

• Activity   Work, not specific to a single organization, weapon system, or individual that transforms inputs (resources) into outputs (resources) or changes their state.

• Resource   Data, information, performers, materiel, or personnel types that are produced or consumed.

• Materiel   Equipment, apparatuses, or supplies that are of interest, without distinction as to their application for administrative or combat purposes.

• Information   The state of a something of interest that is materialized—in any medium or form—and communicated or received.

• Data   Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.

• Person Type   A category of persons defined by the role or roles they share that are relevant to an architecture.

• Architectural description   Information describing an architecture, such as OV-5b: Operational Activity Model.

• Performer   Any entity—human, automated, or any aggregation of human and/or automated—that performs an activity and provides a capability.

• Organization   A specific real-world assemblage of people and other resources organized for an ongoing purpose.

• System   A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.

• Service   A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a performer. The capabilities provided are access to resources—information, data, materiel, performers, and locations.

• Capability   The ability to achieve a desired effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.

• Condition   The state of an environment or situation in which a performer performs.

• Desired effect   A desired state of a resource.

• Measure   The magnitude of some attribute of an individual.

• Measure type   A category of measures.

• Location   A point or extent in space that may be referred to physically or logically.

• Guidance   An authoritative statement intended to lead or steer the execution of actions.

• Rule   A principle or condition that governs behavior; a prescribed guide for conduct or action.

• Agreement   A consent among parties regarding the terms and conditions of activities that said parties participate in.

• Standard   A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.

• Project   A temporary endeavor undertaken to create resources or desired effects.

• Vision   An end that describes the future state of the enterprise, without regard to how it is to be achieved; a mental image of what the future will or could be like.

• Skill   The ability, resulting from one’s knowledge, practice, aptitude, and so on, to do something well.

Figure 11-1 shows the conceptual data model for the DM2 that represents these entities in terms of key relationships.

Figure 11-1   Diagram of DIV-1: Conceptual Data Model for DM2 (graphic from the DoDAF)

Case Study Example Context

The view examples in Chapters 12–19 will all be based on the RMN Airport Case Study. The view examples may come from the RMN Airport Enterprise Level architecture, the Passenger Management Segment Level architecture, or the Passenger Identification Solution Level architecture, depending on a level appropriate for the viewpoint or view. So, for example, the Capability Viewpoint and Project Viewpoint view examples will be based on the RMN Airport Enterprise Level architecture. The view examples may be simplified or partial because of space and scope considerations, as many of the complete examples would be large and complex.

Summary

This chapter provides a quick overview of the DoDAF vewipoints and views plus other material that sets the context of and presents the format for material in Chapters 12–20. This additional material includes an overview of the organization of the viewpoints in Chapters 12–20, including a review of the concept of architecture integration; a review of the DoDAF Metamodel entities; and an identification of the specific architecture levels that the view examples in Chapters 12–20 will be drawn from.

References

Department of Defense. 2009. DoD Architecture Framework Version 2.0. “Volume 1: Introduction, Overview, and Concepts.” http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF%20V2%20-%20Volume%201.pdf.

Department of Defense. 2009. DoD Architecture Framework Version 2.0. “Volume 2: Architectural Data and Models.” http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF%20V2%20-%20Volume%202.pdf.

Department of Defense. “DM2 – DoDAF Meta-Model: The DM2 Conceptual Data Model.” http://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_conceptual/. Retrieved on 1/12/2018.