DoDAF 2.0 Viewpoints

DoDAF 2.0 consists of 8 viewpoints (a viewpoint in this context indicates a collection of views, diagrams or models depending upon how you are creating your architecture).

ALL Viewpoint:- Contains the summary information about the architecture being developed including the data dictionary (prefix by AV)

Standards Viewpoint:-Contains all the information relating to the standards that constrain the other 7 viewpoints, they are not necessarily technical standards (prefix by StdV)

Capability Viewpoint:- Capture the capabilities that the enterprise is expected to realize and shows how they are deployed to organizations (prefix by CV)

Operational Viewpoint:- Contains the views required to describe the Operational and high level functional aspects of the architecture (prefix OV), iI is a logical view of the architecture describes WHAT rather then HOW.

Service Viewpoint:- Captures the views required to specify of the Services (i.e. interface, no implementation) required to support the Operational objectives of the architecture (prefix SvcV), Services enable capabilities and can be realized by Systems and People, they are not necessarily Software Services.

Systems Viewpoint:-Captures the specification of the Systems that are required to be implemented or that already exist that help achieve the operational objectives (prefix SV), they can show implementations of services.

Project Viewpoint:- Maps the enterprises to the projects and organizations that will realize the capabilities through the development of systems and services (prefix PV)

View and Viewpoint inter-relationships

The Viewpoints are not independent but are heavily interrelated

• Each face of Cube represents a viewpoint
• Each window a separate view or product
• Model Elements internal to cube used by multiple views
• Views can act as:
  • Filters on the information in the architecture (OV-3, SV-5)
  • Diagrams allowing you to create the information that populates the architecture (SV-1, OV-2)
• The lines between the views show the relationships between elements that appear on the views
• The key elements are the activities as they provide the spine of traceability up and down the architecture

From the diagram above you can see how Capabilities can be traced down through the activities in the OV-5 and SV-4 to the specification of the Systems that implement them in the SV-1

Viewpoint Relationships

DoDAF is a set of traceability matrices:

• Systems and Services support and implement Operational elements
• Services expose capabilities (service as an interface)
• Operational elements (activities) map to capabilities
• Capabilities are delivered by Projects
• Systems and Services are the realized by projects
• Everything constrained by standards

These relationships are captured in the various matrix views:

Ways to use DoDAF

DoDAF can be used in many different ways by many different people, not everyone needs all the views at the same level of detail. Two key ways to use DoDAF is for high level strategic planning (Enterprise Architecture) and as means of defining capabilities, operational planning and the specification of systems and services to realize these capabilities (Solution Architecture).

The Enterprise View of DoDAF

Used by:

• Planning
• JCIDS
• Operations
• Portfolio Management

For:

• Capability Management
• Operations Planning
• Develop high-level requirements for prime suppliers

Still need the:

• All View
• Standards View
• Data and Information Views (subset)

The Systems Engineering View of DoDAF

Used by

• Portfolio management
• Operations planning
• Defense Acquisition System
• Systems Engineering teams: in Forces and Primes/Tier ones
• Provides requirements to engineering teams

Still need the

• All view
• Standards view
• Data and Information views (subset)

Understanding the Relationships in DoDAF

The key elements in DoDAF from an SE perspective are

• The Capabilities that drive the requirements and the projects
  • Based upon supporting Enterprise vision and goals
• The activities that capture the behavior at the various levels
  • The traceability between the these activities and the capabilities
• The various structural elements that perform the activities
  • Performers (OperationalNodes)
  • Resources (Systems, organizations)
  • Services (as an abstraction of the implementation)
• The relationships between the various resources/performers and the information that flows between them

Patterns in the Framework

There are patterns that exist within the framework between the OVs, SVs and SvcVs and that can be mapped using the technique of separation of concerns. In each viewpoint there are views that capture structure, behavior, resource flows between structural elements and traceability. In the diagram below these have been mapped to SysML concepts but there are equally applicable to other formats.

Although sequence diagrams and statemachines are noted here as being supporting views they are much than this as they can be used to define interactions (providing test cases) between operational, systems and service elements and also capture behavior that can be executed in many tools.

Key View Relationships in Systems Engineering

The diagram below shows the views where the elements normally sit that provides the traceability graph through DoDAF

.

The source of an arrow or dashed line is the view where the element is shown

The target of an arrow or dashed line is the view where the element is normally referenced from

e.g. resources flows normally appear in the OV 2 of 4 as relationships between Performers and Organizations but they can be viewed by reference in the OV-3 as a matrix. It is essentially a filtered view of the information contained in the model.

Dashed lines show trace references

Traceability matrices CV-6, CV-7, SV-5a/b, SvcV 5

Structure OV-2, SV-1, SVCV-1

Behavior OV-5,SV-4,ScvV-4

Sequence Diagrams, OV6, SV-10c,SvcV-10c

Info exchanges OV-3,SV-3/6,SvcV-3/6