Bidders Library Interoperability Test and Evaluation - DoDAF v2-02.pdf

DoDAF Architecture Framework Version 2.02 http://cio-nii.defense.gov/sites/dodaf20/index.html[3/3/2011 3:33:35 PM]

Home DoDAF-DM2 WG DoDAF Journal DoD Meta Data Registry IDEAS Links

The DoDAF Architecture Framework Version 2.02 Welcome to DoDAF Version 2.02! This is the official and current version for the Department of Defense Architecture Framework.

Version 2.02

This is the current release of DoDAF as of August 2010.

A PDF version of this website is produced periodically and can be downloaded here: DoDAF 2.02.pdf

For a description of changes made to DoDAF/DM2

2.01 to create DoDAF/DM2 2.02, download the Version Description Document here.

DoDAF Conformance

DoD Components are expected to conform to DoDAF to the maximum extent possible in development of architectures within the Department. Conformance ensures that reuse of information, architecture artifacts, models, and viewpoints can be shared with common understanding. Conformance is expected in both the classified and unclassified communities, and further guidance will be forthcoming on specific processes and procedures for the classified architecture development efforts in the Department.

DoDAF conformance is achieved when:

The data in a described architecture is defined according to the DM2 concepts, associations, and attributes.

The architectural data is capable of transfer in accordance with the PES.

DoDAF Journal

The DoDAF Journal is a community of interest based discussion board. The Journal includes descriptions of best practices, lessons learned, example views and DM2 datasets, DoDAF model templates, DoDAF meeting presentations, and tutorial materials, and reference documents. It can be used by reference, component, capability, segment, and solution architects and core process stakeholders. Any member of the DoDAF community may submit material for publication and an editorial board will work with the authors to determine appropriateness, ensure public releasability, and make any needed changes to content.

Contact Information

For any general enquiries, please contact us via the general enquiry mailboxes listed on our contact page.

Background

Architecture Development

Meta Model

Viewpoints & Models

Presentation Techniques

Configuration Management Overview

Acronyms List and Glossary of Terms

Site Map

Archives

Department of Defense http://www.silverbulletinc.com/dodaf-dm2 https://metadata.dod.mil/mdr/ http://www.ideasgroup.org/ http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_v2-02_web.pdf http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_v2-02_web.pdf http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF-DM2_v2-02_VDD.pdf http://cio-nii.defense.gov/sites/dodaf20/introduction.html http://cio-nii.defense.gov/sites/dodaf20/introduction.html http://cio-nii.defense.gov/sites/dodaf20/introduction.html http://www.dodenterprisearchitecture.org/ http://www.defenselink.mil/cio-nii/

DoDAF Architecture Framework Version 2.02 http://cio-nii.defense.gov/sites/dodaf20/index.html[3/3/2011 3:33:35 PM]

Go to top of page ↑

Privacy Policy | Web Policy | Contacts http://cio-nii.defense.gov/other/privacy.shtml http://www.defense.gov/webmasters/policy/dod_web_policy_12071998_with_amendments_and_corrections.html

DoDAF Introduction http://cio-nii.defense.gov/sites/dodaf20/background.html[3/3/2011 3:33:50 PM]

Introduction The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries.

The DoDAF serves as one of the principal pillars supporting the DoD Chief Information Officer (CIO) in his responsibilities for development and maintenance of architectures required under the Clinger-Cohen Act. DoDAF is prescribed for the use and development of Architectural Descriptions in the Department. It also provides extensive guidance on the development of architectures supporting the adoption and execution of Net-centric services within the Department.

DoD managers, as process owners, specify the requirements and control the development of architectures within their areas of authority and responsibility. They select an architect and an architecture development team to create the architecture in accordance with the requirements they define.

DoD Components are expected to conform to the DoDAF developing architectures within the Department. DoDAF Conformance ensures reuse of information and that architecture artifacts, models, and viewpoints can be shared with common understanding.

DoDAF V2.0 focuses on architectural "data", rather than on developing individual "products" as described in previous versions. In general, data can be collected, organized, and stored by a wide range of architecture tools developed by commercial sources. It is anticipated that these tools will adopt the DM2 PES for the exchange of architectural data.

DoDAF V2.0 provides a Data Capture Method for each data group of the DM2 to guide architects in collecting and organizing the necessary architectural data.

The DoDAF enables architectural content that is "Fit-for-Purpose" as an architectural description consistent with specific project or mission objectives. Because the techniques of architectural description can be applied at myriad levels of an enterprise, the purpose or use of an architectural description at each level will be different in content, structure, and level of detail. Tailoring the architectural description development to address specific, well-articulated, and understood purposes, will help ensure the necessary data is collected at the appropriate level of detail to support specific decisions or objectives.

Visualizing architectural data is accomplished through models (e.g., the products described in previous versions of DoDAF). Models can be documents, spreadsheets, dashboards, or other graphical representations and serve as a template for organizing and displaying data in a more easily understood format. When data is collected and presented as a "filled-in" model, the result is called a view. Organized collections of views (often representing processes, systems, services, standards, etc.) are referred to as viewpoints, and with appropriate definitions are collectively called the Architectural Description.

DoDAF V2.0 discusses DoDAF-described Models and Fit-for-Purpose Views:

DoDAF-described Models (also referred to as Models) are created from the subset of data for a particular purpose. Once the DoDAF-described Models are populated with data, these "views" are useful as examples for presentation purposes, and can be used as described, modified, or tailored as needed.

Background

Six Core Processes DoDAF Supports

DM2 Support for the Six Core Processes DoDAF Supports

What is New in DoDAF V2.0

Architecture Development

Meta Model

Viewpoints & Models

Presentation Techniques

Configuration Management Overview

Acronyms List and Glossary of Terms http://www.silverbulletinc.com/dodaf-dm2 https://metadata.dod.mil/mdr/ http://www.ideasgroup.org/ http://cio-nii.defense.gov/sites/dodaf20/products/DM2_Data_Dictionary_and_Mappings_v202.xls http://cio-nii.defense.gov/sites/dodaf20/introduction.html http://cio-nii.defense.gov/sites/dodaf20/introduction.html http://cio-nii.defense.gov/sites/dodaf20/introduction.html

Fit-for-Purpose Views are user-defined views of a subset of architectural data created for some specific purpose (i.e., "Fit-for-Purpose"). While these views are not described or defined in DoDAF, they can be created, as needed, to ensure that presentation of architectural data is easily understood. This enables organizations to use their own established presentation preferences in their deliberations.

The models described in DoDAF, including those that are legacies from previous versions of the Framework, are provided as pre-defined examples that can be used when developing presentations of architectural data.

Specific DoDAF-described Models for a particular purpose are prescribed by process-owners.

All the DoDAF-described Models do not have to be created. If an activity model is created, a necessary set of data for the activity model is required. Key process owners will decide what architectural data is required, generally through DoDAF-described Models or Fit-for-Purpose Views. However, other regulations and instructions from the DoD and the Chairman, Joint Chiefs of Staff (CJCS) have particular presentation view requirements.

The architect and stakeholders select views to ensure that the Architectural Descriptions will support current and future states of the process or activity under review. Selecting Architecture Viewpoints carefully ensures that the views adequately frame concerns, e.g., by explaining the requirements and proposed solutions, in ways that enhance audience understanding.

DoDAF also serves as the principal guide for development of integrated architectures as defined in DoD Instruction 4630.8, which defines an integrated architecture as "An architecture consisting of multiples views or perspectives facilitating integration and promoting interoperability across capabilities and among integrated architectures". The term integrated means that data required in more than one instance in architectural views is commonly understood across those views.

The DM2 provides information needed to collect, organize, and store data in a way easily understood.

The DM2 replaces the Core Architecture Data Model (CADM) which supported previous versions of the DoDAF. DM2 is a data construct that facilitates reader understanding of the use of data within an architecture document. CADM can continue to be used in support of architectures created in previous versions of DoDAF. NOTE: DoDAF V2.0 does NOT prescribe a Physical Data Model (PDM), leaving that task to software developers who will implement the principles and practices of DoDAF in their own software offerings.

DoDAF V2.0 is a marked change from earlier versions of Command, Control, Communications, Computers, and Intelligence Surveillance Reconnaissance Architecture Framework (C4ISR AF) or DoDAF, in that architects now have the freedom to create enterprise architectures to meet the demands of their customers. The core of DoDAF V2.0 is a data-centric approach where the creation of architectures to support decision-making is secondary to the collection, storage, and maintenance of data needed to make efficient and effective decisions. The architect and stakeholders select views to ensure that architectures will explain current and future states of the process or activity under review. Selecting architectural views carefully ensures that they adequately explain the requirement and proposed solution in ways that will enhance audience understanding.

DoDAF V2.0 also provides, but does not require, a particular methodology in architecture development. It provides guidance and suggestions on how to ensure that other proposed methods can be adapted as needed to meet the DoD requirements for data collection and storage. Similarly, the views presented in DoDAF are examples, intended to serve as a possible visualization of a particular view. DoDAF V2.0 also continues providing support for views (i.e., 'products' developed in previous versions of the Framework). These views do not require any particular graphical design by toolset vendors.

Authority: Law and Policy DoDAF Supports

Federal law and policies have expressed the need for architectures in support of business http://www.dtic.mil/whs/directives/corres/pdf/463008p.pdf http://cio-nii.defense.gov/sites/dodaf20/products/DM2_Data_Dictionary_and_Mappings_v202.xls http://cio-nii.defense.gov/sites/dodaf20/products/DM2_Data_Dictionary_and_Mappings_v202.xls http://cio-nii.defense.gov/sites/dodaf20/products/DM2_Data_Dictionary_and_Mappings_v202.xls decisions.

Policy/Guidance Description

Clinger-Cohen Act of 1996

Recognizes the need for Federal Agencies to improve the way they select and manage IT resources and states, “information technology architecture, with respect to an executive agency, means an integrated framework for evolving or maintaining IT and acquiring new IT to achieve the agency’s strategic goals and information resources management goals.” Chief Information Officers are assigned the responsibility for “developing, maintaining, and facilitating the implementation of a sound and integrated IT architecture for the executive agency”.

E-Government Act of 2002

Calls for the development of Enterprise Architecture to aid in enhancing the management and promotion of electronic government services and processes.

Office of Management and Budget Circular A-130

“Establishes policy for the management of Federal information resources” and calls for the use of Enterprise Architectures to support capital planning and investment control processes. Includes implementation principles and guidelines for creating and maintaining Enterprise Architectures.

OMB Federal Enterprise Architecture Reference Models

(FEA RM)

Facilitates cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. Alignment with the reference models ensures that important elements of the FEA are described in a common and consistent way. The DoD Enterprise Architecture Reference Models are aligned with the FEA RM.

OMB Enterprise Architecture Assessment Framework

(EAAF)

Serves as the basis for enterprise architecture maturity assessments.

Compliance with the EAAF ensures that enterprise architectures are advanced and appropriately developed to improve the performance of information resource management and IT investment decision making.

General Accounting Office Enterprise Architecture Management Maturity Framework

(EAMMF)

“Outlines the steps toward achieving a stable and mature process for managing the development, maintenance, and implementation of enterprise architecture.” Using the EAMMF allows managers to determine what steps are needed for improving architecture management.

Six Core Processes DoDAF Supports

Organizations within the DoD may define local change management processes, supportable by Architectural Descriptions, while adhering to defined decision support processes mandated by the Department, including JCIDS, the DAS, SE, PPBE, Net-centric Integration, and PfM.

These key support processes are designed to provide uniform, mandated, processes in critical decision-making areas, supplemented by individual agency operations, defined by Architectural Descriptions tailored to support those decisions-making requirements.

Joint Capability Integration and Development System http://cio-nii.defense.gov/docs/ciodesrefvolone.pdf http://cio-nii.defense.gov/docs/ciodesrefvolone.pdf http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_public_laws&docid=f:publ347.107.pdf http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_public_laws&docid=f:publ347.107.pdf http://www.whitehouse.gov/sites/default/files/omb/assets/omb/circulars/a130/a130trans4.pdf http://www.whitehouse.gov/sites/default/files/omb/assets/omb/circulars/a130/a130trans4.pdf http://www.whitehouse.gov/sites/default/files/omb/assets/omb/circulars/a130/a130trans4.pdf http://www.whitehouse.gov/sites/default/files/omb/assets/omb/circulars/a130/a130trans4.pdf http://www.whitehouse.gov/omb/e-gov/eaaf http://www.whitehouse.gov/omb/e-gov/eaaf http://www.whitehouse.gov/omb/e-gov/eaaf http://www.whitehouse.gov/omb/e-gov/eaaf http://www.whitehouse.gov/omb/e-gov/eaaf

The primary objective of the JCIDS process is to ensure warfighters receive the capabilities required to execute their assigned missions successfully. JCIDS defines a collaborative process that utilizes joint concepts and integrated Architectural Descriptions to identify prioritized capability gaps and integrated joint Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities (DOTMLPF) and policy approaches (materiel and non-materiel) to resolve those gaps. JCIDS implements an integrated, collaborative process to guide development of new capabilities through changes in joint DOTMLPF and policy.

JCIDS process owners have written policy to support architecture requirements (i.e., specific product sets required in specific documents, such as the Information Support Plan, Capability Development Document, and Capability Production Document) that permits components and lower echelon commands to invoke the JCIDS process for requirements at all levels.

Defense Acquisition System

The DAS exists to manage the nation’s investments in technologies, programs, and product support necessary to achieve the National Security Strategy and support employment and maintenance of the United States Armed Forces. The DAS uses Joint Concepts, integrated architectures, and DOTMLPF analysis in an integrated, collaborative process to ensure that desired capabilities are supported by affordable systems and other resources.

DoD Directive 5000.1 provides the policies and principles that govern the DAS. In turn, DoD Instruction 5000.2, Operation of the DAS establishes the management framework for translating mission needs and technology opportunities, based on approved mission needs and requirements, into stable, affordable, and well-managed acquisition programs that include weapon systems and automated information systems (AISs). The Defense Acquisition Management Framework provides an event-based process where acquisition programs advance through a series of milestones associated with significant program phases.

The USD (AT&L) leads the development of integrated plans or roadmaps using integrated architectures as its base. DoD organizations use these roadmaps to conduct capability assessments, guide systems development, and define the associated investment plans as the basis for aligning resources and as an input to the Defense Planning Guidance (DPG), Program Objective Memorandum (POM) development, and Program and Budget Reviews.

Systems Engineering

DoD Acquisition policy directs all programs responding to a capabilities or requirements document, regardless of acquisition category, to apply a robust SE approach that balances total system performance and total cost with the family-of-systems, and system-of-systems context. Programs develop a Systems Engineering Plan (SEP) for Milestone Decision Authority (MDA) that describes the program’s overall technical approach, including activities, resources, measures (metrics), and applicable performance incentives.

SE processes are applied to allow an orderly progression from one level of development to the next detailed level using controlled baselines. These processes are used for the system, subsystems, and system components as well as for the supporting or enabling systems used for the production, operation, training, support, and disposal of that system. Execution of technical management processes and activities, such as trade studies or risk management activities may point to specific requirements, interfaces, or design solutions as non-optimal and suggest change to increase system-wide performance, achieve cost savings, or meet scheduling deadlines.

Architecture supports SE by providing a structured approach to document design and development decisions based on established requirements.

Planning, Programming, Budgeting, and Execution

The PPBE process allocates resources within the DoD and establishes a framework and process for decision-making on future programs. PPBE is a systematic process that guides DoD’s strategy development, identification of needs for military capabilities, program planning, resource estimation, and allocation, acquisition, and other decision processes.

JCIDS is a key supporting process for PPBE, providing prioritization and affordability advice.

DoDAF V2.0 supports the PPBE process by identifying the touch points between architecture and the PPBE process, identifying the data to be captured within an Architectural Description, facilitating informed decision-making, and identifying ways of presenting data to various stakeholders/roles in the PPBE decision process.

Portfolio Management

DoD policy requires that IT investments be managed as portfolios to ensure IT investments support the Department’s vision, mission, and goals; ensure efficient and effective delivery of capabilities to the Warfighter; and maximize return on investment within the enterprise.

Each portfolio may be managed using the architectural plans, risk management techniques, capability goals and objectives, and performance measures. Capability architecting is done primarily to support the definition of capability requirements. PfM uses the Architectural Description to analyze decisions on fielding or analysis of a needed capability.

Architectural support to PfM tends to focus on the investment decision itself (although not exclusively), and assists in justifying investments, evaluating the risk, and providing a capability gap analysis.

Operations

In most cases, an enterprise will capture its routine or repeatable business and mission operations as architectural content. However, when the basic structure of an activity is very stable and the activity repeated often, such as military operations planning or project definition and management, the enterprise may choose to include that structure as part of the Architectural Description itself. In this case, the architecture repository may be enhanced to include templates, checklists, and other artifacts commonly used to support the activity.

The JCIDS, PPBE, and DAS processes establish a knowledge-based approach, which requires program managers to attain the right knowledge at critical junctures to make informed program decisions throughout the acquisition process. The DoD IT PfM process continues to evolve that approach with emphasis on individual systems and/or services designed to improve overall mission capability. Consistent with OMB Capital Planning and Investment Control (CPIC) guidance, the DoD uses four continuous integrated activities to manage its portfolios – analysis, selection, control, and evaluation. The overall process is iterative, with results being fed back into the system to guide future decisions.

Go to top of page ↑

DM2 Support for the Six Core Processes DoDAF Supports

The DoDAF V2.0 Meta-model Groups support the viewpoints and DoD Key Processes of JCIDS, DAS, PPBE, System Engineering, Operations, and Portfolio Management (IT and Capability). The table below indicates a non-inclusive mapping of DoDAF Meta-model Groups to the DoDAF Viewpoints and DoD Key Processes. The support for the Key Processes is for the information requirements that were presented at the workshops for the key processes and, as such, do not reflect all of the information requirements that a key process could need.

DoDAF Meta-model Groups Mapping to Viewpoints and DoD Key Processes

Metamodel Data Groups

View Points DoD Key Processes

AV, CV,

DIV,OV,PV,StdV, SvcV, SV

JCIDS, DAS, PPBE, System Engineering, Operations, Portfolio Management (IT and Capability)

Performer

CV, OV,

PV,StdV, SvcV, J, D, P, S, O, C

SV

Activity OV J, O, C

Resource Flow

AV, CV,

DIV,OV,PV,StdV J, S, O

Data and Information AV, DIV J, D, P, S, O, C

Capability

CV, PV, SV,

SvcV J, D, P, S, O, C

Services CV, StdV, SV P, S, C

Project

AV, CV, PV,

SvcV, SV

D, P, S, C

Training/Skill/Education OV, SV, SvcV, StdV J, S, O

Goals CV, PV J, D, P, O, C

Rules OV, StdV, SvcV, SV

J, D, S, O

Measures SvcV, SV J, D, S, O, C

Location SvcV, SV P, S, O

What is New in DoDAF V2.0

The major changes for DoDAF V2.0 are:

The major emphasis on architecture development has changed from a product-centric process to a data-centric process designed to provide decision-making data organized as information for the manager.

Products have been replaced by views that represent specific types of presentation for architectural data and derived information. With the focus on data, DoDAF V2.0 does not have products but has DoDAF-described Models. Rather than the Operational Viewpoint-5 (OV-5) Operational Activity Model Product, there is the Activity Model with the same supporting data. This is shifting the focus of the architecture effort onto the data early in the Architecture Development Process.

Architecture views are, in turn, organized into viewpoints, which provide a broad understanding of the purpose, objectives, component parts, and capabilities represented by the individual architectural views.

The three major viewpoints of architecture described in previous version (e.g., Operational, Technical, and System) have been changed to more specific viewpoints that relate to the collection of architecture-related data which can be organized as useful information for the manager in decision-making. To support customer requirement and re-organization needs:

All the models of data—conceptual, logical, or physical—have been placed into the Data and Information Viewpoint.

The Technical Standards Viewpoint has been updated to the Standards Viewpoint and can describe business, commercial, and doctrinal standards, in addition to technical standards.

The Operational Viewpoint now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships.

Due to the emphasis within the Department on Capability PfM and feedback from the Acquisition community, the Capability Viewpoint and Project Viewpoint have been added.

System has changed from DoDAF V1.5. System is not just computer hardware and computer software. System is now defined in the general sense of an assemblage of components - machine, human - that perform activities (since they are subtypes of Performer) and are interacting or interdependent. This could be anything, i.e., anything from small pieces of equipment that have interacting or interdependent elements, to Family of Systems (FoS) and System of Systems (SoS). Note that Systems are made up of Materiel (e.g., equipment, aircraft, and vessels) and Personnel Types.

The Department initiatives for Architecture Federation and Tiered Responsibility have been incorporated into Version 2.0.

Requirements for sharing of data and derived information in a Federated environment are described.

Specific types of architecture within the Department have been identified and described (e.g., Department-level [which includes Department, Capability & Component architectures] and Solution Architectures).

The DoD Enterprise Architecture is described.

Linkages to the Federal Enterprise Architecture are defined and described.

Architecture constructs originally described in the UK Ministry of Defence Architecture Framework (MODAF), the NATO Architecture Framework (NAF), and the Open Group Architecture Framework (TOGAF) are adopted for use within DoDAF.

A DoDAF Meta-model (DM2), containing a Conceptual Data Model (CDM), a Logical Data Model (LDM), and a Physical Exchange Specification (PES) has been created.

Approaches to SOA development are described and discussed.

For the architect, DoDAF V2.0 changes the focus of the Architecture Development Process are described in “What Does the Architect Need to Do”? The basis of the Architecture Development Process is now the Data Meta-model Groups, described in the LDM.

To align with ISO Standards, where appropriate, the terminology has changed from Views to Viewpoint (e.g., the Operational View is now the Operational Viewpoint).

DoDAF can capture the security markings and is described in the PES. In addition, a discussion of the security characteristics mapped to the DoDAF Concepts has been added.

In DoDAF V1.5 and previous versions, Nodes are logical concepts that caused issues in the exchange and discussion of architectures. In one architecture that was reviewed, Operational Nodes mapped to System, Organization, Person Type, Facility, Materiel, and Installation. Within the same architecture, System Node maps to System, Materiel, Organization, and Location. The overlap Organizational and System nodes (System, Organization, Material) illustrates the complexity of trying to define Nodes.

The concrete concepts of Node (including Activities, System, Organization, Person Type, Facility, Location, Materiel, and Installation) were incorporated into the DoDAF Meta-model. Since Nodes are logical concepts that could be used to represent the more concrete concepts of activities, systems, organizations, personnel types, facilities, locations, materiels, and installations or combinations of those things, DoDAF V2.0 focuses on those concrete concepts. There will not be a mapping of Node to the DoDAF V2.0 Meta-model Groups, concepts, classes, or associations. For the architect, there are some changes in architecture development:

When appropriate, DoDAF V1.0 and V1.5 architectures that use the Node concept will need to update the architecture to express the concrete concepts in place of the abstract concept that Node represents. When pre-DoDAF V2.0 architecture is compared with DoDAF V2.0 architecture, the concrete concepts that Node represents must be defined for the newer architecture.

DoDAF V2.0 architectures will need to express the concrete concepts (activities, systems, organizations, personnel types, facilities, locations, materiels, and installations, etc.).

http://cio-nii.defense.gov/sites/dodaf20/architect.html http://cio-nii.defense.gov/sites/dodaf20/security.html http://www.defense.gov/webmasters/policy/dod_web_policy_12071998_with_amendments_and_corrections.html

DoDAF Architecture Development - 6 Step Process http://cio-nii.defense.gov/sites/dodaf20/arch_development.html[3/3/2011 3:33:54 PM]

6-Step Architecture Development Process

Architecture Development 6-Step Process

Step 1: Determine Intended Use of Architecture Step 2: Determine Scope of Architecture Step 3: Determine Data Required to Support Architecture Development Step 4: Collect, Organize, Correlate, and Store Architectural Data Step 5: Conduct Analyses in Support of Architecture Objectives Step 6: Document Results in Accordance with Decision-Maker Needs

The high-level, 6-step architecture development process provides guidance to the architect and Architectural Description development team and emphasizes the guiding principles. The process is data-centric rather than product-centric (e.g., it emphasizes focus on data, and relationships among and between data, rather than DoDAF V1.0 or V1.5 products). This data-centric approach ensures concordance between views in the Architectural Description while ensuring that all essential data relationships are captured to support a wide variety of analysis tasks. The views created as a result of the architecture development process provide visual renderings of the underlying architectural data and convey information of interest from the Architectural Description needed by specific user communities or decision makers. The figure above depicts this 6-step process.

Background

Architecture Development

Meta Model

Viewpoints & Models

Presentation Techniques

Configuration Management Overview

Acronyms List and Glossary of Terms http://www.silverbulletinc.com/dodaf-dm2 https://metadata.dod.mil/mdr/ http://www.ideasgroup.org/ http://cio-nii.defense.gov/sites/dodaf20/introduction.html http://cio-nii.defense.gov/sites/dodaf20/introduction.html

NOTE: It is important to note that the development of Architectural Description is an iterative process and a unique one, in that every Architectural Description is:

Different in that architecture creation serves a specific purpose, and is created from a particular viewpoint.

Serving differing requirements, necessitating different types of views to represent the collected data.

Representative of a 'snapshot in time' (e.g., the Architectural Description may represent the current view or baseline, or it may represent a desired view in some future time).

Changeable over time as requirements become more focused or additional knowledge about a process or requirement becomes known.

The methodology described below is designed to cover the broadest possible set of circumstances, and also to focus on the most commonly used steps by the architecture community.

Step 1: Determine Intended Use of Architecture. Defines the purpose and intended use of the architecture ("Fit-for-Purpose"); how the Architectural Description effort will be conducted; the methods to be used in architecture development; the data categories needed; the potential impact on others; and the process by which success of the effort will be measured in terms of performance and customer satisfaction. This information is generally provided by the process owner to support architecture development describing some aspect of their area of responsibility (process, activity, etc.).

A template for collection of high-level information relating to the purpose and scope of the Architectural Description, its glossary, and other information, has been developed for registration of that data in DARS.

Step 2: Determine Scope of Architecture. The scope defines the boundaries that establish the depth and breadth of the Architectural Description and establish the architecture's problem set, helps define its context and defines the level of detail required for the architectural content. While many architecture development efforts are similar in their approach, each effort is also unique in that the desired results or effect may be quite different. As an example, system development efforts generally focus first on process change, and then concentrate on those automated functions supporting work processes or activities. In addition to understanding the process, discovery of these 'system functions' is important in deciding how to proceed with development or purchase of automation support.

Information collected for Architectural Descriptions describing services is similar to information collected for Architectural Descriptions describing systems. For describing services, Architectural Description will collect additional information concerning subscriptions, directory services, distribution channels within the organization, and supporting systems/communications web requirements.

Similar situations occur with Architectural Description development for joint operations. Joint capabilities are defined processes with expected results, and expected execution capability dates. The Architectural Descriptions supporting the development of these types of capabilities usually require the reuse of data already established by the military services and agencies, analyzed, and configured into a new or updated process that provides the desired capability. Included are the processes needed for military service and/or agency response, needed automation support, and a clear definition of both desired result and supporting performance measures (metrics). These types of data are presented in models.

The important concept for this step is the clarity of scope of effort defined for the project that enables an expected result. Broad scoping or unclear definition of the problem can delay or prevent success. The process owner has the primary responsibility for ensuring that the scoping is correct, and that the project can be successfully completed.

Clarity of scope can better be determined by defining and describing the data to be used in the proposed Architectural Description in advance of the creation of views that present https://dars1.army.mil/ desired data in a format useful to managers. Early identification of needed data, particularly data about the Architectural Description itself, the subject-matter of the proposed Architectural Description, and a review of existing data from COIs, can provide a rich source for ensuring that Architectural Descriptions, when developed, are consistent with other existing Architectural Descriptions. It also ensures conformance with any data-sharing requirements within the Department or individual COIs, and conformant with the DM2.

An important consideration beginning with this and each subsequent step of the architecture development process is the continual collection and recording of a consistent, harmonized, and common vocabulary. The collection of terms should continue throughout the architecture development process. As architectural data is identified to help clarify the appropriate scope of the architecture effort, vocabulary terms and definitions should be disambiguated, harmonized, and recorded in a consistent AV-2 process documented in the "DoDAF V2.0 Architecture Development Process for the DoDAF-described Models" Microsoft Project Plan.

Analysis of vocabularies across different Architectural Descriptions with similar scope may help to clarify and determine appropriate Architectural Description scope. Specific examples of data identification utilizing the AV-2 Data Dictionary construct are found in the DoDAF Journal.

Step 3: Determine Data Required to Support Architecture Development. The required level of detail to be captured for each of the data entities and attributes is determined through the analysis of the process undergoing review conducted during the scoping in Step

2. This includes the data identified as needed for execution of the process, and other data required to effect change in the current process, (e.g., administrative data required by the organization to document the Architectural Description effort). These considerations establish the type of data collected in Step 4, which relate to the architectural structure, and the depth of detail required.

The initial type of architectural data content to be collected is determined by the established scope of the Architectural Description, and recorded as attributes, associations, and concepts as described in the DM2. A mapping from DM2 concepts, associations, and attributes to architecture models suggests relevant architectural views the architect may develop (using associated architecture techniques) during the more comprehensive and coherent data collection of Step 4. This step is normally completed in conjunction with Step 4, a bottom-up approach to organized data collection, and Architectural Description development typically iterates over these two steps. As initial data content is scoped, additional data scope may be suggested by the more comprehensive content of Architectural Views desired for presentation or decision-making purposes.

This step can often be simplified through reuse of data previously collected by others, but relevant to the current effort. Access to appropriate COI data and other architecture information, discoverable via DARS and the DMR, can provide information on data and other architectural views that may provide useful in a current effort.

Work is presently underway within the Department to ensure uniform representation for the same semantic content within architecture modeling, called Architecture Modeling Primitives.

The Architecture Modeling Primitives, hereafter referred to as Primitives, will be a standard set of modeling elements, and associated symbols mapped to DM2 concepts and applied to modeling techniques. Using the Primitives to support the collection of architecture content and, in concert with the PES, will aid in generating common understanding and communication among architects in regard to architectural views. As the Primitives concepts are applied to more modeling techniques, they will be updated in the DoDAF Journal and details provided in subsequent releases of DoDAF. When creating an OV-6c in Business Process Modeling Notation (BPMN), the Primitives notation may be used. DoD has created the notation and it is in the DoDAF Journal. The full range of Primitives for views, as with the current BPMN Primitives, will be coordinated for adoption by architecture tool vendors.

Step 4: Collect, Organize, Correlate, and Store Architectural Data. Architects typically collect and organize data through the use of architecture techniques designed to use views (e.g., activity, process, organization, and data models as views) for presentation and decision-making purposes. The architectural data should be stored in a recognized commercial or government architecture tool. Terms and definitions recorded are related to elements of the (DM2).

Designation of a data structure for the Architectural Description effort involves creation of a taxonomy to organize the collected data. This effort can be made considerably simpler by leveraging existing, registered artifacts registered in DARS, to include data taxonomies and data sets. Each COI maintains its registered data on DARS, either directly or through a federated approach. In addition, some organizations, such as U.S. Joint Forces Command (JFCOM), have developed templates, which provide the basis of a customizable solution to common problems, or requirements, which includes datasets already described and registered in the DMR. Examples of this template-based approach are in the DoDAF Journal.

DARS provides more information that is specific, and guidance on retrieving needed data through a discovery process. Once registered data is discovered, the data can be cataloged and organized within a focused taxonomy, facilitating a means to determine what new data is required. New data is defined, registered in DARS, and incorporated into the taxonomy structure to create a complete defined list of required data. The data is arranged for upload to an automated repository to permit subsequent analysis and reuse. Discovery metadata (i.e., the metadata that identifies a specific Architectural Description, its data, views, and usage) should be registered in DARS as soon as it is available to support discovery and enable federation. Architects and data managers should use the DoD EA Business Reference Model (DoD EA BRM) taxonomy elements as the starting point for their registration efforts.

Additional discovery metadata, such as processes and services may be required later, and should follow the same registration process.

Step 5: Conduct Analyses in Support of Architecture Objectives. Architectural data analysis determines the level of adherence to process owner requirements. This step may also identify additional process steps and data collection requirements needed to complete the Architectural Description and better facilitate its intended use. Validation applies the guiding principles, goals, and objectives to the process requirement, as defined by the process owner, along with the published performance measures (metrics), to determine the achieved level of success in the Architectural Description effort. Completion of this step prepares the Architectural Description for approval by the process owner. Changes required from the validation process, result in iteration of the architecture process (repeat steps 3 through 5 as necessary).

Step 6: Document Results in Accordance with Decision-Maker Needs. The final step in the architecture development process involves creation of architectural views based on queries of the underlying data. Presenting the architectural data to varied audiences requires transforming the architectural data into meaningful presentations for decision-makers. This is facilitated by the data requirements determined in Step 3, and the data collection methods employed during Step 4.

DoDAF V2.0 provides for models and views. DoDAF-described Models are those models that enable an architect and development team whose data has already been defined and described consistent with the DM2. The models become views when they are populated with architectural data. These models include those previously described in earlier versions of DoDAF, along with new models incorporated from the MODAF, the NATO NAF, and TOGAF that have relevance to DoD architecture development efforts.

Fit-for-Purpose Views are user-defined views that an architect and development team can create to provide information necessary for decision-making in a format customarily used in an agency. These views should be developed consistent with the DM2, but can be in formats (e.g., dashboards, charts, graphical representations) that are normally used in an agency for briefing and decision purposes. An Architectural Description development effort can result in an Architectural Description that is a combination of DoDAF-described Models and Fit-for- Purpose Views.

DoDAF does not require specific models or views, but suggests that local organizational presentation types that can utilize DoDAF-created data are preferred for management http://www.modaf.org.uk/ http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html presentation. A number of available architecture tools support the creation of views described in this step. The PES provides the format for data sharing.

NOTE: DoDAF V2.0 does NOT prescribe a Physical Data Model, leaving that task to the software developers who will implement the principles and practices of DoDAF in their own software offerings.

Scoping Architectures to be "Fit-for-Purpose"

Establishing the scope of an architecture is critical to ensuring that its purpose and use are consistent with specific project goals and objectives. The term “Fit-for-Purpose” is used in DoDAF to describe an architecture (and its views) that is appropriately focused (i.e., responds to the stated goals and objectives of process owner, is useful in the decision-making process, and responds to internal and external stakeholder concerns. Meeting intended objectives means those actions that either directly support customer needs or improve the overall process undergoing change. The architect is the technical expert who translates the decision-maker’s requirements into a set of data that can be used by engineers to design possible solutions. At each tier of the DoD, goals and objectives, along with corresponding issues that may exist should be addressed according to the established scope and purpose, (e.g., Departmental, Capability, SE, and Operational), as shown in the notional diagram in the figure below.

Establishing the Scope for Architecture Development

Establishing a scope for an architecture effort at any tier is similarly critical in determining the architecture boundaries (Purpose and Use expected), along with establishing the data categories needed for analysis and management decision-making. Scope also defines the key players whose input, advice, and consensus is needed to successfully architect and implement change (i.e., Stakeholders, both internal and external). Importantly, scope also determines the goals and objectives of the effort, consistent with both boundaries and stakeholders; since goals and objectives define both the purpose for architecture creation and the level of the architecture. Establishing the scope of an effort also determines the level of complexity for data collection and information presentation.

Architecture development also requires an understanding of external requirements that may influence architecture creation. An architecture developed for an internal agency purpose still needs to be mappable, and consistent with, higher level architectures, and mappable to the DoD EA. For some architecture developments, consideration must be given in data collection and graphical presentation to satisfaction of other external requirements, such as upward reporting and submission of architectural data and models for program review, funding approval, or budget review due to the sensitivity or dollar value of the proposed solution.

This site contains guidance on data collection for specific views required by instruction, regulation, or other regulatory guidance (i.e., Exhibit 53, or Exhibit 300 submissions; OMB Segment architecture reviews, or interoperability requirements).

Architecture scoping must facilitate alignment with, and support the decision-making process and ultimately mission outcomes and objectives as shown in the figure below. Architectural data and supporting views, created from organizing raw data into useful information, and collected into a useful viewpoint, should enable domain experts, program managers, and decision makers to utilize the architecture to locate, identify, and resolve definitions, properties, facts, constraints, inferences, and issues, both within and across architectural boundaries that are redundant, conflicting, missing, and/or obsolete. DoDAF V2.0 provides the flexibility to develop both Fit-for-Purpose Views (User-developed Views) and views from DoDAF-described Models to maximize the capability for decision-making at all levels. The figure below shows how the development of architectures supports the management decision process. In this case, the example shows how an architecture and the use of it in analysis can facilitate the ability to determine and/or validate mission outcome.

Analysis also uncovers the effect and impact of change (“what if”) when something is redefined, redeployed, deleted, moved, delayed, accelerated, or no longer funded. Having a disciplined process for architecture development in support of analytics will produce quality results, not be prone to misinterpretations, and therefore, be of high value to decision makers and mission outcomes.

Mission Outcomes Supported by Architectures

Enterprise Architecture

“Today, the encouraging coalescence among leaders is that many enterprise systems have the same architectural approach—although not all express it in the same way. A similar convergence addresses the kinds of techniques, pattern, and designs that are independent of specific application domains, and that enable effective production of responsive, scalable, flexible, and unifiable enterprise applications.”

Within DoD, Enterprise Architecture (EA) has been seen for many years as providing product-oriented insight into a wide range of data, programs, and activities, organized through Communities of Interest (COI).