• DODAF Home 
• Background 
• Architectural Development 
• Meta Model 
  • Conceptual 
  • Logical 
  • PES 
  • IDEAS Foundation Ontology 
• Viewpoints & Models
  • All Viewpoint 
  • Capability Viewpoint 
  • Data and Information Viewpoint 
  • Operational Viewpoint 
  • Project Viewpoint 
  • Services Viewpoint 
  • Standards Viewpoint 
  • Systems Viewpoint 
  • Models 
  • Model Categories
  • Levels of Architecture
  • Architecture Interrogatives 
  • Architecture Modeling Primitives
  • Mapping to DM2 
• Presentation Techniques
  • Composite Views 
  • Fusion Views 
  • Reference Models 
• DODAF-DM2 Configuration Management
• Related Links 
• Acronyms List and Glossary of Terms 
• Site Map 
• Archives

6-Step Architecture Development 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.

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 WMA AFIP (CAC Required).

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 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.

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 WMA AFIP (CAC Required) 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 provided in subsequent releases of DoDAF. When creating an OV-6c in Business Process Modeling Notation (BPMN), the Primitives notation may be used. 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 to include data taxonomies and data sets. Each COI maintains its registered data either directly or through a federated approach. In addition, some organizations 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. 

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 presentation. A number of available architecture tools support the creation of views described in this step. The PES provides the format for data sharing.

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

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). The data-centric approach to DoDAF V2.0 is designed to facilitate the reuse and sharing of COI data. Since DoDAF provides the conceptual, logical, and PES but does not otherwise prescribe the configuration of the product composition, architects and stakeholders are free to create their views of data that best serve their needs.

Introduction and Overview

An Architectural Description is a strategic information asset that describes the current and/or desired relationships between an organization’s business, mission and management processes, and the supporting infrastructure. Architectural Descriptions define a strategy for managing change, along with transitional processes needed to evolve the state of a business or mission to one that is more efficient, effective, current, and capable of providing those actions needed to fulfill its goals and objectives. Architectural Descriptions may illustrate an organization, or a part of it, as it presently exists; any changes desired (whether operational or technology-driven); and the strategies and projects employed to achieve the desired transformation. An Architectural Description also defines principles and goals and sets direction on issues, such as the promotion of interoperability, intra-, and interagency information sharing, and improved processes, that facilitate key DoD program decisions.

Such support extends beyond details or summaries of operational and systems solutions, and includes program plans, programmatic status reporting, financial and budget relationships, and risk management. In addition to detailed views of individual solutions, the framework supports the communication of enterprise-wide views and goals that illustrate the context for those solutions, and the interdependencies among the components. Beyond the solution space, standard mechanisms for communicating program plans, financial information, and project status are established so that executives and managers can evaluate and direct their programs.

The DoD EA is an Architectural Description that is an enterprise asset used to assess alignment with the missions of the DoD enterprise, to strengthen customer support, to support capability portfolio management (PfM), and to ensure that operational goals and strategies are met. The DoD EA is shown below. It is comprised of DoD architecture policy, tools, and standards, DoD-level Architectural Descriptions like the DoD Information Enterprise Architecture (DoD IEA), DoD-level Capability Architectural Descriptions, and Component Architectural Descriptions. Its purposes are to guide investment portfolio strategies and decisions, define capability and interoperability requirements, provide access to Segment architecture information, to establish and enforce standards, guide security and information assurance requirements across the Department of Defense, and provide a sound basis for transition from the existing DoD environment to the future. The DoD EA is a federation of Architectural Descriptions with which Solution Architectural Descriptions must conform. Its content includes but is not limited to rules, standards, services and systems lifecycle information needed to optimize and maintain a process, or part of a process that a self-sufficient organization wants to create and maintain by managing its IT portfolio. The DoD EA provides a strategy that enables the organization to support its current operations while serving as the roadmap for transitioning to its target environment. Transition processes include an organization’s PfM, PPBE, and EA planning processes, along with services and systems lifecycle methodologies.

Components of the DoD EA

The JCA portfolios describe future, required operational, warfighting, business, and Defense intelligence capabilities, together with the systems and services required. They provide the organizing construct for aligning and federating DoD EA content to support the Department portfolio management structure. The description of the future DoD operating environment and associated capability requirements represent the target architecture of the DoD EA. These are time-phased as determined by functional owners and JCA developers.

Migration in a net-centric operating environment from the “As-Is” to the “To-Be” requires that the DoD Information Environment Architecture (DoD IEA) and the Net-Centric strategies act as uniform references for, and guide the transition sequence to ensure that both operational/business capabilities and IT capabilities, as required, are properly described. Policy is being developed by the DoD CIO to describe how federation will be used to mature the DoD EA as well as its relationship to federated, solution Architectural Descriptions.

Transition Planning

As discussed above, one major impetus for creating and using Architectural Descriptions is to guide acquisition and development of new enterprises, capabilities and systems or improvements to existing ones. Earlier versions of DoDAF addressed this need exclusively using “As-Is” and “To-Be” Architectural Descriptions, along with a Systems and/or Services Technology Forecast. The “As-Is” and “To-Be” concepts are time-specific snapshots of DoDAF views that initially served as the endpoints of a transition process. However, this transition strategy has several potential pitfalls, to include the difficulty in accurately representing the “As-Is” starting point where legacy systems are sometimes poorly documented, and processes are largely undefined. There is also the consideration that long-term goals are often very flexible, resulting in flux in the “To-Be” version.

Since the “As-Is” and “To-Be” Architectural Descriptions are time-specific versions of similar sets of data with similar viewpoints, transition planning is able to chart an evolutionary path from the “As-Is” to its corresponding “To-Be” architectural vision given a clear understanding of the expected outcomes or objectives through some future (perhaps undefined) future point. It is expected that the To-Be Architectural Descriptions will change over time as Departmental priorities shift and realign.

Federated Approach to DoD Architecture Management

The Department has adopted a federated approach to distributed architectural data collection, organization, and management among the Services, Agencies and COIs as its means of developing the DoD Enterprise Architecture, with a virtual rather than physical data set described through supporting documentation and architectural views. This approach provides increased flexibility while retaining significant oversight and quality management services at the Departmental level. Detailed guidance on the DoD federation approach will be contained in DoDD 8210, “Architecting the DoD Enterprise.”

Tiered Accountability

Tiered Accountability (TA) is the distribution of authority and responsibility to a DoD organization for an element of the DoD EA. Under TA, DoD is defining and building enterprise-wide capabilities that include data standards, business rules, enabling systems, and an associated layer of interfaces for Department, specified segments of the enterprise (e.g., JCA, DoD Components), and Programmatic solutions. Each tier has specific goals, as well as responsibilities to the tiers above or below them.

Architectural Descriptions are categorized when developed to facilitate alignment (mapping and linking), cataloging, navigating, and searching disparate architecture information in a DoD registry of holdings. All Architectural Descriptions developed by the tiers should be federated, as described in the DoD Federation Strategy.

Alignment in the tiers is required for the DoD EA to be discoverable, shareable, and interoperable. Architectural Descriptions can also support many goals within the tiers, each of which may imply specific requirements for structure, content, or level of detail. Alignment decisions should balance the interdependence of Architectural Descriptions with the need for local flexibility to address local issues. Alignment describes the minimum constraints needed to ensure consistency across architecture levels. Architectural Descriptions often relate at some ‘touch point’ to other Architectural Descriptions on the same level, level(s) above, or level(s) below, and should be discovered and utilized in the development of Architectural Descriptions to ensure that appropriate linkages are created and maintained. The need to plan for them implies that each Architectural Description sharing a touch-point should be available to architects on both sides. The DMR for data facilitates the ability to discover and utilize architectural data, with the caveat that any touch-points within the purview of an established COI adhere to COI guidance.

DoD Architecture Enterprise Services

The next generation of DoD Enterprise Architectures will be constructed by employing a set of DoD Architecture Enterprise Services (DAES) for registering, discovering, aligning, translating, and utilizing architectural data, and derived information to support key DoD decision processes through implementing the concepts of the DoD Net-Centric Strategies. DAES will be implemented using Web Services, in which specific content and/or functionality is provided by one user for others, many of whom may be unknown to the provider. An Operational Resource Flow Description (A redesigned Operational Viewpoint 2 (OV-2) DoDAF-described Model) has been retained in DoDAF V2.0 to describe those services that can be discovered and subscribed from one or more specific sources and delivered to one or more known or unknown subscribers.

Registration of architectures, one of the goals of the NCDS , is the first step toward enabling discovery of architecture metadata. DAES includes a registration service to register the metadata (through the DMR), and a method to describe the purpose and scope of an Architectural Description. The registration service will enable cataloging of Architectural Descriptions in federated repositories, and, once complete, Architectural Descriptions are ‘available’ for discovery. When an Architectural Description is discoverable, it can be aligned to, linked to, or re-used by other Architectural Descriptions. The discovery service enables users to execute a federated search for architecture holdings meeting specified search parameters.

Alignment to the Federal Enterprise Architecture

The OMB established the Federal Enterprise Architecture (FEA) program in 2003 to build a comprehensive business-driven blueprint of the entire Federal Government. OMB’s Circular A-11 requires that Cabinet-level agencies, including the DoD, link their budget submissions to the FEA, and annually evaluates those submissions through the Enterprise Architecture Assessment Program, which establishes an evaluation score for overall agency progress.

The core principles of the FEA program are:

• Business-driven approach.
• Promote collaboration of effort and reuse.
• Improve efficiency and effectiveness of business operations through the use of enterprise architecture for the capital investment process.
• Demonstrate cost savings and cost avoidance through improved core processes, and cross-agency sharing and mutual investment.

DoD leverages the FEA construct and core principles to provide the Department with the enterprise management information it needs to achieve its own strategic transformation goals and respond to upward reporting requirements of OMB. The primary objective is to improve DoD performance, using EA, by providing a framework for cross-mission analysis and identification of gaps and redundancies; and by developing transition plans and target architectures that will help move DoD to the net-centric environment.

Several Federal and DoD-specific EA artifacts exist that describe enterprise-level management information. These include:

• The President’s Management Agenda.
• OMB A-11 Exhibit 300 submissions.
• OMB FEA Practice Guidance.
• OMB EA Assessment Guide.
• OMB FEA Reference Models.
• DoD EA Reference Model (RM) Taxonomy.
• DoD EA Consolidated RM.
• DoD EA Transition Strategy.
• DoD Segment Architectures.
• DoD EA Self-Assessment.
• DoD Architecture Federation Strategy.

These artifacts facilitate the alignment with the FEA, contribute to a broader understanding of architecture alignment, provide a basis for federated Architectural Descriptions, promote a more efficient and effective use of assets, and ultimately lead to better decision-making.

When developing architectures, particularly at the Departmental and Component levels, alignment with the FEA is accomplished by utilizing the Federal Enterprise Architecture-Consolidated Reference Model (FEA-CRM) documents together with DoD documents and references as a basis for defining processes, data, services, and technical standards. As an example, when a process owner determines that an Architectural Description is needed for some specific purpose, the first references to use are as shown below, as well as other Architectural Descriptions above and below the level of the Architectural Description under development. The DoD-level information is contained in the DoD EA Reference Models, along with the implementing guidance, standards, and descriptions of Department-wide information that is mapped to the FEA-CRM in accordance with the FEA construct.

References to Architectural Description Development