Presentation on theme: "DOD Architecture Framework (DoDAF) Relevance to JITC Testing"— Presentation transcript:
1DOD Architecture Framework (DoDAF) Relevance to JITC Testing Good Morning,Hopefully you all are here to become DoD Engineering architects. Actually we have quite a bit of slides to go through and the intent of the presentation is to familiarize you with DoDAF and particularly DoDAF version 2.0, so that when you see an architecture viewpoint you know what it should be providing you as a Tester.Fred HaukaasJT4AJune 2010
2DoDAF’s Role in JITC Testing What is going on with DoDAF?DoDAF EvolutionA look at DoDAF 2.0What Architecture Viewpoints do JITC Testers need to be aware of?All Viewpoints (AV-1 and AV-2)Operational Viewpoints (OV-1, OV-2, OV-3, OV-4, OV-5, and OV-6CSystem Viewpoints (SV-1, SV-2, SV-4, SV-5, and SV-6)Data and Information Viewpoints (DIV-2 and DIV-3)Standard Viewpoints (StdV-1 and StdV-2)Service Viewpoints (SvcV-1, SvcV-2, SvcV-4, SvcV-5, and SvcV-6)Here is a brief outline of today's presentation. Unfortunately there are a significant number of viewpoints available with DoDAF 2.0, but thankfully we are looking at only 22 of the 49 Viewpoints.
3The Importance of DoDAF Evolution As our Department policies and decision processes evolve, so must the DoDAFDoDAF v1.5 represented an important step toward addressing the requirements of the Net-Centric Environment in architecturesDoDAF v2.0 must address evolving information requirementsof the Department using both top-down and bottom-up approachesInformation SharingSupport for the Net-Centric Data and Services Strategies of the DepartmentPortfolio ManagementDoDAF has come a long way in a relatively short time frame. Who knows what occurrence really began the drive to emphasize Enterprise architecture and when this happened?Ans: Hint, The first C4ISR Architecture Framework v1.0, released 7 June 1996, was created in response to the passage of: The Clinger-Cohen act of 1996, formerly the Information Technology Management Reform Act of 1996 (ITMRA), is a 1996 US federal law, designed to improve the way the federal government acquires, uses and disposes information technology and led to formation of an Enterprise architecture. Version 2 came along in 1997.Six years later in August 2003 the DoDAF v1.0 was released, which restructured the C4ISR Framework v2.0Four years later in April 2007 the Version 1.5 was released with a documentation of "Definitions and Guidelines", "Product Descriptions" and "Architecture Data Description"Most recently in May 2009 version 2.0 was released.Let’s take a little more in depth look at version 1.5.
4Net-Centric Concepts were addressed in DoDAF 1.5 The following Net-Centric Concepts were presented and discussed in DoDAF 1.5Populate the Net-Centric Environment (NCE)2. Utilize the NCE3. Support the Unanticipated user4. Leverage Communities of Interest (COIs) to promote Jointness5. Support Shared Infrastructure1. Represent what information and capabilities are being made available (as services) to the NCE so they can be leveraged by others.2. Represent what information and capabilities provided on the GIG will be available to service consumers through service discovery and leveraged across the NCE.3. Represents that 1) capabilities can scale to support both human and systemunanticipated users, and 2) the posting of information, data, applications andservices to the NCE occur as soon as possible to enable multiple use.4. Represents the utilization of COI specific interface specifications, taxonomies, and common vocabulary to support interoperability in the NCE.5. Represents that the shared physical and services infrastructure (the Enterprise Information Environment ) is identified and leveraged in the NCE.Why is DoDAF important? Next slide
5Key Policies Requiring DoDAF DoDI , 30 June 2004, "Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)“Joint StaffCJCSI G, 1 MARCH 2009, “JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”Manual for CJCSI G, APRIL 2009, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”CJCSI E, 15 December 2008, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS”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.Or another way of saying is that DoDAF is prescribed for the use and development of Architectural Descriptions in the DoD. Specific DoDAF-described Models for a particular purpose are prescribed by process-owners. All the DoDAF-described Models do not have to be created. DoDAF V2.0 is "Fit-for-Purpose", based on the decision-maker needs. DoDAF does not prescribe any particular Views, but instead concentrates on data as the necessary ingredient for architecture development.Does this mean no viewpoints have to be provided?No, other regulations and instructions from both DoDand CJCS may have particular presentation view requirements. These Views aresupported by DoDAF 2.0, and should be consulted for specific view requirements.As DoDAF transitioned from 1.5 to 2.0Direct support for the Warfighter
6Moving From DoDAF 1.5 to DoDAF 2.0 Promulgation MemoVersion 2.0 is the prescribed framework for all Department architectures and represents a substantial shift in approachDon’t redo current architectureArchitectures shall comply with Version 2.0 in their next major releaseUpdate only in the next releaseDoes not prevent early adoption of DoDAF V2.0We have the release of DoDAF 2.0 which actually occurred last year. (28 May 2009)
7DoDAF V2.0 What are we delivering? Volume 1 – Manager’s GuideGuidance for Development, Use, and Management of ArchitecturesVolume 2 – Architect’s GuideDescribes construction of Architectures, the DODAF Meta-model, Data Exchange Requirements, and Development of the Architectural Models in technical detailVolume 3 – Developer’s GuideIntroduces the DoDAF Meta-Model Physical Exchange SpecificationDoDAF Journal (https://www.us.army.mil/suite/page/454707)On-line interface providing examples, description of best practices, lessons learned, and reference documents supplementing the information in the three volumesDoDAF 2.0 was released with three volumes and a Journal. Volume 2 is the most relevant in terms of descriptive information but hopefully the Journal will become more useful as it is fully developed.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 DoDAF Meta‐model (DM2) Physical Exchange Specification (PES) for the exchange of architectural data.The DM2 provides a means to collect architecture‐related data, organize the data into useful information by architects and architecture development teams, store the information for later reuse, and facilitate management analysis of architectural data and information for decision making purposes
8DoDAF Evolution To Support “Fit For Purpose” Architecture Is an architectural view that is appropriately focused on supporting the stated goals and objectives.Is meaningful and useful in the decision-making process.Encourages the architect to focus on collecting data and creating views that are customized to the decision-maker’s value chain.Architectural data and views are aligned to the information consumer’s needs.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.Hence your viewpoints.
9DoDAF V2.0 FocusResults: Better ANALYSIS and Decisions.Focus: architecture DATA, not ProductsDoDAF 2.0 focus is on the data.DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development.
10Architecture Models + Data = Architectural DescriptionOperational Model ExampleThingsIndividualsTypes or classes of individuals or thingsArchitectureData + MetadataArchitectureModelsArchitectural DescriptionFit-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.
11Key ConceptsDoDAF is prescribed for the use and development of Architectural Descriptions in the DepartmentSpecific DoDAF-described Models for a particular purpose are prescribed by process-ownersAll the DoDAF-described Models do not have to be created. DoDAF V2.0 is “Fit-for-Purpose”, based on the decision-maker needsDoDAF V2.0 is data-centric and has shifted from the DoDAF V1.5 focus on ProductsDoDAF V2.0 prescribes a discipline for Architecture Development to determine the purpose and scope of the architecture before the data and Viewpoints are selectedNode has been decomposed into more concrete conceptsExamples will appear in the DoDAF Journal.
12Key PointsThe DoD Architecture Framework (DoDAF) version 2.0 is a significant improvement over past versions of the framework. It places much higher emphasis on the collection and organization of architecture data rather than on visualization.To better support data collection, the data model for DoD architecting has been revamped and is included within DoDAF 2.0. It is now much more concise and understandable than previous versions of the Core Architecture Data Model (CADM). As a result of these improvements, it has been renamed the DoDAF MetaModel (DM2) which includes:- A Conceptual Model focused for understanding architecture content by leadership and the operational community- A Logical Model for use by architects, analysts, and tool vendors- A Physical Exchange Specification for service developers andvendors that will enable sharing architecture information in a net-centric environment
13Key Points ContinuedAnother major shift in DoDAF 2.0 is the concept of “fit for purpose” architecture presentation. DoDAF 2.0, based on data collection and the removal of set boundaries between the operational, service/system, and technical views, will allow the architecture data to be organized in an “ad hoc” fashion, combining all relevant information tailored to specific decision maker requirements.DoDAF 2.0 is the culmination of accommodating the feedback on DoDAF 1.0 and DoDAF 1.5 as well as in depth analysis and incorporation of the lessons learned and best practices from the various architecture frameworksHopefully, this has set the stage for us to take a closer look at the Viewpoints of DoDAF 2.0
14DoDAF 2.0 Provides these Viewpoints RenamedNewNewNewArchitecture viewpoints are composed of data that has been organized to facilitate understanding.NewData models split out into separate Viewpoint in V2.0Services views split out into separate viewpoint in V2.0
15All Viewpoints (AVs) Viewpoints Descriptions AV-1 Overview and Summary InformationDescribes a Project's Visions, Goals,Objectives, Plans, Activities, Events,Conditions, Measures, Effects (Outcomes),and produced objects.AV-2 Integrated DictionaryArchitecture data repository with definitionsof all terms used throughout thearchitecture data and presentations.
16AV-1: Overview and Summary Information Description: The overview and summary information containedwithin the AV-1 provides executive-level summary informationin a consistent form that allows quick reference and comparisonbetween Architectural Descriptions.ARCHITECTURE RELATIONSHIPS:LINK AV-1 to all architecture viewpoints.The written content of the AV-1 content describes the concepts contained inthe pictorial representation of the OV-1. In the initial phases of architecturedevelopment, it serves as a planning guide. When the architecture is built, theAV-1 provides summary information concerning who, what, when, why, andhow of the plan as well as a navigation aid to the models that have beencreated. The usage of the AV-1 is to scope the architecture effort, providecontext to the architecture effort, define the architecture effort, summarize thefindings from the architecture effort, and assist search within an architecturerepository.
17Architecture Project Identification AV-1 ExampleDepartment of DefenseBusiness Enterprise Architecture 7.0Overview and Summary Information (AV-1)March 12, 2010The AV-1 is an executive-level summary of the Department of Defense (DoD) Business Enterprise Architecture (BEA). The initial version of the AV-1 for BEA 7.0 focused the architecture development effort by documenting the scope of planned changes. This final release of the AV-1 includes findings and recommendations from the BEA 7.0 development effort.Architecture Project IdentificationNameDoD Business Enterprise Architecture (BEA) 7.0ArchitectDoD Business Transformation Agency (BTA)Developed ByRepresentatives from the DoD Business Mission Area (BMA) Core Business Missions (CBMs) and BTAAssumptionsandConstraintsThe BEA 7.0:- Addresses only DoD Enterprise-level business and strategic plans, goals, objectives and strategies.- Makes maximum reuse of legacy BEA products with changes made as necessary.- Focuses on addressing business capability improvements and architecture gaps identified during BEA 7.0 planning sessions with stakeholder communities plus content and technical changes necessary to bring products into conformance with updates to the DoD Architecture Framework (DoDAF), the BEA Development Methodology (BDM), BEA Architecture Product Guide (APG) and the Enterprise Transition Plan (ETP).Approval AuthorityThe Deputy Secretary of Defense, acting through the Defense Business Systems Management Committee (DBSMC)Date CompletedMarch 12, 2010LOE and CostsLevel of effort, projected and actual costs to develop the BEA may be requested from the Director, BTA.Point of Contact Information
18Organizations Involved AV-1 Example ContinuedScope: Architecture View(s) and Products IdentificationProducts DevelopedBEA 7.0 consists of the set of integrated architecture products - AV-1, AV-2, CV-2, CV-6, DIV-1, DIV-2, OV-2, OV-3, OV-5a, OV-5b, OV6a, OV-6c, SV-1, SV-5a, SV-6, SvcV-1, ScvV-5 and StdV-1 - necessary to comply with DoDAF, the APG, and BEA 7.0 requirements. The BEA products result from a collaborative effort of the Core Business Missions (CBMs) and represent an integration of business priorities documented and described throughout the various products.ScopeThe scope of the BEA is any function, process, rule, data, or technology that is required to be used in a standard manner to support or describe the business enterprise. This scope is further defined within six Business Enterprise Priorities (BEPs). The six BEPs have been identified as the highest priority transformation initiatives at the DoD Enterprise level and serve as the focus of the BEA 7.0 development effort. They are:Time Frames AddressedThe BEA is the “To Be” architecture for DoD business transformation efforts. The current BEA “To Be” end state has intermediate time frames for implementation addressed in the ETP.Organizations InvolvedDevelopment of the BEA involves organizations of the DoD Business Mission Area (BMA) CBMs (led by the Principal Staff Assistants (PSAs) at the enterprise level), as follows: Comptroller, Personnel & Readiness, and Acquisition Technology & Logistics, and is further supported by the Investment Review Boards (IRBs) to include: Financial Management (FM), Human Resources Management (HRM), Materiel Supply & Service Management (MSSM), Real Property & Installations Life-cycle Management (RPILM), and Weapon Systems Life-cycle Management (WSLM). The PSAs determine the BEPs based on the mission needs of the DoD.
19Joint Capability Areas AV-1 Example ContinuedPurpose and ViewpointTo provide a blueprint for DoD business transformation that helps to ensure that the right capabilities, resources and materiel are rapidly delivered to our warfighters: What they need, where they need it, when they need it, anywhere in the world. The BEA guides and constrains implementation of interoperable defense business system solutions as required by the National Defense Authorization Act (NDAA) and guides information technology (IT) investment management to align with strategic Business Capabilities as required by NDAA, Clinger-Cohen and supporting Office of Management and Budget (OMB) and Government Accountability Office (GAO) policy.- Who are our people, what are their skills, where are they located?- Who are our industry partners, and what is the state of our relationship with them?- What assets are we providing to support the warfighter, and where are these assets deployed?- How are we investing our funds to best enable the warfighting mission?The BEA is developed from a DoD BMA, tiered accountability, and business owner perspective focusing on the definition and documentation of activities, processes, data, information exchanges, business rules, laws, regulations, policies and terms at a DoD Enterprise level. The DoD Enterprise level addresses business capabilities that are both enterprise level and DoD-wide, and includes the systems and initiatives that support those capabilities.Joint Capability AreasSecurity Caveats
20AV-1 Example Continued Context Tools and File Formats Used MissionThe BEA is essential to the transformation of business operations throughout the Department of Defense and to the delivery of enterprise-level business capability improvements that align to warfighter needs.GoalsEstablish foundational data standards and business rules.Support DoD investment management criteria for systems certification.Comply with evolving DoD Networks and Information Integration (NII) architecture guidance.Provide the foundation to accelerate outcome based architecture development and implementation.Describe DoD enterprise CBM end-to-end business processes as they relate to the six BEPs.Rules, Criteria, and Conventions FollowedRules -BEA products shall be developed and decomposed only to the level of detail required to adequately portray enterprise “To-Be” business capability improvements and transformation priorities. (This has been determined on a BEP by BEP basis).Criteria and Conventions – Guidance contained in the BDM, the APG, and Decision Memoranda (DM) and approved by BEA leadership provide the criteria and conventions followed during BEA development for methodology, content, and format.Tasking for the BEA andLinkages to Other ArchitecturesTasking – The 2005 National Defense Authorization Act (NDAA) requires that architecture be defined and used to assess and maintain investments throughout the BMA.Linkages and Relationships – The BEA is linked to the Federal Enterprise Architecture (FEA) through the DoD EA Reference Models and federated with Component and program architectures through tiered accountability.Tools and File Formats UsedTelelogic System Architect v10.7, Enterprise Elements, Oracle, Microsoft SQL Server, Word, Access, and Excel, Adobe AcrobatFindings Recommendations
21AV-2: Integrated Dictionary Description: The AV-2 presents all the metadata used in anarchitecture. An AV-2 presents all the data as a hierarchy,provides a text definition for each one and references thesource of the element (e.g., DoDAF Meta-model, IDEAS, apublished document or policy).ARCHITECTURE RELATIONSHIPS:LINK AV-2 to:AV-1. AV-2 defines capabilities by identifying overall objectives ofthe system, what are the goals of the system, and what are themajor design constraints from AV-1..The purpose of the AV-2 is to provide a means to explain the terms andabbreviations used in building the architecture and, as necessary, submit themfor review and inclusion into authoritative vocabularies developed by COIs thatare pertinent to the Architectural Description content
22AV-2: Integrated Dictionary ContinuedARCHITECTURE RELATIONSHIPS:LINK AV-2 to:DIV-2 (OV-7). AV-2 defines resources by identifying the major objects and data elements (entities) of the system from DIV-2.DIV-3 (SV-11). AV-2 defines resources by identifying the major objects and data elements (entities) of the system from DIV-3OV-2. AV-2 defines resources by identifying the relationshipsamong the resources from OV-2.OV-3. AV-2 defines resources by identifying the relationshipsamong the resources from OV-3
23AV-2: Integrated Dictionary ContinuedARCHITECTURE RELATIONSHIPS:LINK AV-2 to:OV-4. AV-2 defines performers by identifying those that activelycontribute toward the completion of activities or the achievement ofan objective from OV-4.OV-5. AV-2 defines activities by identifying the major processes ofthe system that are needed to provide the desired capabilitiesfrom OV-5.OV-6c. AV-2 defines activities and performers by Breaking the majorprocesses into those activities necessary to achieve the objectivesof each process from OV-6c.
24AV-2 Example Name Description Node Type Assigned Activities _Ext_ Air AssetsAerospace forces that have the inherent capability to provide support to CSAR/SOF mission tasking.External Node_Ext_ Provide Air Support + "PILOT" _Ext_ Provide Voice Network + "PILOT"_Ext_ Air Force Weather AgencyProvides weather forecasts en-route and over the target area_Ext_ Provide Weather Data + "Weather Forecaster"
25Operational Viewpoints (OVs) DescriptionsOV-1: High Level Operational Concept GraphicHigh-level graphical/textual description of operational conceptOV-2: Operational ResourceFlow DescriptionOperational connectivity and information exchange needlinesOV-3: Operational ResourceFlow MatrixInformation exchanged and the relevant attributes of that exchangeOV-4: Organizational Relationships ChartOrganizational, role, or other relationships among OrganizationsOV-5: Operational Activity ModelCapabilities, operational activities, relationships among activities, inputs, and outputs; overlays can show cost, performers or other pertinent informationOV-6c: Event-Trace DescriptionOne of three models used to describe operational activity - traces actions in a scenario or sequence of events
26OV-1: High Level Operational Concept GraphicDescription: The OV-1 provides a graphical depiction of what the architecture is about and an idea of the players and operations involved. An OV-1 can be used to orient and focus detailed discussions. Its main use is to aid human communication, and it is intended for presentation to high-level decision-makers.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:LINK OV-1 to:OV-2. Organizations, organization types, and/or human roles, depicted in OV-1 should be traceable to operational resources in OV-2; relationships in OV-1 should trace to needlines in OV-2.
29OV-2: Operational Resource Flow DescriptionDescription: The OV-2 depicts Operational Needlines that indicate a need to exchange resources.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link OV-2 to:OV-1. Organizations, organization types, and/or human roles,depicted in OV-1 should be traceable to operational resources inOV-2; relationships in OV-1 should trace to needlines in OV-2.OV-3. A needline in OV-2 maps to one or more informationexchanges in OV-3.New to DoDAF V2.0, the OV-2 show flows of funding, personnel and materiel in addition to information. The OV-2 may also show the location of Operational facilities or locations, and may optionally be annotated to show flows of information, funding, people or materiel between Operational Activities. The Operational Activities shown in an OV-2 may be external activities that communicate with those internal activities.
30OV-2: Operational Resource Flow Description Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link OV-2 to:OV-4. Organizations, organization types, and/or human roles in anOV-4 may map to one or more operational resource in an OV-2,indicating that the resource represents the organization.OV-5. The activities annotating an operational resource in an OV-2map to the activities described in an OV-5. Similarly, OV-5 shoulddocument the operational resources that participate in eachoperational activity.
31OV-2: Operational Resource Flow Description Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link OV-2 to:OV-6c. Lifelines in OV-6c should map to operational resourcesin OV-2.SV-1. Operational resources in an OV-2 may be supported byone or more systems in SV-1 (indicating that the operationalresources owns/uses the system). A needline in OV-2 maymap to one or more interfaces in SV-1, and an interface inSV-1 maps to one or more needlines in OV-2.SvcV-1. Operational resources in an OV-2 may be supportedby one or more services in SvcV-1 (indicating that the operationalresource owns/uses the service). A needline in OV-2 may map toone or more interfaces in SvcV-1, and an interface in SvcV-1maps to one or more needlines in OV-2.
33OV-3: Operational Resource Flow MatrixDescription: The OV-3 identifies the resource transfers that are necessary to support operations to achieve a specific operational task.NOTE: The OV-3 information can be presented in tabular form. DoDAF V2.0 does not prescribe the column headings in an OV-3 Matrix.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link OV-3 to:OV-2. A needline in OV-2 maps to one or more resource(information) exchanges in OV-3.This model is initially constructed from the information contained in the OV-2Operational Resource Flow Description model. But the OV-3 provides a moredetailed definition of the Resource Flows for operations within a community ofanticipated users.
34OV-3: Operational Resource Flow Matrix ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link OV-3 to:OV-5. An information exchange in OV-3 should map to one ormore information flows (an external Input, an external output, oran output from one operational activity mapped to an input toanother) in OV-5, if OV-5 decomposes to a level that permits sucha mapping. Above that level of decomposition, a single informationflow in an OV-5 may map to more than one information exchange(or none, if the information flow does not cross node boundaries).OV-6c. Events in OV-6c map to triggering events in OV-3.DIV-2 (OV-7). An information element in OV-3 should beconstructed of entities in DIV-2 (OV-7).
35OV-3 Example Needline Identifier Information Exchange Identifier Information Element Name and IdentifierDF_NMISPoint-of-Sale DataN/AHIS_NMISPatient DataPatient_NCMMeal OrderPV_DFSInvoiceKitchen_PatientMeal Tray
36OV-3 Example Continued Content Scope Accuracy Language Point-of-sale data from dining facilities and other entities serviced by Medical Food Management.Recommended new MHS Activity: Manage Medical Food100%US EnglishPatient data including admissions, discharges, and tranfers.Meal order received for processing.Invoice of items delivered.Prepared meal including ordered recipe items, nourishments, etc.What do you see as a red flag on this matrix?Note the 100 % Accuracy.
37OV-3 Example Continued Producer Consumer Sending Op Node Name and IdentifierSending Op Activity Name and IdentifierReceiving Op Node Name and IdentifierReceiving Op Activity Name and Identifier_Ext_ Dining Facility_Ext_ Provide Point-of-Sale DataCitrix ServerManage Foodservice Operations_Ext_ Hospital Information System_Ext_ Provide Patient DataProcess HL7 ADT_Ext_ Patient Room_Ext_ Receive MealNutrition Care Management / Diet OfficeProcess Meal Orders (Room Service)_Ext_ Prime Vendor_Ext_ Deliver ItemsDining Facility StorageReceive Items into InventoryCentral KitchenAssemble Ordered Tray
38Performance Attributes Information Assurance Dissemination Control OV-3 Example ContinuedPerformance AttributesInformation AssurancePeriodicityTimelinessAccess ControlAvailabilityConfidentialityDissemination ControlIntegrity09 - EVENT DRIVENM = Moderate (1-10 Seconds)3 = Password and Identification Document01 = LOW--BEST EFFORT04 = NEED TO KNOW02 = PRIVATE--IAW PRIVACY ACT02 = NOT REQUIRED
39Mission/ Scenario UJTL or METL Interoperability Level Required OV-3 Example ContinuedNature of TransactionMission/ Scenario UJTL or METLTransaction TypeInteroperability Level RequiredTriggering EventCriticalityMHS Activity Manage and Report IncidentsCollaborateN/APoint-of-Sale Data6 = AdministrativePatient DataMeal OrderInvoiceMeal Tray
40Protection (Type Name, Duration, Data) Classification Caveat OV-3 Example ContinuedSecurityCommentsAccountabilityProtection (Type Name, Duration, Data)ClassificationClassification CaveatCMTHIPAA, Privacy Act of 1974, 5 USC 552 and 10 USC 11021 = None03 = FOR OFFICIAL USE ONLY"98 -NOT SPECIFIED"NPoint-of-Sale data currently manually input into NMIS. Objective requirement for automated interface between Dining Facility Point-of-Sale system and NMIS.YMeal orders currently taken via phone interface between a patient and a Diet Clerk. Objective requirement to automate this interface.Meal Tray not an "information" exchange.
41OV-3 Example 2 Information Element Description Needline Identifier Information Element DescriptionNeedline IdentifierInformation Element Name and IdentifierContentScopeAccuracyLanguage4_Ext_ Beneficiary Dependent's InformationPersonal dataMHS Enterprise99%English_Ext_ Beneficiary Information1_Ext_ Customer Demographic Data
42OV-3 Example 2 Continued Producer Consumer Sending Op Node Name and IdentifierSending Op Activity Name and IdentifierReceiving Op Node Name and IdentifierReceiving Op Activity Name and Identifier_Ext_ DMDC_Ext_ Provide DEERS InformationEWS-RSchedule Services_Ext_ External User_Ext_ Establish Beneficiary ProfileRegister Beneficiaries
43OV-3 Example 2 Continued Nature of Transaction Mission/Scenario UJTL or METLTransaction TypeInteroperability Level RequiredTriggering EventCriticalitySN ~ Coordinate Defensewide Health ServicesDirect07 = Level 1 - Connected Level (Peer to Peer)Scheduling Services4 = Mission CriticalRegistration5 = Mission Support
44OV-3 Example 2 Continued Performance Attributes Information Assurance PeriodicityTimelinessAccess ControlAvailabilityConfidentialityDissemination ControlIntegritySeconds"F: Fast (1-10 sec)"05 = ID CERT/ACL02 = MED--SPECIFIC RESOURCES ALLOCATED04 = NEED TO KNOW02 = PRIVATE--IAW PRIVACY ACT04 = MANDATORY
45OV-3 Example 2 Continued Security Accountability Protection (Type Name, Duration, Data)ClassificationClassification CaveatAttributed to specific actor(s)1 = NoneFOUO"14 - PROPRIETARY NR OUTSIDE US GOVERNMENT"
46OV-4: Organizational Relationships ChartDescription: The OV-4 addresses the organizational aspects of an Architectural Description.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link OV-4 to:OV-2. Organizations, organization types, and/or human roles inan OV-4 may map to one or more operational resources in anOV-2, indicating that the resource represents the organization.A typical OV-4 illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key players in the business represented by the architecture. An actual OV-4 shows real organizations and the relationships between them.
48OV-4 Example USSTRATCOM Air Force Space Command Army Space Navy Space 14th Air ForceSPACEAF20th Air Force50th SpaceWing21st Space1st SPCSSCCMissile WarningSquadronsSpaceSurveillanceJICSatelliteTrackingNetworkSBSS ControlSquadronCoordinationLineRelationship
49OV-5a: Operational Activity Decomposition TreeOV-5b: Operational Activity ModelDescription: The OV-5s and OV-2 Operational Resource Flow Description model are, to a degree, complements of each other. The OV-5s focuses on the operational activities whereas OV-2 Operational Resource Flow Description model focuses on the operational activities in relation to locations.Note: The OV-5a helps provide an overall picture of the activities involved and a quick reference for navigating the OV-5bDue to the relationship between locations and operational activities, thesetypes of models should normally be developed together. An OV-5a or OV-5bdescribes the operational activities (or tasks) that are normally conducted in thecourse of achieving a mission or a business goal. The OV-5b also describesInput/Output flows between activities, and to/from activities that are outsidethe scope of the Architectural Description. The OV-5a and OV-5b are equallysuited to describing non-military activities and are expected to be usedextensively for business modeling.
50OV-5a: Operational Activity Decomposition TreeOV-5b: Operational Activity ModelARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link OV-5 to:OV-2. The activities annotating an operational resource in an OV-2map to the activities described in an OV-5. Similarly, OV-5 shoulddocument the operational resources that participate in eachoperational activity.OV-3. An information exchange in an OV-3 should map to one ormore information flows (an external input, an external output, or anoutput from one operational activity mapped to an input to another)in OV-5, if OV-5 decomposes to a level that permits such amapping. Above that level of decomposition, a single informationflow in OV-5 may map to more than one information exchange (ornone, if the information flow does not cross resource boundaries).
51OV-5a: Operational Activity Decomposition TreeOV-5b: Operational Activity ModelARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link OV-5s to:OV-6c. Events in OV-6c map to inputs and outputs of operationalactivities.SV-5s. Operational activities in SV-5s match operationalactivities in OV-5s.SvcV-5. Operational activities in SvcV-5 match operational
52OV-5a Example Decomposition tree or hierarchical view. A2.1.1 Perform MissionA.1A.2PerformConduct AirbornePreflight &and GroundPostflightMission ActivitiesActivitiesA1.1A1.2A1.3A1.4A2.1PlanConductConductConductOperateMissionPre-MissionPost MissionAircraftAircraftActivitiesDebriefingMaintenanceDecomposition tree or hierarchical view.A2.1.1PerformTake-OffA2.1.3PerformEn-routeNavigationAnd OperationsA2.1.3ReceiveStrategicIn-flightRefuelingA2.1.4PerformLandingCMTCMTCMT
53OV-5b Example Red Text/Lines identify Critical Mission Threads CMTRequest Take Off Clearance_Ext_ Take-off ClearanceTake-off ReportPerformTake-offA2.1.1Position and Status InformationCMTIFF Response_Ext_ NDB SignalResponse To ATC InstructionPre-Landing Report_Ext_ IFF QueryDME Query_Ext_ TACAN BroadcastPerformEn-routeATC Check-in_Ext_ GPS SignalsNavigationRequest for Route/Altitude Change_Ext_ Air Traffic Control Informationand OperationsAir Refueling Clearance Request_Ext_ VOR SignalsAircraft StatusA2.1.2_Ext_ Strategic Tanker Check-in ResponseReceiveCheck-in InformationActivity model. Programs should be using UJTLs to a great extent. Note the critical pathways in red.Strategic_Ext_ Close Control InformationCollision Avoidance InformationIn-Flight_Ext_ Collision Avoidance InformationRefuelingTACAN Air to Air_Ext_ TACAN Air to AirA2.1.3CMT_Ext_ ILS SignalLanding Report_Ext_ MLS SignalPerformLandingRequest Landing Clearance_Ext_ Landing ClearanceA2.1.5
54OV-6c: Event-Trace Description Description: The OV-6c is valuable for moving to the next level of detail from the initial operational concepts. An OV-6c model helps define interactions and operational threads.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link OV-6c to:OV-2. Lifelines in OV-6c should map to operational resources in OV-2.OV-3. Events in OV-6c map to triggering events in OV-3.OV-5s. Events in OV-6c map to inputs and outputs of operationalactivities.The OV-6c can also help ensure that each participating Operational Activity andLocation has the necessary information it needs at the right time to perform itsassigned Operational Activity.
55OV-6c: Event-Trace Description ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link OV-6c to:SV-5s/SvcV-5. A capability associated with a specific sequencein OV-6c matches a capability in SV-5s/SvcV-5.
57System Viewpoints (SVs) DescriptionsSV-1 Systems InterfaceDescriptionIdentification of systems and system items andtheir interconnectionsSV-2 Systems CommunicationsSystems and system items and their relatedcommunications laydownsSV-4 Systems FunctionalityFunctions performed by systems and thesystem data flows among system functionsSV-5a Operational Activity toSystems Function TraceabilityMatrixMapping of system functions back to operationalactivitiesSV-5b Operational Activity toSystems Traceability MatrixMapping of systems back to capabilities oroperational activitiesSV-6 Systems Data ExchangeProvides details of system data elements beingexchanged between systems and the attributesof that exchange
58SV-1: Systems Interface Description Description: A SV-1 can be used simply to depict Systems andsub-systems and identify the Resource Flows between them.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SV-1 to:OV-2. Operational resources in OV-2 may be supported by one ormore systems in SV-1 (indicating that the operational resourceowns/uses the system). A needline in OV-2 may map to one ormore interfaces in an SV-1, and an interface in SV-1 maps to oneor more needlines in OV-2.The real benefit of a SV-1 is its ability to show the human aspects ofan architecture, and how these interact with Systems. If possible,a SV-1 shows Systems, Physical Assets, and System interfacesfor the entire Architectural Description on the same diagram. If asingle SV-1 is not possible, the resource of interest should bedecomposed into multiple SV-1 models.
59SV-1: Systems Interface DescriptionARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SV-1 to:SV-2. An interface in SV-1 is implemented by Systems, their ports,and the Resource Flows between those ports (communicationslink(s) or communications network(s)) in SV-2.SV-4. SV-4 defines system functions that are executed by systemsdefined in SV-1.SV-5 Systems in SV-1 match systems in SV-5.SV-6 Each system data element appearing in a system dataexchange is graphically depicted by one of the Interfaces inSV-1; an interface supports one or more system data exchanges.
60SV-1: Systems Interface Description Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SV-1 to:StdV-1 (TV-1). Technical standards in StdV-1 (TV-1) apply to andsometimes constrain systems, subsystems, and systemhardware/software items in SV-1.StdV-2 (TV-2). Timed standard forecasts in StdV-2 (TV-2) impactsystems, subsystems and system hardware/software items in SV-1.
62SV-2: Systems Resource Flow DescriptionDescription: A SV-2 comprises Systems, their ports, and theResource Flows between those ports. The architect may choose to create a diagram for each Resource Flow for all Systems or to show all the Resource Flows on one diagram if possible.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SV-2 to:SV-1. An interface in SV-1 is implemented by Systems, their ports,and the Resource Flows between those ports (communicationslink(s) or communications network(s)) in SV-2.Each SV-2 model can show which ports are connected, the Systems that thePorts belong to, and the definition of the System Resource Flow in terms of thephysical/logical connectivity and any protocols that are used in the connection.
63SV-2: Systems Resource Flow Description Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SV-2 to:StdV-1 (TV-1). Technical standards in StdV-1 (TV-1) apply to andsometimes constrain communications systems, communicationslinks, and communications networks in SV-2.StdV-2 (TV-2). Timed standard forecasts in StdV-1 (TV-2) impactcommunications systems, communications links, andcommunications networks in SV-2.
64LOCATIONS OF INTEREST) SV-2 ExampleDETAILEDPERSPECTIVEHIGH LEVELPERSPECTIVELOCATION ALOCATION BLOCATION CEXTERNAL CONNECTION(OUTSIDE THELOCATIONS OF INTEREST)COMMUNICATIONSPATHS, AND NETWORKSDETAILS OF COMMSINTERFACE 1CONNECTIONTO LOCATION BLOCATION ASystem1System2Two-WayCommunicationsPathsOne-WayCommuni-cationsPathSystem3System4Key ConceptsThe Systems Communications Description (SV-2) provides the ability to decompose the interfaces shown in the Systems Interface Description (SV-1).Specialized communications systems, such as routers and gateways, can be identified in SV-2. Communications systems are systems whose primary function is to control the transfer and movement of systems data as opposed to performing mission applications processing.Data ElementsCommunications System: Name, Description, Communications Standards/Protocols SupportedCommunications Link: Name, Description, Communications Standards/Protocols Supported, Capacity, Infrastructure Technology, End PointsCommunications Path: Name, Description, End Points, Links Included, Systems Interfaces ImplementedCommunications Network: Name, Description, Security Classification, Communications Links Included, Communications Systems Included, Systems Nodes/Systems AttachedLocal Area NetCONNECTIONTO LOCATION BSystem5EXTERNALCONNECTION(OUTSIDE THELOCATIONS OF INTEREST)SV-2 documents the communications network details, decomposing the interfaces from the System Interface DescriptionCONNECTIONTO LOCATION C64
66SV-4: Systems Functionality DescriptionDescription: The primary purposes of SV-4 are to develop a clear description of the necessary data flows that are input(consumed) by and output (produced) by each resource, toensure that the functional connectivity is complete (i.e., that aresource’s required inputs are all satisfied), and to ensure thatthe functional decomposition reaches an appropriate level ofdetail.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SV-4 to:SV-1. SV-4 defines system functions that are executed bysystems defined in SV-1.The Systems Functionality Description provides detailed information regardingthe allocation of functions to resources and the flow of resources betweenfunctions.
67SV-4: Systems Functionality Description ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SV-4 to:SV-5. System functions in SV-4 should map one-to-one to systemfunctions in SV-5.SV-6. System resource flows (data flows) in SV-4 should map tosystem resource flows (data elements) appearing in systemresource (data) exchanges of SV-6.StdV-1 (TV-1). Technical standards from StdV-1 (TV-1) apply tosystem functions in SV-4.StdV-2 (TV-2). Timed standard forecasts in StdV-2 (TV-2) impact
69SV-5a: Operational Activity to Systems Function Traceability Matrix SV-5b: Operational Activity to SystemsTraceability MatrixDescription: The SV-5s addresses the linkage between Systems and Systems Functions described in SV-4 Systems FunctionalityDescription and Operational Activities specified in OV-5aOperational Activity Decomposition Tree or OV-5b OperationalActivity Model.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SV-5s to:OV-5. Operational activities in SV-5 match operational activities inOV-5.The SV-5s depicts the mapping of system and system functions and, optionally,the capabilities and performers that provide them to operational activities. TheSV-5s identifies the transformation of an operational need into a purposefulaction performed by a system or solution.
70SV-5a: Operational Activity to Systems Function Traceability MatrixSV-5b: Operational Activity to SystemsTraceability MatrixARCHITECTURE DATA ELEMENT RELATIONSHIPSCONTINUED:Link SV-5s to:OV-6c. A capability associated with a specific sequence in OV-6cmatches a capability in SV-5.SV-1. Systems in SV-1 match systems in SV-5.SV-4. System functions in SV-4 should map one-to-one to systemfunctions in SV-5.
71SV-5 Example Activities Functions Allocated System System Function NumberAccess the Net-Centric EnvironmentConduct Aeromedical EvacuationConduct Air Refueling OperationsConduct Aircraft MaintenanceConduct CSAR/SOF Command and ControlConduct FARP OperationsConduct Intelligence DebriefingConduct Maintenance DebriefingConduct Operational DebriefingConduct Pre-flight Inspection and PreparationCrew PreparationJoin Voice NetworksLoad Mission Plan & Configure Aircraft SystemsMaintain Battlespace AwarenessPerform Air Drop DeliveryPerform Airland DeliveryPerform En-route Navigation and OperationsPerform LandingPerform Take-offPlan MissionReceive Strategic In-Flight RefuelingA2.2.2A2.3.6A2.3.1A1.4A2.3.3A2.3.2A1.3.2A1.3.3A1.3.1A1.2.3A1.2.2A2.2.1A2.3.7A2.3.5A2.3.4A2.1.2A2.1.4A2.1.1A1.1A2.1.3ILS/MLSConduct Instrument ApproachXPFPS, DTADS HostDebrief Intelligence FunctionGCSS/CAPREDebrief Maintenance FunctionPFPS, DTADS Host, Video RecorderDebrief Operations FunctionTACAN, Collision Avoidance SystemExecute Strategic RefuelingNAV, TACAN, GPS, ILS/MLSExecute Tactical Take-off and LandingEncryption System1.2.1Load Crypto KeysData Transfer and Diagnostic System (DTADS)1.2.2Load and Extract Mission DataRWR, NAV, TACAN, GPS, OFPMaintain Geospatial AwarenessPerform Refuel Mission Aircraft FunctionPFPS1.1Mk XII IFF SystemProvide Aircraft IdentificationRWRReceive Threat WarningIMDS, DTADSReport Maintenance ActivitiesFuture CapabilityActivitiesFunctionsPerformRefuelMissionAircraft1.3.2ProvideIdentificationConductInstrumentApproachMaintainGeospatialAwarenessDebriefMaintenanceOperationsIntelligencePre-flight andPost-flight220.127.116.11Execute TacticalTake-off andLandingExecuteStrategicRefuelingLoadCrypto KeysOperate Aircraft1.3.1Load and ExtractMission DataReceiveThreatWarningReportFly1.3PlanHC/MC-130Recap1
72NOTE: Each system Resource Flow exchange listed in the SV-6 SV-6: Systems ResourceFlow MatrixDescription: The SV-6 specifies the characteristics of ResourceFlow exchanges between systems. The SV-6 is the physicalequivalent of the logical OV-3 table and provides detailedinformation on the system connections. Non-automatedResource Flow exchanges, such as verbal orders, are alsocaptured.NOTE: Each system Resource Flow exchange listed in the SV-6table should be traceable to at least one operational Resource Flowexchanged listed in the corresponding OV-3 Operational ResourceFlow Matrix and these, in turn, trace to operation Resource Flows inthe OV-2 Operational Resource Flow Description.The focus of SV-6 is on how the System Resource Flow exchange is affected, insystem-specific details covering periodicity, timeliness, throughput, size,information assurance, and security characteristics of the resource exchange.In addition, the System Resource Flow elements, their format and mediatype, accuracy, units of measurement, and system data standard are alsodescribed in the matrix.
73SV-6: Systems Resource Flow Matrix Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPSLink SV-6 to:OV-3. If any part of an information element in OV-3 originatesfrom or flows to an operational activity that is to be automated,then that information element should map to one or moresystem data elements in SV-6.SV-1. Each system data element appearing in a system dataexchange is graphically interfaced in SV-1; an interface supportsone or more system data exchanges.SV-4. System data flows in SV-4 should map to system dataelements appearing in system data exchanges of SV-6.
74ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED: SV-6: Systems ResourceFlow Matrix ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SV-6 to:StdV-1 (TV-1) . Technical standards in StdV-1 (TV-1) apply to,and sometimes constrain, system data elements in SV-6.StdV-2 (TV-2). Timed standard forecasts in StdV-2 (TV-2)) affectsystem data elements in SV-6.
75SV-6 Example Interface Identification Data Exchange Identification System Node InterfaceOV-2 NeedlineCritical Mission ThreadSystem Data Exchange (SDX)2028Yes_Ext_ 15-Line Briefing_Ext_ ACO_Ext_ ATO
76SDX Text Description (Content) SV-6 Example ContinuedData DescriptionSDX Text Description (Content)Format TypeMedia TypeAccuracyUnits of MeasurementData Standard15-Line Briefing: 1 Call sign 2 Number of survivors 3 Location (coordinates, grid, etc.) 4 Injuries/conditions 5 Equipment (comm/signal) PLS code:ASCII TextFiber Optic Network97%BitsIETF RFC 1870, IETF RFCs , IETF RFC 2822, IETF RFCAirspace Control Order99%Air Tasking OrderIETF RFC 1870, IETF RFCs , IETF
77SV-6 Example Continued Producer Consumer From System Entity From System FunctionFrom System NodeTo System EntityTo System FunctionTo System NodeTBMCS_Ext_ Provide Theater Command and Control_Ext_ C2PFPSPlan MissionMission Planning Cell
79SV-6 Example Continued Information Assurance Access Control AvailabilityConfidentialityDissemination ControlIntegrityNon-Repudiation SenderNon-Repudiation Receiver03 = CLEARANCE02 = MED--SPECIFIC RESOURCES ALLOCATED04 = RESTRICTED--IAW ESTABLISHED POLICY04 = MANDATORY01 = PROOF OF ORIGIN RQD02 = PROOF OF REC N/R
80Protection (Type Name, Duration, Date) Classification Caveat SV-6 Example ContinuedInformation SecurityProtection (Type Name, Duration, Date)ClassificationClassification CaveatReleasability02 = ENCRYPT FOR TRANSMISSION ONLY (EFTO)11 = SECRET"12 - US ONLY"03 = CONDITIONAL
81Data and Information Viewpoints (DIVs) DescriptionsDIV-2: Logical Data ModelDocumentation of the data requirementsand structural business process rulesDIV-3: Physical Data ModelPhysical implementation of the LogicalData Model entities, e.g., messageformats, file structures, physical schema
82DIV-2 (OV-7): Logical Data Model Description: The documentation of the data requirements and structural business process (activity) rules. In DoDAF V1.5, this was the OV-7. The DIV-2 allows analysis of an architecture’s data definition aspect, without consideration of implementation specific or product specific issues.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link DIV-2 to:OV-3. An information element in OV-3 should be constructed ofentities in DIV-2 (OV-7).StdV-1 (TV-1). Technical standards in StdV-1 (TV-1) apply tomodeling techniques in DIV-2 (OV-7).Another purpose is to provide a common dictionary of data definitions toconsistently express models wherever logical-level data elements are includedin the descriptions.
84DIV-2 (OV-7) ExampleInformation Elements defined in OV-2/OV-3 are reused in DIV2 (OV-7).
85DIV-3 (SV-11): Physical Data Model Description: The DIV-3 defines the structure of the variouskinds of system or service data that are utilized by the systemsor services in the Architectural Description. The PhysicalSchema is one of the models closest to actual system design inDoDAF.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link DIV-3 (SV-11) to:StdV-1 (TV-1). Technical standards in StdV-1 (TV-1) apply tomodeling techniques in DIV-3 (SV-11).DIV-3 is used to describe how the information represented in the DIV-2 Logical Data Model isactually implemented. Specifying the system/service data elements exchanged betweenSystems and/or services, thus reducing the risk of interoperability errors.• Definition of physical data structure.• Providing as much detail as possible on data elements exchanged between systems, thusreducing the risk of interoperability problems.• Providing data structures for use in the system design process, if necessary.• Providing a common dictionary of data implementation elements (e.g., tables and records in a relational database schema) to consistently express models wherever physical-level data elements are included in the descriptions.• Providing as much detail as possible on the system or service data elements exchangedbetween systems, thus reducing the risk of interfacing errors.• Providing system and service data structures for use in the system and service design process, if necessary.The essential elements of a physical data schema model (in the case of a relationaldatabase) are: tables, records and keys. In an object-oriented data model, all data elements are expressed as objects; whether they are classes, instances, attributes, relationships, or events.
87DIV-3 (SV-11) ExampleSystem Data Elements defined in SV-6 are reused in DIV-3 (SV-11).System Data Element may implement Information Element from OV-3.“The Physical Schema product is one of the architecture products closest to actual system design in the Framework. The product defines the structure of the various kinds of system data that are utilized by the systems in the architecture.DIV-3 (SV-11) is an implementation-oriented data model that is used in the Systems View to describe how the information requirements represented in Logical Data Model DIV-2 (OV-7) are actually implemented. Entities represent (a) system data flows in SV-4, (b) system data elements specified in SV-6.
88Standards Viewpoints (StdVs) DescriptionsStandards View-1Standards Profile (StdV-1)Listing of standards that apply to solutionelements in a given architectureStandards View-2Standards Forecast (StdV-2)Description of emerging standards andpotential impact on current solutionelements, within a set of time frames
89StdV-1 (TV-1): Standards Profile Description: The StdV-1 defines the technical, operational, andbusiness standards, guidance, and policy applicable to thearchitecture being described. As well as identifying applicabletechnical standards, the DoDAF V2.0 StdV-1 also documents thepolicies and standards that apply to the operational or businesscontext. The DISR is an architecture resource for technicalstandards that can be used in the generation of the StdV-1.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link StdV-1 (TV-1) to:DIV-2 (OV-7). Technical standards in StdV-1 (TV-1) apply to modelingtechniques in DIV-2 (OV-7).SV-1. Technical standards in StdV-1 (TV-1) apply to, and sometimesconstrain, systems, subsystems, and system hardware/software itemsin SV-1.Standards Profiles for a particular architecture must maintain full compatibility with the root standards they have been derived from. In addition, the StdV-1 model may state a particular method of implementation for a Standard, as compliance with a Standard does not ensure interoperability. The Standards cited are referenced as relationships to the systems, services, system functions, service functions, system data, service data, hardware/software items or communication protocols, where applicable, in:• SV-1 Systems Interface Description.• SV-2 Systems Resource Flow Description.• SV-4 Systems Functionality Description.• SV-6 Systems Resource Flow Matrix.• SvcV-1 Services Context Description.• SvcV-2 Services Resource Flow Description.• SvcV-4 Services Functionality Description.• SvcV-6 Services Resource Flow Matrix.• DIV-2 Logical Data Model.• DIV-3 Physical Data Model..
90StdV-1 (TV-1): Standards Profile ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link StdV-1 (TV-1) to:SV-2. Technical standards in StdV-1 (TV-1) apply to, and sometimesconstrain, communications systems, communications links, andcommunications networks in SV-2.SV-4. Technical standards from StdV-1 (TV-1) apply to systemfunctions in SV-4.SV-6. Technical standards in StdV-1 (TV-1) apply to, and sometimesconstrain, system data elements in SV-6.DIV-3 (SV-11). Technical standards in StdV-1 (TV-1) apply tomodeling techniques in DIV-3 (SV-11).
92StdV-2 (TV-2): Physical Data Model Description: The StdV-2 contains expected changes in technologyrelated standards, operational standards, or business standardsand conventions, which are documented in the StdV-1 model.StdV-2 lists emerging or evolving standards relevant to the solutionscovered by the Architectural Description.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link StdV-2 (TV-2) to:SV-1. Timed standard forecasts in StdV-2 (TV-2) affect systems,subsystems and system hardware/software items in SV-1.SV-2. Timed standard forecasts in StdV-2 (TV-2) affectcommunications systems, communications links, and communicationsnetworks in SV-2.StdV-2 delineates the standards that potentially impact the relevant system and service elements (from SV-1 Systems Interface Description, SV-2 Systems Resource Flow Description, SV-4 Systems Functionality Description, SV-6 Systems Resource Flow Matrix, SvcV-1 Services Context Description, SvcV-2 Services Resource Flow Description, SvcV-4 Services Functionality Description, SV-6 Services Resource Flow Matrix, and DIV-2 Logical Data Model)
93StdV-2 (TV-2): Physical Data Model ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link StdV-2 (TV-2) to:SV-4. Timed standard forecasts in StdV-2 (TV-2) affect systemfunctions in SV-4.SV-6. Timed standard forecasts in StdV-2 (TV-2) affect system dataelements in SV-6.
95Service Viewpoints (SvcVs) DescriptionsSvcV-1 Services InterfaceDescriptionIdentification of services and serviceitems and their interconnectionsSvcV-2 Services CommunicationsServices and service items and theirRelated communications laydownsSvcV-4 Services FunctionalityFunctions performed by services and theservice data flows among servicefunctionsSvcV-5 Operational Activity toServices Traceability MatrixMapping of services back to operationalactivitiesSvcV-6 Services Data ExchangeMatrixProvides details of system or servicedata elements being exchanged betweenservices and the attributes of thatexchange
96SvcV-1: Services Interface Description Description: The SvcV-1 addresses the composition and interactionof Services. It is important to recognize that the SvcV-1 focuses onthe Resource Flow and the providing service.NOTE: A Service Resource Flow is a simplified representationof a pathway or network pattern, usually depicted graphically as aconnector (i.e., a line with possible amplifying information).This differs from a SV-1 System Interface Description which focuses on theSystem-to-System point-to-point interface, for which the Source System andTarget System have an agreed upon interface. For the SvcV-1, the focus on theprovider and the data provided is a Net-Centric Data Strategy tenet appropriatefor a publish/subscribe pattern.
97SvcV-1: Services Interface Description Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SvcV-1 to:OV-2. Operational resources in OV-2 may be supported by one ormore services in SvcV-1 (indicating that the operational resourceowns/uses the service). A needline in OV-2 may map to one ormore services in an SvcV-1, and an service in SV-1 maps toone or more needlines in OV-2.SvcV-2. A service in SvcV-1 is implemented by Services, theirports, and the Resource Flows between those ports(communications link(s) or communications network(s)) inSvcV-2.SvcV-4. SvcV-4 defines services functions that are executed byservices defined in SvcV-1.
98SvcV-1: Services Interface Description Continued ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SvcV-1 to:SvcV-5 Services in SvcV-1 match services in SvcV-5.SvcV-6 Each service data element appearing in a service dataexchange is graphically depicted by one of the services inSvcV-1; a service supports one or more service data exchangesStdV-1 (TV-1). Technical standards in StdV-1 (TV-1) apply to andsometimes constrain services, subservices, and servicehardware/software items in SvcV-1.StdV-2 (TV-2). Timed standard forecasts in StdV-2 (TV-2) impactservices, subservices and service hardware/software items inSvcV-1.
100SvcV-2: Services Resource Flow Description Description: A SvcV-2 specifies the Resource Flows betweenservices for a network data service, a SvcV-2 comprises services,their ports, and the Service Resource Flows between those ports.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SvcV-2 to:SvcV-1. An service in SvcV-1 is implemented by Services, theirports, and the Resource Flows between those ports(communications link(s) or communications network(s)) in SvcV-2.The SvcV-2 may also be used to describe non-IT type services such as Searchand Rescue. The architect may choose to create a diagram for each ServiceResource Flow and the producing service, each Service Resource Flow andconsuming Service, or to show all the Service Resource Flows on one diagram, ifthis is possible.
101Description Continued SvcV-2: Services Resource FlowDescription ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SvcV-2 to:StdV-1 (TV-1). Technical standards in StdV-1 (TV-1) apply to andsometimes constrain communications services, communicationslinks, and communications networks in SvcV-2.StdV-2 (TV-2). Timed standard forecasts in StdV-1 (TV-2) impactcommunications services, communications links, andcommunications networks in SvcV-2.
102SvcV-2 Example No viewpoint example yet available. Similar to SV-2 but focus is on services
103SvcV-4: Services Functionality DescriptionDescription: The primary purpose of SvcV-4 is to develop a cleardescription of the necessary data flows that are input consumed)by and output (produced) by each resource, ensure that theservice functional connectivity is complete (i.e., that a resource’srequired inputs are all satisfied), and to ensure that the functional decomposition reaches an appropriate level of detail. The SvcV-4is the Services Viewpoint counterpart to the OV-5b Operational ActivityModel of the Operational Viewpoint.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SvcV-4 to:SvcV-1. SvcV-4 defines service functions that are executed byservices defined in SvcV-1.There are two basic ways to depict a SvcV-4:• The Taxonomic Service Functional Hierarchy shows a decomposition of service functions depicted in a tree structure and is typically used where tasks are concurrent but dependent, such as a production line, for example.• The Data Flow Diagram shows service functions connected by data flow arrows and data stores.
104SvcV-4: Services Functionality Description ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SvcV-4 to:SvcV-5. Service functions in SvcV-4 should map one-to-one to servicefunctions in SvcV-5.SvcV-6. Service resource flows (data flows) in SvcV-4 should map toservice resource flows (data elements) appearing in serviceresource (data) exchanges of SvcV-6.StdV-1 (TV-1). Technical standards from StdV-1 (TV-1) apply toservice functions in SvcV-4.StdV-2 (TV-2). Timed standard forecasts in StdV-2 (TV-2) impact
106Services Traceability Matrix SvcV-5: Operational Activity toServices Traceability MatrixDescription: The SvcV-5 addresses the linkage between servicefunctions described in SvcV-4 and Operational Activitiesspecified in OV-5a Operational Activity Decomposition Tree orOV-5b Operational Activity Model.ARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SvcV-5s to:OV-5. Operational activities in SvcV-5 match operational activitiesin OV-5s.The SvcV-5 depicts the mapping of service functions (and, optionally, thecapabilities and performers that provide them) to operational activities andthus identifies the transformation of an operational need into a purposefulaction performed by a service solution.
107Services Traceability Matrix Continued SvcV-5: Operational Activity toServices Traceability MatrixContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS:Link SvcV-5s to:OV-6c. A capability associated with a specific sequence in OV-6cmatches a capability in SvcV-5.SvcV-1. Services in SvcV-1 match services in SvcV-5.SvcV-4. Services functions in SvcV-4 should map one-to-one toservices functions in SvcV-5.
108SvcV-5 Example Activities to Function Mapping for Time-Sensitive Targeting SvcV-5
109SvcV-6: Services Resource Flow MatrixDescription: The SvcV-6 specifies the characteristics of theService Resource Flows exchanged between Services, usuallyin a tabular format. The focus of SvcV-6 is on how the ServiceResource Flow exchange is affected, in service specific detailscovering periodicity, timeliness, throughput, size, informationassurance, and security characteristics of the resourceexchange. In addition, for Service Resource Flow of data, theirformat and media type, accuracy, units of measurement,applicable system data standards, and any DIV-3 PhysicalData Models are also described or referenced in the matrix.NOTE: Each system Resource Flow exchange listed in the SvcV-6table should be traceable to at least one operational Resource Flowexchanged listed in the corresponding OV-3 Operational ResourceFlow Matrix and these, in turn, trace to operation Resource Flows inthe OV-2 Operational Resource Flow Description.Modeling discipline is needed to ensure that the architecture models are coherent. Each Service Resource Flow exchange listed in the SvcV-6 table should be traceable to at least one Operational Resource Flow exchanged listed in the corresponding OV-3 Operational Resource Flow Matrix and these in turn trace to OV-2 Operational Resource Flow Description.
110SvcV-6: Services Resource Flow Matrix ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SvcV-6 to:OV-3. If any part of a resource (information element) in OV-3originates from or flows to an operational resource that is to beautomated, then that resource (information element) should map toone or more service resources (data elements) in SvcV-6.SvcV-1. Each service resource (data element) appearing in a serviceresource (data exchange) is graphically interfaced in SvcV-1; aninterface supports one or more service resource (data exchanges).SvcV-4. Resource service data flows in SvcV-4 should map toservice resource (data elements) appearing in service resources(data exchanges) of SvcV-6.
111SvcV-6: Services Resource Flow Matrix ContinuedARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED:Link SvcV-6 to:StdV-1 (TV-1) . Technical standards in StdV-1 (TV-1) apply to,and sometimes constrain, service resource (data elements) inSvcV-6.StdV-2 (TV-2). Timed standard forecasts in StdV-2 (TV-2)) affectservice resource (data elements) in SvcV-6.
112SvcV-6 Example Not identical to V 1.5 columns Nature of TransactionData SourceData DestinationContentSizeFormatSourceSystem NameReceivingSource SystemFunctionSystem FunctionOtherProtocolsIdentifier/Name ofOperationalNeedlineSupported(from OV-2)Identifier/Name of OperationalInformation Exchange(from OV-3)e.g., 1-ae.g., 1-bCorrespondingSystem Interface(s)(from SV-1)e.g., Interface 1e.g., Interface 2.e.g., Interface n12ne.g., 1-ce.g., 1-dSystem DataExchangee.g., 1-a (1)e.g., 1-a (n)DataStandardKey ConceptsThis is the Services View version of the Operational Resource Exchange Matrix (OV-3).The Services Data Exchange Matrix (SvcV-6) provides traceability between the operational resource (information) exchanges and the services data exchanges for those resource (information) exchanges that are automated.Data ElementsDescriptions of any codes for values in the attribute columnsDocuments data/resource exchanges among systems and how information exchanges are implemented. For services, the focus is the resource flows produced and consumed by each services. Column headings are no longer specified.112
113SvcV-6 Example Continued Performance AttributesInformation Assurance AttributesPhysical EnvironmentFrequencyTimelinessThroughputThreatsPhysicalElectronicAerospaceSeaLandPolitical/EconomicClassificationCriticality/PriorityEncryptionAuthenticationOther.113
114DoDAF V2.0 Summary The continuous evolution of DODAF is compelling and necessaryThe success of DOD architecting is dependent onsimplifying and streamlining the DODAFAligning architecture with key transformation issues suchas portfolio management, JCIDS, and resourcemanagement is criticalShifting OSD architecture policy away from products andtoward data is important
115DoDAF V2.0 Summary Continued DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture developmentIt 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 changeThe models provide choices, based upon the decision-maker needsAdoption 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
116Frequently Asked Questions The most commonly asked:1. Do all models/views need to be created?2. What is the minimum set of models/views that need to be created?3. Am I required to use specific tools for developing architectural descriptions?4. What about methodologies? Is there a required methodology?5. Where do I go for more information?No, the models and views needed depend on the purpose, scope, and the policy and regulatory requirements that guide the development.DoDAF does not prescribe any mandatory models or views. Policy, such as CJCSI 6212 and 3170, indicates the specific requirements for systems/services developed under those policies. In any architectural development, there may be multiple stakeholders, with unique and overlapping requirements for models and views. What DoDAF does prescribe is the data that is necessary for that model or view.No. DoDAF does not prescribe particular toolsets for developing architectural descriptions. Any toolset capable of importing and exporting the Physical Exchange Specification (PES) Data described in DoDAF Volume 3 can be used.DoDAF is methodology, technique, and notation agnostic. That means architects and teams can use the methodology, supporting techniques, or notations that are prescribed by their own leaders. DoDAF, Volume 1 provides a notional methodology to ensure that any selected methodology can be compared to it for completeness of the steps needed from planning to execution. Similarly, architects and teams can use varying techniques (SADT, IDEF, UML, etc.) or notations (BPMN, etc.) that will facilitate their desired end results, such as process improvement, systems or services development, or a combination of both.The DoDAF Journal is the first place at https://www.us.army.mil/suite/page/ along with the volumes of DoDAF. At the appendices of DoDAF Volume 1, there is a bibliography of know sources of information. The DoDAF Journal will expand over time to include more lessons learned, examples, and other resources to assist development teams.
117DoDAF Website Overview Public DoDAF WebsiteOpen to publicHosted on the DoD CIO/NII websitePrivate DoDAF WebsiteNeed Government SponsorNeed AccountChange Request SubmissionHosted on DKO Homepagehttps://www.us.army.mil/suite/page/454707117
118Engineering and Policy Branch DoDAF V2.0, Vol 1-3 is also available at JITC INTRANET:Questions?Engineering and Policy BranchJune 2010
120Architectural Description Architecture data Architectural data Product Terms UpdatedDoDAF V1.5DoDAF V2.0ArchitectureArchitectural DescriptionArchitecture dataArchitectural dataProductDoDAF-described ModelFit-for-Purpose View*ViewViewpoint*User defined
121DoDAF V2.0 Promulgation Memo Version 2.0 is the prescribed framework for all Department architectures and represents a substantial shift in approachDon’t redo current architectureArchitectures shall comply with Version 2.0 in their next major releaseUpdate only in the next release
122DoDAF V2.0 ConformanceThe 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. Powerpoint, Visio, Excel, etc. 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 Physical Exchange Specification (PES)Architectures that will exchange information need to comply with DM2 PES (for the appropriate architectural data)
123Data-Centric Paradigm Prior versions of DoDAF emphasized ‘products’ (i.e., graphical representations or documents).DoDAF V2.0 emphasizes the capture and analysis of data and its relationships, rather than the creation 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.As such, DoDAF 2.0 is a data-centric paradigm, as opposed to a “product-centric” paradigm.Emphasizes the capture and analysis of dataSupport for decision making and “information consumption”123
125DoDAF ConformanceDoD Components are expected to conform to DoDAF to the maximumextent possible in development of architectures within the DepartmentConformance ensures that reuse of information, architecture artifacts,models, and viewpoints can be shared with common understandingConformance is expected in both the classified and unclassifiedcommunitiesNOTE: DoDAF does not prescribe any particular Views, but instead concentrates on data as the necessary ingredient for architecture development. However, other regulations and instructions from both DoD and CJCS may have particular presentation view requirements. These Views are supported by DoDAF 2.0, and should be consulted for specific view requirements.
126These Basic Products Link to Each Other HIGH-LEVEL OPERATIONALCONCEPT DESCRIPTION (OV-1)STANDARDS PROFILE (StdV-1)VALUE ADDED: SUMMARY LEVEL REPRESENTATION OF ORGANIZATIONS/ROLES, MISSION, AND CONTEXT FOR THE ARCHITECTUREVALUE ADDED: COMPLETE LIST OF RELEVANT STANDARDS WITH OPTIONS & PARAMETERSOPERATIONAL CONCEPT ROLES & MISSIONS SET SCOPE FOR ACTIVITY MODELSTANDARDS APPLY ATSYSTEM TO SYSTEMINTERFACESOPERATIONAL ACTIVITY MODEL (OV-5)ACTIVITIES MAP TO OV-2 PERFORMERSI/OS MAP TO NEEDLINESPERFORMERS OF ACTIVITIES, IF SHOWN ON 0V-5, MAP TO OV-2 PERFORMERSSYSTEMS INTERFACE DESCRIPTION(SV-1)OPERATIONAL CONCEPT CONNECTIVITY & RESOURCE EXCHANGES, IF SHOWN ON 0V-1, MAP TO OV-2 NEEDLINES & RESOURCE EXCHANGESVALUE ADDED: BUSINESS/MISSION PROCESS & RELATIONSHIPS AMONG ACTIVITIES AND RESOURCE EXCHANGESRESOURCE EXCHANGES ASSOCIATED WITH EACH NEEDLINE ARE DETAILED IN OV-3INPUT/OUTPUT LABELS MAP TO OPERATIONAL RESOURCE EXCHANGES (NOT ALWAYS ONE-TO-ONE)This figure summarizes the relationships among the core products.OPERATIONAL RESSOURCE FLOWDESCRIPTION (OV-2)VALUE ADDED: STATEMENT OF LOCATIONS,SYSTEMS & INTERFACESPERFORMERS ARE ASSOCIATEAD WITH SYSTEMS AND LOCATIONSEACH OPERATIONAL NEEDLINE MAPS TO ONE OR MORE SYSTEM INTERFACESOPERATIONAL RESOURCE FLOW MATRIX(OV-3)VALUE ADDED: INDIVIDUAL RESOURCE EXCHANGESASSOCIATED WITH EACH NEEDLINE & PERFORMANCE REQUIREMENTSVALUE ADDED: STATEMENT OFOPERATIONAL PERFORMERS, ACTIVITIES, AND CRITICALRESOURCE EXCHANGE NEEDS126
127Project Viewpoints (PVs) DescriptionsPV-1: Project PortfolioRelationshipsOrganizational structures needed to managea portfolio of projects and showsdependency relationships between theorganizations and projects.PV-2: Project TimelinesA timeline perspective on programs orprojects, with the key milestones andinterdependenciesPV-3: Project toCapability MappingMapping of programs and projects tocapabilities to show how the specificprojects and program elements help toachieve a capability
128Capability Viewpoints (CVs) DescriptionCV-1: VisionOverall vision for transformational endeavors,provides a strategic context for the capabilitiesdescribed, and provides a high-level scope.CV-2: Capability TaxonomyA hierarchy of capabilities, specifies all thecapabilities that are referenced throughout oneor more architectures.CV-3: Capability PhasingPlanned achievement of capability at differentpoints in time or during specific periods of time.CV-4: Capability DependenciesDependencies between planned capabilities anddefines logical groupings of capabilities.CV-5: Capability to OrganizationalDevelopment MappingThe fulfillment of capability requirements, showsthe planned capability deployment andinterconnection for a particular Capability Phase.CV-6: Capability to OperationalActivities MappingMapping between the capabilities required andthe operational activities that those capabilitiessupport.CV-7: Capability to ServicesMappingMapping between capabilities and the servicesthat these capabilities enable.
129Scoping Architecture Work Six Step Process (V2.0) - The Planning Perspective123456Determine the intended use of the architectureScopingArchitecture WorkPlanning theArchitecture ProjectDetermine scope of the architectureDetermine data required to support architecture developmentCollect, organize, correlate, and store architecture dataConduct analyses in support of architecture objectivesDocument results IAW with Decision-Maker needsWhat Needs to be DoneHow the Work Will Be Done
130Before DoDAF 2.0, Node was used inconsistently. Node in DoDAF 1.5Before DoDAF 2.0, Node was used inconsistently.There was confusion around what Node represented and how it should be interpreted.OrganizationFunctional GroupingLocationFacilityProgram, etc.Before DoDAF 2.0 Nodes were not explicitly defined.130
131Node Concept in DoDAF V2.0 DoDAF 1.x DoDAF 2.0 Location Organization Person TypePerformerSystemNodeBefore DoDAF 2.0 Nodes were not explicitly defined.Functional Grouping(Activity)ServiceProgram(Project)131
132We are forced to be more precise. What’s the Benefit?We are forced to be more precise.Consider the relationship Node to Activity for example:In DoDAF 1.5:Node to Operational Activity“Who does what”?“Where things happen”?132
133What’s the Benefit? DoDAF 2.0 If Node is a Performer (Organization, Person Type, System, Service)Performer Performs Activity “Who does what”If Node is a LocationActivity is Performed at Location “What happens where”If Node is a Functional Grouping (Activity)Activity is Part of Functional Grouping “Activity is part of”If Node is a Program (Project)Activity is Part of Program (Project) “Activity is part of”133