Introduction NAME 24 Sep 2009 Mr. Michael Wayson Enterprise Architecture & Standards Directorate Office of the DoD Deputy Chief Information Officer (703) 607-0482 Michael.Wayson@osd.mil

DoDAF Definition DoDAF V2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries.

DoDAF V2.0 Goals Support the Department’s core processes: Capabilities Integration and Development (JCIDS) Planning, Programming, Budgeting, and Execution (PPBE) Acquisition System (DAS) Systems Engineering (SE) Operations Planning Capabilities Portfolio Management (CPM) Establish guidance for architecture content as a function of purpose – “fit for purpose” Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

DoDAF V2.0 What has been delivered? Volume 1 – Manager’s Guide Guidance for Development, Use, and Management of Architectures Volume 2 – Architect’s Guide Describes construction of Architectures, the DODAF Meta-model, Data Exchange Requirements, and Development of the Architectural Models in technical detail Volume 3 – Developer’s Guide Introduces the DoDAF Meta-Model Physical Exchange Specification

DKO DoDAF Journal What has been delivered in the DKO DoDAF Journal (https://www.us.army.mil/suite/page/454707) Models, Evaluation, Process Other Information (https://www.us.army.mil/suite/folder/17204298) Meta-Model Data Dictionary (Zip File) Physical Exchange Specification XSDs (Zip file) DoDAF Product Development Questionnaire Analysis Report (Capability and Project View examples and others are here) The DKO-S DoDAF Homepage is www.us.army.smil.mil/suite/page/9964. Need a sponsored account if not Military or DoD Civilian

DoDAF V2.0 Promulgation Memo Version 2.0 is the prescribed framework for all Department architectures and represents a substantial shift in approach. Don’t redo current architecture Architectures shall comply with Version 2.0 in their next major release. Update only in the next release Does not prevent early adoption of DoDAF V2.0

VERSION 15 3/25/2017 10:01 Value of DoDAF V2.0 DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development. Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs. Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers. Facilitates development of architectural descriptions under Service-Oriented Architecture (SOA)-related techniques and tools Adheres to the DoD Acquisition Life Cycle methodologies contained in the DoD Acquisition Guide Can be used in conjunction with Lean Six Sigma and other Process Improvement methods 7

DoDAF V2.0 Focus Results: Better ANALYSIS and Decisions. Focus: architecture DATA, not Products The DoDAF Meta-model (DM2) supports the architecture content of the DoD Core Processes The relationships captured in DM2 supports qualitative and quantitative analysis By being able to relate architectural descriptions, with a common architecture vocabulary, better analysis across architectural description can be performed . Data allows better analytical results for the decision makers. 8

Shift from Product-Centric to Data-Centric Focus Prior versions of DoDAF and earlier C4ISR versions of the Architecture Framework have emphasized reusable and interoperable data organized into ‘products’ (e.g., graphical representations or documents) DoDAF V2.0 emphasizes focus on data, and relationships among and between data rather than the presentations of products Emphasizes on utilizing architectural data to support analysis and decision-making, Greatly expands the types of graphical representations that can be used to support decision-making activities. Supports innovative and flexible presentation of the architectural data in a meaningful, useful, and understandable manner DoDAF 2.0 significantly refocuses the architectural concepts that have been in play for many years. First and foremost, the focus is on DATA, not architecture products. Data is needed for good analysis and better decisions. How these decisions are made within the culture of an organization should not artificially change just because we publish a Framework. Instead, this version discusses how to collect the data needed, validate that data, organize that data, and THEN form it into models, views, and viewpoints that graphically express the data. For those that have been happy with the older ‘DoDAF products’, please be assured that they are still being supported, along with many other views. The difference is that you can choose HOW to express your data in ways that better fit both your organizational preferences, and your specific project needs

DoDAF 2.0 focuses architecture development to ‘Fit for Purpose’ DoDAF 2.0 introduces ‘Fit-for-Purpose’ architecture as one that is appropriately focused on supporting the stated objectives ‘Fit-for-Purpose’ architectures Respond to the stated goals and objectives of a process owner Are useful in the decision-making process Respond to internal and external stakeholder concerns ‘Fit-for-Purpose’ enables the architect to focus on collecting data and creating views that are necessary for the decision-maker’s requirements, and focusing the architecture to align to the decision-maker’s needs 10

Data-Centric: Original DoDAF Views have been expanded to better organize information, and reflect data that practitioners actually use Modified Viewpoints The original DoDAF Systems View has been separated into a Systems Viewpoint (SV) and a Service Viewpoint (SvcV) to accommodate extension to both systems and software/services engineering practice All the models of data (Conceptual, Logical, and Physical) have been moved into the Data & Information Viewpoint (DIV) The Operational Viewpoint (OV) now describes rules and constraints for any function (business, intelligence, warfighting, etc) Technical View (TV) has been updated to the Standards Viewpoint (StdV) to describe business, commercial, and doctrinal standards in addition to technical standards The All Viewpoint (AV) is essentially the same. New Viewpoints Capability Viewpoint (CV) focuses on Capability data in support of Capability development and to standardize the capture of capability data Project Viewpoint (PV) focuses on the Portfolio Management/CPM information to explicitly tie architecture data to project efforts 11

DoDAF Evolution To Support “Fit For Purpose” Architecture CADM Separate Baseline For DoDAF 1.5 Removed Essential & Supporting Designations Expanded audience to all of DoD (Published in 2003) DoDAF 1.5 Addresses Net-Centricity Volume III is CADM & Architecture Data Strategy Addresses Architecture Federation Baseline for DoDAF 2.0 Shifted away from DoDAF mandating a set of products (Published in 2007) DoDAF 2.0 Cover Enterprise and Program Architecture Emphasize Data versus Products Tailored Presentation AV-1 to capture federation metadata Quality Support to Decision Processes FEA & Allied/Coalition Support Journal - Errata & Interim Releases DoDAF 2.0

DoDAF V2.0 DoDAF Metamodel (DM2) Fit For Purpose Presentation Dashboards Graphical Depictions Reference Models Fusion Products Composite DoDAF V2.0 DoDAF V1.5 Standards Viewpoint Operational Rest of OVs All TVs All All AVs Systems Viewpoint All “Systems” Versions of SV Products Data & Information Viewpoint OV-7 Services SV-11 All “Service” Versions of SV Products DoDAF Metamodel (DM2) DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions. In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.). Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience. DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues. BUILD ONE: The original views (OV, SV,TV, AV) have had their content reorganized to better address their purpose The Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementations All of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views. BUILD TWO: The new Systems view better accommodates our legacy system descriptions. The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services. The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships. The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective. BUILD THREE: The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both. Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View. There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker. Capability Viewpoint Project New Updated Moved

Perspectives: Viewpoints That Fit-the-Purpose Renamed New New New Overarching aspects of architecture context that relate to all models All Viewpoint Articulate the data relationships and alignment structures in the architecture content Data and Information Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Standards Viewpoint Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions Operational Viewpoint Articulate operational scenarios, processes, activities & requirements Capability Viewpoint Articulate the capability requirement, delivery timing, and deployed capability Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process. Project Viewpoint New DoDAF organizes the DoDAF-described Models into the following viewpoints: The All Viewpoint describes the overarching aspects of architecture context that relate to all viewpoints. The Capability Viewpoint articulates the capability requirements, the delivery timing, and the deployed capability. The Data and Information Viewpoint articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services. The Operational Viewpoint includes the operational scenarios, activities, and requirements that support capabilities. The Project Viewpoint describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. An example is the Vcharts in Chapter 4 of the Defense Acquisition Guide. The Services Viewpoint is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions. The Standards Viewpoint articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services. The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions. Architecture viewpoints are composed of data that has been organized to facilitate understanding. 14

DoDAF V2.0 The logo indicates the change with DoDAF V2.0. With authoritative data, using a vocabulary for architects, a development method, and desired presentations, an architectural description can be ‘Fit-for-Purpose’ for the Decision-makers. 15

“Fit for Purpose” Architecture Descriptions There are now 52 DoDAF-described Models --- as w/ past versions of DoDAF you only build the ones you need to get the information you need. It's the data behind the models that Decision-Makers really care about. Models Based on models and authoritative information (data), the architectural description can support desired presentations for multiple purposes. 16

DoDAF V2.0 Focus: Terms DoDAF V1.5 DoDAF V2.0 Architecture Alignment with ISO 42010 and 15407 DoDAF V1.5 DoDAF V2.0 Architecture Architectural Description Architecture data Architectural data Product Model (a template for collecting data) View (a model with data for an architecture) View Viewpoint Models are templates for organizing and displaying data in DoDAF 2.0 Previous versions of DoDAF referred to these as ‘Products’ An example of a Model is an OV-2, OV-5, SV-1, CV-5 Views are the result of collecting and populating Models with data and then presenting it Views are a Model populated with specific data An example of a view is a MOC OV-2, MDA OV-6c, NAVFAC SV-1 Viewpoints are a collection of models/views Previous versions of DoDAF just referred to these as ‘Views’ Examples include: All Viewpoint (AV), Operational Viewpoints (OV), Capability Viewpoint (CV) The collection of information, specifically Views and/or Viewpoints, used to document the architecture is referred to as an Architectural Description Previous versions of DoDAF referred to these as just an ‘Architecture’ A few words about terminology before we go very far. There is a lot of terminology in the presentation, and you will be faced with it each time you discuss an architecture. In addition, there are changes from previous versions of DoDAF that you might be familiar with, and normally use. In our part of the engineering world, everything starts will identifying a need, developing a plan for action, and collecting information about whatever it is that seems to need update or other types of change. Unfortunately, data or information is not easy to read or even pretty to look at. For that reason, people create presentations, such as this, to explain what they mean, seek further information, do analysis, and eventually gain concurrence. To do those things, we in the community look for ways to explain what we mean. Generally, for technical things, we use models—templates that look the way we usually express ourselves. When we ‘fill in’ the data, we have a view of the data. We used to call a view a ‘product’. A collection of these views is called a viewpoint, and becomes the architectural description. The difference is that you don’t have to use the examples contained in DoDAF—they are NOT required. You can create your own if you wish from the data collected. These are called User-created Views or Fit-for-Purpose Views. If you are comfortable with the older DoDAF ‘products’, then you can use the DoDAF-described Views—all of the old products are listed among the DoDAF-described products. DoDAF does describe a number of new views, as you will soon see. There is a lot of new material in DoDAF 2.0

Operational Model Example Architectural Description DoDAF V2.0 Focus: Architecture Models + Data = Architectural Description Operational Model Example Things Individuals Types or classes of individuals or things The framework enables architecture content to be built that is “Fit for Purpose”, defined and described in Volume 1 as architecture, which is consistent with specific project or mission objectives. Because architecture can be applied at myriad levels of an enterprise, the purpose or use of architecture at each level will be different in content, structure, and level of detail. Pulling everything together that we know about an architecture—the viewpoints, requirements, and expected outcomes, we have an architectural description. In order to ensure that architectural descriptions meet program and mission objectives, the approach to architecture development must be tailored to address a specific, well-articulated, and understood purpose. This will help to ensure that necessary data collection, to an appropriate level of detail, is undertaken, completed, and supportive of specific decisions or objectives. Architectural description: A collection of products to document an architecture. An architectural description generally contains one or more viewpoints to express the business, service, system and other elements of the overall project or program. Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Architecture Data + Metadata Architecture Models Architectural Description Fit-for-Purpose (FFP) Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs. 18

Methodology: DoDAF V2.0 Six-Step Architecture Development Process Determine the intended use of the architecture 1 Determine scope of architecture 2 Determine data required to support development 3 Collect, organize, correlate, and store architecture data 4 Conduct analyses in support of objectives 5 Document Results IAW Decision-Maker needs 6 Provide list of data needed and use cases 3.1 Model to DM2 Concept List Review list of architecture data and determine if it meets the use 3.2 DM2 Conceptual Data Model & Logical Data Model Assist with the Architect’s data collection processes 4.1 List of Potential Collection Methods Selected Verify the data collected meets the use cases 5.1 Example Uses Fit-for-Purpose Use Determine how data needs to be presented 6.1 Legacy Products User Requirements Presentations Detailed Steps for Decision- Maker It is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience. If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts. There are six steps is the DoDAF methodology: 1-Determine the intended use of the architecture 2- Determine the scope of the architecture 3- Determine data required to support architecture development 4- Collect, organize, correlate and store data 5- Conduct analysis in support of architecture objectives 6- Document results Managers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed. With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort.

Data: DoDAF Meta-Model (DM2) Purposes: The vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage Specification for federated data exchange between: architecture development and analysis tools architecture databases other authoritative data sources Support discovery and understandability tenants of NCDS: Discovery DM2 categories of information Understandability thru precise semantics augmented with linguistic traceability Capture and express Architectural Descriptions in a common, understood language for the exchange of architecture information 20

Data: Types of Data in DoDAF V2.0 (known as Conceptual Data) Projects Goals Rules Measures Locations Activities Performers Resource Flows Information and Data Training, Skill, Education Capabilities Services The new DoDAF meta-Model is much simpler and easier to understand than the old CADM Model from previous versions of DoDAF. There are twelve data groups, each of which collects some specific type of architecture data. [Go through groups] Internal [Project, Goals, Training, skill, education] Architectural [Rules, measures, Locations, Activities, Performers, Resource Flows, Capability, Services] Informational [Information and data] Data may be activity data, system or service data, or network data, or any of a number of data categories that contain appropriate data. 21

The DoDAF Meta-model Improvements High-level conceptual model developed with easily understood terms and descriptions Semantically correct without broken or obscure associations and relationships Only that data related to architecture development in Departmental core processes Extensible and Scalable to support “Fit-for-Purpose” developments Small and compact versus large, cumbersome, and difficult to read

DoDAF V2.0 Conformance The data in an architectural description is defined according to the DoDAF Meta-model (DM2) concepts, associations, and attributes. The information captured in an architecture tool is consistent with the DM2 concepts, association, and attributes. Architectural data should be stored in a recognized commercial architecture tool that conforms to industry standards. Tools, preferably data-driven, can be used for the PRESENTATION of architectural data, but it must be based on DATA. The architecture data is capable of transfer in accordance with the UPDM and PES

DoDAF Meta-model (DM2) and Unified Profile for DoDAF and MODAF (UPDM) DoDAF Meta-model (DM2)/Physical Exchange Specification (PES) – A data model that defines conceptual, logical, and physical views of the information requirements for DoD architectures. A language for the DoD architect A model for ALL tool vendors An exchange schema for interoperability Unified Profile for DoDAF and MODAF (UPDM) 1.0 – An Object Management Group specification for UML tool vendors to follow for consistent representations/exchanges of DoDAF V1.5/MODAF V1.2 architectures. A specification from which UML/SYSML tool vendors can implement UPDM 2.0 – A new effort by the Object Management Group to update UPDM for DoDAF V2.0 and MODAF V1.3.

DISR and MDR DoD Information Technology Standards and Profile Registry (DISR) – Registry of standards for the Department; UPDM is in DISR because it is a standard developed by a Voluntary Consensus Standards body. DoD Metadata Registry (MDR) – A registry of data models, vocabularies, and schemas to support COI collaboration

DoDAF V2.0 Summary DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development. It is all about the decision-makers and the data! Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs. Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers. DoDAF V2.0 is available at: http://www.defenselink.mil/cio-nii/policy/eas.shtml https://www.us.army.mil/suite/page/454707 The DKO-S DoDAF Homepage is www.us.army.smil.mil/suite/page/9964.