Comprehensive DoDAF Guide

What is DoDAF?

The DoDAF is a system architecture framework developed by the US Undersecretary of Defense for Business Transformation Working Group of the US Department of Defense.

DoD is the acronym for the U.S. Department of Defense. The predecessor of DoDAF is the C4ISR architecture framework. C4ISR is a military term meaning automated command system. It is the abbreviation of the first letter of the English word for seven subsystems in the modern military command system, namely Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance. In layman’s terms, C4ISR is a military automated command system developed by the U.S. military.

DoDAF Framework Evolution

  1. C4ISR AF 1.0 was introduced in June 1996.
  2. C4ISR AF 2.0 was released in December 1997.
  3. DoDAF 1.0 was released in August 2003 to increase the scope of its application, not limited to C4ISR, but can be applied to all mission areas; CADM v1.01 (Core Architecture Data Model) was also released.
  4. In April 2007, DoDAF 1.5 was released, with special emphasis on the Net-Centric concept, and the Net-Centric concept was reflected in the architecture description; CADM v1.5 was also released to store the description file of the new Net-Centric concept.
  5. DoDAF2.0 was released on May 28, 2009.

Compared to previous versions, the main changes in version 2.0 are as follows.

  • The architecture development process shifted from product-centric to data-centric, mainly providing decision data.
  • The three major views (operational, technical, and system) were transformed into more specific views. There are now eight views: full view, data and information view, standard view, capability view, operational view, service view, system view, and project view.
  • Describes the need for data sharing and access to information in a federal environment.
  • Clarified and described the relationship to the Federal Enterprise Architecture.
  • Created a DoD architecture framework metamodel.
  • Described and discussed the methodology for Service Oriented Architecture (SOA) development.

DoDAF Framework Structure

The DoDAF framework can be broadly composed of eight views and implementation methodologies. The eight views are as follows.

  • All Viewpoint, AV: provides information about the entire architecture description, such as the scope and context of the architecture description.
  • Capability Viewpoint, CV: A description of the capabilities that are used to achieve the corporate goals that are consistent with the corporate vision.
  • Data and Information Viewpoint, DIV: The business information requirements and structured business process rules used for the architecture description. It describes information related to the exchange of information in the architecture description, such as attributes, characteristics, and interrelationships.
  • Operational Viewpoint, OV: Describes the organization, tasks or activities, and the information that must be exchanged between them . It conveys the type of information exchanged, the frequency of exchange, the tasks and activities supported by the information exchange, and the nature of the information exchange.
  • Project Viewpoint, PV: Describes how project plans are combined into a portfolio plan with a back-and-forth relationship. This view provides a way to describe the organizational relationships among multiple projects, each of which is responsible for delivering a single system or function.
  • Services Viewpoint, SvcV: Describes the systems, services, and interconnected functions that provide support for operational activities. DoD processes include operational, commercial, intelligence, and infrastructure functions.
  • Standards Viewpoint, StdV: Is the smallest collection of rules that control the combination, interaction, and interdependencies between parts or elements of a system. Its goal is to ensure that the system is capable of meeting a specific set of operational requirements. This view provides technical system implementation guidance upon which engineering specifications can be formed, common modules can be built, and product lines can be developed. It includes technical standards, implementation practices, standard options, rules, and criteria.
  • Systems Viewpoint, SV: Information on automated systems, interconnectivity, and system functionality. In the near future, this viewpoint will disappear as DOD shifts its focus to service-oriented environments and cloud computing.

To maintain consistency and wholeness across views, DoDAF V2.0 defines 52 artifacts to show the entire architecture from requirements to implementation. However, not all artifacts are required and can be used on an as-needed basis.

How to Implement DoDAF?

The DoDAF implementation methodology consists of 6 steps.

1) Define the architecture usage

Define the purpose and intended use of the architecture („fit for purpose”), how the architecture description effort will be conducted, the methods used in the architecture development; the categories of data required, the potential impact on others, and the process for measuring the success of the effort through performance and customer satisfaction. This information is typically provided by the process owner to support the architecture development that describes some aspect of their area of responsibility (process, activity, etc.).

2) Determining the scope of the architecture

Defines the boundaries that establish the depth and breadth of the architecture’s description, establishes the architecture’s problem set, helps define its context, and defines the level of detail required for the architecture’s content. It is also important for deciding how to proceed with development or purchasing automation support.

3) Determine data requirements

The selection of data entities and attributes is important for the architecture to be built in a way that not only meets the goals of the first step, but also maintains the consistency of the architecture. Entities and attributes are represented by data types, which include rules governing business behavior, information about activities to be completed, command relationships, task lists, and many other types.

4) Perform architecture product design

This is the most important step in inputting and editing existing architecture models, collecting new data and adding to the architecture, and extracting data from existing architectures in the DoD System Junction Knowledge Base or related knowledge bases, and then organizing and classifying all data, registering it in DARS (DoD Architecture Registry System), and associating it to an automated repository for subsequent analysis and reuse.

5) Analysis of the architecture

Static analysis, dynamic analysis, experimental analysis, and test analysis are performed on the architecture containing all required data to determine the validity of the architecture data.

6) Generate architecture result files

Generate architecture product descriptions based on basic data queries, which should be consistent with the established model, reusable and shareable.

Impact of DoDAF

Probably from the military, DoDAF does not have as much impact on enterprise architecture as TOGAF. However, with the release of version 2.0, DoDAF framework itself continues to complete, it is no longer only applicable to the military system construction, enterprises can fully flexible to use DoDAF to implement enterprise architecture. In addition, the research on C4ISR and DoDAF has given rise to the „System of Systems” theory, which is a hot topic in academia now. It can be said that DoDAF is one of the most valuable research frameworks in many EA frameworks.

DoDAF Software – Visual Paradigm

Visual Paradigm provides an easy-to-use, model-driven solution that supports the development of DoDAF 2.02 views and models. Create integrated DoDAF products that maintain traceability between views. Generate architecture documents that facilitate organizations to effectively coordinate enterprise architecture initiatives.

DoDAF References

2 komentarze

Leave a Reply

Twój adres e-mail nie zostanie opublikowany.