1 / 133

Fred Haukaas JT4A June 2010

DOD Architecture Framework (DoDAF) Relevance to JITC Testing. Fred Haukaas JT4A June 2010. DoDAF’s Role in JITC Testing. What is going on with DoDAF? DoDAF Evolution A look at DoDAF 2.0 What Architecture Viewpoints do JITC Testers need to be aware of? All Viewpoints (AV-1 and AV-2)

tyrell
Download Presentation

Fred Haukaas JT4A June 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DOD Architecture Framework (DoDAF) Relevance to JITC Testing Fred Haukaas JT4A June 2010

  2. DoDAF’s Role in JITC Testing • What is going on with DoDAF? • DoDAF Evolution • A look at DoDAF 2.0 • What 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-6C • System 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)

  3. The Importance of DoDAF Evolution • As our Department policies and decision processes evolve, so must the DoDAF • DoDAF v1.5 represented an important step toward addressing the requirements of the Net-Centric Environment in architectures • DoDAF v2.0 must address evolving information requirements • of the Department using both top-down and bottom-up approaches • Information Sharing • Support for the Net-Centric Data and Services Strategies of the Department • Portfolio Management

  4. Net-Centric Concepts were addressed in DoDAF 1.5 • The following Net-Centric Concepts were presented and discussed in DoDAF 1.5 • Populate the Net-Centric Environment (NCE) • 2. Utilize the NCE • 3. Support the Unanticipated user • 4. Leverage Communities of Interest (COIs) to promote Jointness • 5. Support Shared Infrastructure

  5. Key Policies Requiring DoDAF DoD DoDI 4630.8, 30 June 2004, "Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)“ Joint Staff CJCSI 3170.01G, 1 MARCH 2009, “JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM” Manual for CJCSI 3170.01G, APRIL 2009, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM” CJCSI 6212.01E, 15 December 2008, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS” Direct support for the Warfighter

  6. Moving From DoDAF 1.5to DoDAF 2.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

  7. DoDAF V2.0What are we delivering? • 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 • DoDAF 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 volumes

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

  9. DoDAF V2.0 Focus Results: Better ANALYSIS and Decisions. Focus: architecture DATA, not Products DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development.

  10. Architecture Models + Data = Architectural Description Operational ModelExample • Things • Individuals • Types or classes of individuals or things 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.

  11. Key Concepts • DoDAF is prescribed for the use and development of Architectural Descriptions in the Department • 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 V2.0 is data-centric and has shifted from the DoDAF V1.5 focus on Products • DoDAF V2.0 prescribes a discipline for Architecture Development to determine the purpose and scope of the architecture before the data and Viewpoints are selected • Node has been decomposed into more concrete concepts • Examples will appear in the DoDAF Journal.

  12. Key Points • The 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 and • vendors that will enable sharing architecture information in a net- • centric environment

  13. Key Points Continued • Another 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 frameworks

  14. DoDAF 2.0 Provides these Viewpoints Renamed New New New Architecture viewpoints are composed of data that has been organized to facilitate understanding. New Data models split out into separate Viewpoint in V2.0 Services views split out into separate viewpoint in V2.0

  15. All Viewpoints (AVs)

  16. AV-1: Overview and Summary Information • Description: The overview and summary information contained • within the AV-1 provides executive-level summary information • in a consistent form that allows quick reference and comparison • between Architectural Descriptions. ARCHITECTURE RELATIONSHIPS: • LINK AV-1 to all architecture viewpoints.

  17. AV-1 Example Department of Defense Business Enterprise Architecture 7.0 Overview and Summary Information (AV-1) March 12, 2010

  18. AV-1 Example Continued Scope: Architecture View(s) and Products Identification

  19. AV-1 Example Continued

  20. AV-1 Example Continued

  21. AV-2: Integrated Dictionary • Description: The AV-2 presents all the metadata used in an • architecture. An AV-2 presents all the data as a hierarchy, • provides a text definition for each one and references the • source of the element (e.g., DoDAF Meta-model, IDEAS, a • published document or policy). • ARCHITECTURE RELATIONSHIPS: • LINK AV-2 to: • AV-1. AV-2 defines capabilities by identifying overall objectives of • the system, what are the goals of the system, and what are the • major design constraints from AV-1. • .

  22. ARCHITECTURE 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-3 OV-2. AV-2 defines resources by identifying the relationships among the resources from OV-2. OV-3. AV-2 defines resources by identifying the relationships among the resources from OV-3 AV-2: Integrated Dictionary Continued

  23. ARCHITECTURE RELATIONSHIPS: LINK AV-2 to: OV-4. AV-2 defines performers by identifying those that actively contribute toward the completion of activities or the achievement of an objective from OV-4. OV-5. AV-2 defines activities by identifying the major processes of the system that are needed to provide the desired capabilities from OV-5. OV-6c. AV-2 defines activities and performers by Breaking the major processes into those activities necessary to achieve the objectives of each process from OV-6c. AV-2: Integrated Dictionary Continued

  24. AV-2 Example

  25. Operational Viewpoints (OVs)

  26. OV-1: High Level Operational Concept Graphic • Description: 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.

  27. OV-1 Example

  28. OV-1 Example

  29. OV-2: Operational Resource Flow Description • Description: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 in OV-2; relationships in OV-1 should trace to needlines in OV-2. • OV-3. A needline in OV-2 maps to one or more information • exchanges in OV-3.

  30. ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED: Link OV-2 to: OV-4. Organizations, organization types, and/or human roles in an OV-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-2 map to the activities described in an OV-5. Similarly, OV-5 should document the operational resources that participate in each operational activity. OV-2: Operational Resource Flow Description Continued

  31. ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED: Link OV-2 to: OV-6c. Lifelines in OV-6c should map to operational resources in OV-2. SV-1. Operational resources in an OV-2 may be supported by one or more systems in SV-1 (indicating that the operational resources owns/uses the system). A needline in OV-2 may map to one or more interfaces in SV-1, and an interface in SV-1 maps to one or more needlines in OV-2. SvcV-1. Operational resources in an OV-2 may be supported by one or more services in SvcV-1 (indicating that the operational resource owns/uses the service). A needline in OV-2 may map to one or more interfaces in SvcV-1, and an interface in SvcV-1 maps to one or more needlines in OV-2. OV-2: Operational Resource Flow Description Continued

  32. OV-2 Example

  33. OV-3: Operational Resource Flow Matrix • Description: 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.

  34. ARCHITECTURE DATA ELEMENT RELATIONSHIPS CONTINUED: Link OV-3 to: OV-5. An information exchange in OV-3 should map to one or more information flows (an external Input, an external output, or an output from one operational activity mapped to an input to another) in OV-5, if OV-5 decomposes to a level that permits such a mapping. Above that level of decomposition, a single information flow 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 be constructed of entities in DIV-2 (OV-7). OV-3: Operational Resource Flow Matrix Continued

  35. OV-3 Example

  36. OV-3 Example Continued

  37. OV-3 Example Continued

  38. OV-3 Example Continued

  39. OV-3 Example Continued

  40. OV-3 Example Continued

  41. OV-3 Example 2

  42. OV-3 Example 2 Continued

  43. OV-3 Example 2 Continued

  44. OV-3 Example 2 Continued

  45. OV-3 Example 2 Continued

  46. OV-4: Organizational Relationships Chart • Description: 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 in • an OV-4 may map to one or more operational resources in an • OV-2, indicating that the resource represents the organization.

  47. OV-4 Generic Example

  48. USSTRATCOM Army Space Navy Space Air Force Space Command Command Command 14th Air Force 20th Air Force SPACEAF USSTRATCOM JIC 50th Space 21st Space Wing Wing Satellite 1st SPCS Tracking SCC Network Command Relationship Missile Warning Squadrons Squadrons Coordination Line Space Surveillance Squadrons SBSS Control Squadron OV-4 Example

  49. OV-5a: Operational Activity Decomposition Tree OV-5b: Operational Activity Model • Description: 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-5b

  50. OV-5a: Operational Activity Decomposition Tree OV-5b: Operational Activity Model • ARCHITECTURE DATA ELEMENT RELATIONSHIPS: • Link OV-5 to: • OV-2. The activities annotating an operational resource in an OV-2 • map to the activities described in an OV-5. Similarly, OV-5 should • document the operational resources that participate in each • operational activity. • OV-3. An information exchange in an OV-3 should map to one or • more information flows (an external input, an external output, or an • output from one operational activity mapped to an input to another) • in OV-5, if OV-5 decomposes to a level that permits such a • mapping. Above that level of decomposition, a single information • flow in OV-5 may map to more than one information exchange (or • none, if the information flow does not cross resource boundaries).

More Related