Hide Notes 

Slide 1: Relating the Mission and Means Framework to DoD Architecture Framework Products T he U niversity of Texas at A ustin ARL Jim Watkins Applied Research Laboratories The University of Texas
Slide 2: Game Plan • • • • Historical Perspectives on Architecture Frameworks DoD Architecture Framework Views and Products Mission and Means Framework Relating MMF Levels and Operators to DoD AF Views and Products Conclusions • 2
Slide 3: Historical Perspectives • Command and Control experiences in Grenada, Desert Storm, etc • Government Performance and Results Act of 1993 • Information Technology Management Reform Act of 1996 (Clinger-Cohen) • Defense Science Board, et al • C4ISR Architecture Framework, Version 1.0, 7 June 1996 • C4ISR Architecture Framework, Version 2.0 18 Dec 1997 • OSD Memo, 23 Feb 1998: Strategic Direction for a DoD Architecture Framework USD(A&T), ASD(C3I), and J6 • DoD Architecture Framework (30 August 2003) 3
Slide 4: Architecture Description A representation of a defined domain in terms of its component parts, what these parts do, how the parts relate to each other, and the rules and constraints under which the parts function • Descriptions can vary widely with regard to degree of detail – Domains can be extraordinarily broad (e.g. DoD) or narrow (one component of a communications network) – Functional descriptions of domains can be very general or specific – Rules and constraints can be high-level and broad or task-level and specific 4
Slide 5: The Architecture Description Process 1 Determine the intended use of the architecture 2 Determine scope of architecture 3 Determine characteristics to be captured 4 Determine views and products to be built 5 Build the requisite products 6 Use architecture for the intended purpose 5
Slide 6: Integrated Architecture Definition: An architecture consisting of multiple views (operational, systems, and technical standards) that facilitate integration and promote interoperability across family-ofsystems (FoS), system-of-systems (SoS) and compatibility among related mission area architectures. DoDD 4630.5, Jan 11, 2002 Interoperability and Supportability of Information Technology and National Security Systems Integrated architectures provide a logical, structured approach for defining how forces operate, the associated information flow, the relation between that information flow and system capabilities, and the relation between system capabilities and technical standards. 6
Slide 7: Architecture Framework • What it consists of – Common definitions, products, data, and references • What it does – Provides guidance on how to describe architectures – Provides a generic problem space and a common vocabulary within which individuals can cooperate to solve a specific problem – Provides the rules, guidance, and product descriptions for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures – Can be leveraged to provide at least a starter set of issues and concerns that must be addressed in architecture development • What it does not do – Provide guidance on how to design or implement a specific architecture – Provide guidance on how to develop or acquire systems 7
Slide 8: Architecture and Engineering A Dynamic Tension Architecture: The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. DoD Integrated Architecture Panel 1995, based on IEEE STD 610.12 The architect: articulates through the design the vision of the operator System: A set of interacting components in which the behavior of each component affects the behavior of the whole set Systems Engineering: The design, production, and maintenance of trustworthy systems within cost and time constraints An interdisciplinary process that ensures that a customer’s needs are satisfied throughout a system’s entire life-cycle The system engineer: implements a system that conforms to the architecture within cost and time constraints 8
Slide 9: The Architecture Frameworks Quagmire 9
Slide 10: DoD Architecture Framework, Version 1.0 Final Draft – 30 August 2003 • • http://www.eaframeworks.com/DoDAF/ Defines a common approach for DoD architecture description development, presentation, and integration for both warfighting operations and business operations and processes Three volumes: I. Definitions and Guidelines II. Product Descriptions III. Deskbook 10 •
Slide 11: Volume I – Definitions and Guidelines Introduction: Purpose, scope, architecture descriptions, definitions of views, definitions of products, integrated architectures, history of the framework Related Government Policy and Legislation Architecture Uses: Representative uses of three views, linkages among views, relationships among products, uses of integrated architectures, products according to use Techniques for Using Architecture Information: Capability-based analysis, Mission Capability Packages, key interface profiles, human factors, architecture measures, Architecture Guidelines, Description Process, and Integration Architecture Data Model, Repository, and Tools Architecture Framework Evolution Glossary, Dictionary, and References 11
Slide 12: Volume II – Product Descriptions Introduction Architecture Basics – Views, Products, and Architecture Data: Architecture Views, Products, Data Elements, Product Development, Product and Architecture Data Element Relationships, CADM Support for Architecture Products All-Views Products (AV) Operational View Products (OV) Systems View Products (SV) Technical Standards View Products (TV) Framework Architecture Data Element Relationships: Logical linkages among architecture data elements underlying the products and the views 12
Slide 13: Volume III – Deskbook Provides supplementary guidance to Framework users. Unlike the guidance provided in Volumes I and II, the techniques presented are not mandatory. Techniques for Developing Architectures Requirements-based architecture development Dept of the Navy CIO process guidance Example architecture using structured analysis and UML USSPACECOM architecture developed with OO methodology Security/Information Assurance architecture An architecture perspective on NCOW Representing the role of humans in architectures Capability Maturity profile Architecture Level of Detail Techniques for Using Architectures Air Force Capability-Based Analysis Navy’s Mission Capability Package Approach Key Interface Profiles C4I Support Plans Role of Architectures in CPIC Additional Information Architectural Concepts and CADM Architectural Modeling and Repository Tools Federal Enterprise Architecture Reference Models – Relationship to DoD Architecture Framework Universal Reference Resources e.g. UJTL, CADM, DDDS, GIG, 13 COE
Slide 14: Three Views of the Architectural Framework O p e r a tio n a l V ie w Pr L e ocess E x v e ls in g Sy cha of and s te to n g e In fo In No msA Ne R e rm a te r-N d e s ss q u i tio o d R e e d lin , A o c i re m n al q u i e s c ti a ti ent re m a n v it o n s ie s s d ent , s I d e n tifie s W a r fig h te r R e la tio n s h ip s a n d In fo r m a tio n N e e d s of e ls ev ge d L an y an xch lo g d no an in g nEs c h ty e s ess o a ti e n t T e b ili iliti oc P r fo rm ire m s ic rta a b B a ppo ap In qu Su ew C Re N S y ste m s V ie w R e la te s C a p a b ilitie s a n d C h a r a c te r istic s to O p e r a tio n a l R e q u ir e m e n ts S p e c ific C a p a b ilitie s Id e n tifie d to S a tis fy In fo rm a tio n -E x c h a n g e L e v e ls a n d O th e r O p e ra tio n a l R e q u ire m e n ts T e c h n ic a l C rite ria G o v e rn in g In te ro p e ra b le Im p le m e n ta tio n / P ro c u re m e n t o f th e S e le c te d S y s te m C a p a b ilitie s T e c h n ic a l V ie w P r e s c r ib e s S ta n d a r d s a n d C o n v e n tio n s 14
Slide 15: Architecture Description Guiding Principles • Should be built with a Purpose in Mind • Should be as Simple and Straightforward as Possible • Should Facilitate, Not Impede, Communication Among Humans • Should be Relatable and Comparable Across DoD • Should be Modular, Reusable, and Decomposable 15
Slide 16: Three Views of the Architectural Framework O p e r a tio n a l V ie w Pr L e ocess E x v e ls in g Sy cha of and s te to n g e In fo In No msA Ne R e rm a te r-N d e s ss q u i tio o d R e e d lin , A o c i re m n al q u i e s c ti a ti ent re m a n v it o n s ie s s d ent , s I d e n tifie s W a r fig h te r R e la tio n s h ip s a n d In fo r m a tio n N e e d s of e ls ev ge d L an y an xch lo g d no an in g nEs c h ty e s ess o a ti e n t T e b ili iliti oc P r fo rm ire m s ic rta a b B a ppo ap In qu Su ew C Re N S y ste m s V ie w R e la te s C a p a b ilitie s a n d C h a r a c te r istic s to O p e r a tio n a l R e q u ir e m e n ts S p e c ific C a p a b ilitie s Id e n tifie d to S a tis fy In fo rm a tio n -E x c h a n g e L e v e ls a n d O th e r O p e ra tio n a l R e q u ire m e n ts T e c h n ic a l C rite ria G o v e rn in g In te ro p e ra b le Im p le m e n ta tio n / P ro c u re m e n t o f th e S e le c te d S y s te m C a p a b ilitie s T e c h n ic a l V ie w P r e s c r ib e s S ta n d a r d s a n d C o n v e n tio n s 16
Slide 17: Operational View (OV) A description of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions (including both warfighting missions and business processes) • • Contains graphical and textual products Identifies: – operational nodes and elements – assigned tasks and activities – information flows required between nodes – – – – – – – – types of information exchanged frequency of information exchange which tasks and activities are supported by the information exchanges nature of information exchanges in detail sufficient to ascertain specific interoperability requirements Generally driven by doctrine Generally independent of organization or force structure Generally independent of technology Should clearly identify the time phase(s) covered 17 • Defines: • OV Tenets
Slide 18: Three Views of the Architectural Framework O p e r a tio n a l V ie w Pr L e ocess E x v e ls in g Sy cha of and s te to n g e In fo In No msA Ne R e rm a te r-N d e s ss q u i tio o d R e e d lin , A o c i re m n al q u i e s c ti a ti ent re m a n v it o n s ie s s d ent , s I d e n tifie s W a r fig h te r R e la tio n s h ip s a n d In fo r m a tio n N e e d s of e ls ev ge d L an y an xch lo g d no an in g nEs c h ty e s ess o a ti e n t T e b ili iliti oc P r fo rm ire m s ic rta a b B a ppo ap In qu Su ew C Re N S y ste m s V ie w R e la te s C a p a b ilitie s a n d C h a r a c te r istic s to O p e r a tio n a l R e q u ir e m e n ts S p e c ific C a p a b ilitie s Id e n tifie d to S a tis fy In fo rm a tio n -E x c h a n g e L e v e ls a n d O th e r O p e ra tio n a l R e q u ire m e n ts T e c h n ic a l C rite ria G o v e rn in g In te ro p e ra b le Im p le m e n ta tio n / P ro c u re m e n t o f th e S e le c te d S y s te m C a p a b ilitie s T e c h n ic a l V ie w P r e s c r ib e s S ta n d a r d s a n d C o n v e n tio n s 18
Slide 19: Systems View (SV) A description, including graphics, of the systems and interconnections providing for, or supporting, DoD functions • For a domain – – – – – shows how multiple systems link and interoperate may describe the internal construction and operations of particular systems within the architecture includes the physical connection, location, and identification of key hardware and software may include data stores, circuits, and networks may specify system and component performance parameters • For the individual system • The Systems View associates physical resources and their performance attributes to the operational view and its requirements per standards defined in the Technical Standards View SV Tenets – – – – – – – Primary purpose is to enable or facilitate operational tasks and activities Maps systems back to the operational architecture Identifies system interfaces and defines connectivities between systems Defines system constraints and bounds of system performance behavior Are technology-dependent, showing how multiple systems link and interoperate Can support multiple organizations and missions Are based upon and constrained by technical architectures 19 •
Slide 20: Three Views of the Architectural Framework O p e r a tio n a l V ie w Pr L e ocess E x v e ls in g Sy cha of and s te to n g e In fo In No msA Ne R e rm a te r-N d e s ss q u i tio o d R e e d lin , A o c i re m n al q u i e s c ti a ti ent re m a n v it o n s ie s s d ent , s I d e n tifie s W a r fig h te r R e la tio n s h ip s a n d In fo r m a tio n N e e d s of e ls ev ge d L an y an xch lo g d no an in g nEs c h ty e s ess o a ti e n t T e b ili iliti oc P r fo rm ire m s ic rta a b B a ppo ap In qu Su ew C Re N S y ste m s V ie w R e la te s C a p a b ilitie s a n d C h a r a c te r istic s to O p e r a tio n a l R e q u ir e m e n ts S p e c ific C a p a b ilitie s Id e n tifie d to S a tis fy In fo rm a tio n -E x c h a n g e L e v e ls a n d O th e r O p e ra tio n a l R e q u ire m e n ts T e c h n ic a l C rite ria G o v e rn in g In te ro p e ra b le Im p le m e n ta tio n / P ro c u re m e n t o f th e S e le c te d S y s te m C a p a b ilitie s T e c h n ic a l V ie w P r e s c r ib e s S ta n d a r d s a n d C o n v e n tio n s 20
Slide 21: The minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements. • Provides the technical systems-implementation guidelines upon which – – – Engineering specifications are based Common building blocks are established Product lines are developed Technical (Standards) View (TV) • Includes a collection of the – – – – Technical standards Implementation conventions Standard options Rules and criteria that govern system components and interfaces for a given architecture • TV Tenets – – – – – – Based on associations between operational requirements and their supporting systems, enabling technologies, and appropriate interoperability criteria Primary purpose is to define the set of standards and rules that govern system implementation and system operation It is constructed from an enterprise-wide set of standards and design rules It should reflect multiple information system implementation paradigms Must accommodate new technology, evolving standards, and the phasing out of old technology Should be driven by commercial standards and direction 21
Slide 22: Linkages Among the Views OPCON DRIVES Operational View DRIVES Systems View DRIVES Technical Standards View 22
Slide 23: Linkages Among the Views OPCON Operational View Provides detail regarding -Information exchanges -Interoperability levels -Performance parameters Required to support the mission or task Systems View Technical Standards View 23
Slide 24: Linkages Among the Views Defines System Attributes OPCON Operational View Provides detail regarding -Information exchanges -Interoperability levels -Performance parameters Required to support the mission or task Provides basis for comparing system performance against operational requirements Systems View Technical Standards View 24
Slide 25: Linkages Among the Views Defines System Attributes OPCON Operational View Provides detail regarding -Information exchanges -Interoperability levels -Performance parameters Required to support the mission or task Provides basis for comparing system performance against operational requirements Systems View Technical Standards View Defines the specific implementation criteria that will result in the fielding of an interoperable system 25
Slide 26: The Interrelationship Between Architecture Views O p e r a tio n a l V ie w Pr L e ocess E x v e ls in g Sy cha of and s te to n g e In fo In No msA Ne R e rm a te r-N d e s ss q u i tio o d R e e d lin , A o c i re m n al q u i e s c ti a ti ent re m a n v it o n s ie s s d ent , s I d e n tifie s W a r fig h te r R e la tio n s h ip s a n d In fo r m a tio n N e e d s of e ls ev ge d L an y an xch lo g d no an in g nEs c h ty e s ess o a ti e n t T e b ili iliti oc P r fo rm ire m s ic rta a b B a ppo ap In qu Su ew C Re N S y ste m s V ie w R e la te s C a p a b ilitie s a n d C h a r a c te r istic s to O p e r a tio n a l R e q u ir e m e n ts S p e c ific C a p a b ilitie s Id e n tifie d to S a tis fy In fo rm a tio n -E x c h a n g e L e v e ls a n d O th e r O p e ra tio n a l R e q u ire m e n ts T e c h n ic a l C rite ria G o v e rn in g In te ro p e ra b le Im p le m e n ta tio n / P ro c u re m e n t o f th e S e le c te d S y s te m C a p a b ilitie s T e c h n ic a l V ie w P r e s c r ib e s S ta n d a r d s a n d C o n v e n tio n s 26
Slide 27: Architecture Products Those graphical, textual, and tabular items that are developed in the course of building a given architecture description and that describe characteristics pertinent to the purpose of the architecture The products that should be developed for a given architecture depend on the intended use of the architecture 27
Slide 28: Architecture Products All Views Product AV-1 Product Name Overview and Summary Information Integrated Dictionary General Description Scope, purpose, intended users, environment depicted, analytical findings Data repository with definitions of all terms used in all products AV-2 28
Slide 29: All Views AV-1 Overview and Summary Information AV-2 Integrated Dictionary Textual product presenting the definitions and metadata associated with all architectural product graphical items. Each labeled graphical item (e.g. icon, box, or connecting line) in the graphical representation of a product should have a corresponding entry in the Integrated Dictionary 29
Slide 30: Architecture Products Operational Views General Description High-level graphical/textual description of operational concept Operational nodes, operational activities performed at each node, connectivity and information exchange needlines between nodes Information exchanged between nodes and the relevant attributes of the exchange Organizational, role, or other relationships among organizations Operational activities, relationships among activities, inputs and outputs. Overlays can show cost, performing nodes, or other pertinent information One of the three products used to describe operational activity sequence and timing – identifies business rules that constrain operation One of the three products used to describe operational activity sequence and timing – identifies business process responses to events One of the three products used to describe operational activity sequence and timing – traces actions in a scenario or sequence of events and specifies timing of events Documentation of the data requirements and structural business rules that constrain operation 30 Product OV-1 OV-2 OV-3 OV-4 OV-5 OV-6a OV-6b OV-6c Product Name High-Level Operational Graphic Operational Node Connectivity Description Operational Information Exchange Matrix Organizational Relationships Chart Operational Activity Model Operational Rules Model Operational State Transition Description Operational Event-Trace Description Logical Data Model OV-7
Slide 31: High-Level Operational Graphic OV-1 31
Slide 32: Operational Node Connectivity Description OV-2 Information Exchange 1 •Information Description •Name Identifier •Definition •Media •Size •Units •Information Exchange Attributes •Frequency. Timeliness, Throughput •Security •Interoperability Requirements •Information Source •Information Destination Node B Activity 1 Activity 2 Activity 1 Activity 2 Node A Node C Activity 1 32
Slide 33: Operational Information Exchange Matrix OV-3 Information Description Information Source Information Destination Information Exchange Attributes Operational Information Element Operational Description Media Size Units Element & Activity Operational Element & Activity Frequency, Timeliness, Throughput Security Interoperability Requirements Name/ Identifier Definition Digital, Voice, Text, Image, etc Range Limits Feet, Liters, Inches, etc Identifier Of Producing OE Producing Activity Identifier Of Consuming OE Consuming Activity 33
Slide 34: Command Relationship Chart OV-4 NCA CJCS (1) (1) Direction from the NCA thru the CJCS (2) USCINCTRANS manages deployment and redeployment of forces and material in compliance with the supported CINCs’ OPLANS (3) USCINCTRANS tasks the TCCs (as appropriate) for execution of airlift, sealift, land movement, and commonuser seaport operations (2) USTRANSCOM (3) MSC MTMC AMC 34
Slide 35: Operational Activity Model OV-5 35
Slide 36: Operational Rules Model OV-6a BMD Active Defense 36
Slide 37: Operational Rules Model OV-6a BMD Example Illustrating Action Assertion Rules in Structured English For each MISSILE TRACK entity Instance If MISSILE TRACK boost phase code > 0, Then MISSILE TRACK acceleration rate is non-null Else MISSILE TRACK drag effect rate is non-null And There Exists a MISSILE TRACK POINT entity instance Such That MISSILE TRACK.SOURCE TRACK identifier = MISSILE TRACK POINT.SOURCE TRACK identifier And MISSILE TRACK POINT.SOURCE identifier End If End For 37
Slide 38: Operational State Transition Description OV-6b Air Traffic Operations 38
Slide 39: Operational Event-Trace Description OV-6c Nodes Events/Times Node 1 EVENT 1 Time 1 Node 2 Node 3 (Formula relating Time 1 to Time 2) EVENT 2 Time 2 Time 3 (Formula relating Time 3 to Time 3’) EVENT 3 EVENT 4 EVENT 5 EVENT 6 EVENT 7 EVENT 8 Time 3’ Time n 39
Slide 40: Product SV-1 SV-2 SV-3 SV-4 SV-5 SV-6 SV-7 SV-8 SV-9 Product Name Architecture Products - Systems Views General Description Systems Interface Description Systems Communication Description System-Systems Matrix Systems Functionality Description Operational Activity to Systems Function Traceability Matrix Systems Data Exchange Matrix Systems Performance Parameters Matrix Systems Evolution Description Systems Technology Forecast Identification of systems and systems components and their interconnections between nodes System nodes and their related communications laydown Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g. system-type interfaces Functions performed by systems and the info flow among sys functions Mapping of systems back to operational capabilities or of system functions back to operational activities Provides details of systems data being exchanged between systems Performance characteristics of each system(s) hardware and software elements, for the appropriate timeframe(s) Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current sys to a future implementation Emerging technologies and software/hardware products that are expected to be available in a given set of timeframes, and that will affect future development of the architecture SV-10a-c a b c SV-11 Describe systems activity sequence and timing: Systems Rules Model Constraints imposed on functionality due to design or implementation Systems State Transition Description Responses of a system to events Systems Event-Trace Description Refinements of critical sequences of events and event timing Physical Schema Physical implementation of the information of the Logical Data Model 40
Slide 41: SV-1 System Interface Description 41
Slide 42: SV-1 System Interface Description, Intranodal Perspective 42
Slide 43: Systems Communications Description SV-2 43
Slide 44: System-Systems Matrix SV-3 44
Slide 45: System Functionality Description SV-4 45
Slide 46: Systems Data Exchange Matrix SV-6 46
Slide 47: System Rules Model SV-10a Action Assertion Example 47
Slide 48: Systems State Transition Description SV-10b Telephone Example 48
Slide 49: Systems Event-Trace Description SV-10c Telephone Switching Example 49
Slide 50: Architecture Products Technical Standards View (TV) Product TV-1 TV-2 Product Name Technical Standards Profile Technical Standards Forecast General Description Extraction of standards that apply to a given architecture Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes 50
Slide 51: TV-1 Technical Architecture Profile 51
Slide 52: Relationships Between Products • Individual Architecture Products are not stand-alone entities • Products represent depictions of subsets of data describing various aspects of an architecture • Relationships exist among the data that compose the various products – This creates relationships among the products 52
Slide 53: Data-Centric Build Sequence SV-9 OV-4 TV-2 TV-1 TV-2 OV-3 OV-2 AV-1 OV-1 TV-1 SV-8 SV-4 As-Is To-Be SV-1 SV-7 OV-5 OV-6a OV-6b OV-6c AV-2 OV-7 SV-5 SV-10a SV-10b SV-10c SV-6 SV-2 SV-3 SV-11 53
Slide 54: Architecture Products by Use – Guidance from DoD AF 54
Slide 55: Architectures: Data Model, Repository, and Tools • Architectures have typically been developed as sets of graphical, tabular, or textual products • Standards-Based Data-Centric Architectures – “Data-Centric”: key product information is contained in a database – Data can be stored in a repository and manipulated by automated tools – Provide efficiency and flexibility – Enable architecture integration and reconciliation of data – Facilitate data maintainability and importability from authoritative data sources • The Core Architecture Data Model (CADM): – Designed to provide a common approach for organizing and portraying the structure of architecture information – Intended to: • Facilitate the exchange, integration, and comparison of architecture information throughout the DoD • Help improve C4ISR interoperability 55
Slide 56: The Core Architecture Data Model CADM Operational Nodes Data Operational Activities Information System Functions Systems Systems Nodes Standards Technologies Performance 56
Slide 57: Core Architecture Data Model • Developed cooperatively by representatives of OSD, Combatant Commands, Military Services, and Defense Agencies • The DoD standard data model for Framework-based architecture data elements • Built using the IDEF1x methodology, notation, and forms • Evolving to support UML methodology, notation, and forms 57
Slide 58: CADM Overview • The CADM is designed to provide a common approach for organizing and portraying the structure of the architecture information • Truly intended to be a core architecture data model that focuses on a small set of common architectural data • Individual Services, Commands, and Agencies will develop extensions to the model to meet their unique requirements • The CADM will provide a point of mediation between and among products, databases, and other logical data models • CADM is a logical (conceptual) rather than a physical data model – Primary purpose is to specify single-concept data requirements, formalizing both meaning and relationships of data • CADM does not select the technology or other features of a physical implementation – Implementors are free to choose the form of the database and denormalize data structures • By designing physical databases in logical conformance to CADM, developers can improve interoperability, increase data exchange, and enhance possibility of reuse from project to project 58
Slide 59: Architecture Views and Products The 11 Oct 2002 Data Model has: 612 Entities with 3496 Attributes 7 Essential Views (2 AVs, 3 OVs, 1 SV, 1 TV) 19 Supporting Views (6 OVs, 12 SVs, 1 TV) All Views AV-1 Overview and Information Summary AV-2 Integrated Dictionary AV-3 Capability Maturity Profile Systems Views SV-1 System Interface Description SV-2 Systems Communications Description SV-3 Systems Matrix SV-4 Systems Functionality Description SV-5 Operational Activity to System Function Traceability Matrix SV-6 System Data Exchange Matrix SV-7 System Performance Parameters Matrix SV-8 System Evolution Description SV-9 System Technology Forecast SV-10a Systems Rules Model SV-10b Systems State Transition Description SV-10c Systems Event/Trace Description SV-11 Physical Data Model Technical Views TV-1 Technical Architecture Profile TV-2 Standards Technology Forecast Operational Views OV-1 High-Level Operational Concept Description OV-2 Operational Node Connectivity Description OV-3 Operational Information Exchange Matrix OV-4 Organizational Relationships Chart OV-5 Activity Model OV-6a Operational Rules Model OV-6b Operational State Transition Description OV-6c Operational Event/Trace Description OV-7 Logical Data Model Boldface – Essential Products 59
Slide 60: Key Entities and Relationships 60
Slide 61: Mapping “Node” from CADM to FDMS CADM Definition: A ZERO DIMENSIONAL TOPOLOGICAL PRIMITIVE THAT DEFINES TOPOLOGICAL RELATIONSHIPS. Note (CADM 2.0): A representation of an element of architecture that produces, consumes, or processes data. NODE Category Codes 1 = AS--Assessment Node; 2 = C2 (BM)--Battle Management Node; 3 = CL-Collection Node; 4 = CD--Combat Direction Node; 5 = CM--Communications Node; 6 = EX (Weapon)--Execution Node; 7 = PR--Processing Node; 8 = PL--Platform; 9 = PA--Process Activity; 10 = SY--System; 11 = SE--System Element; 12 = O-Organization; 13 = P--Person; 97 = N--Not applicable; 98 = Not specified; 99 = X-Not known; 14 = SI--System Instance(s); 15 = OT--Organization Type; 16 = Facility; 17 = Process Activity; 18 = Task. 61
Slide 62: Mission and Means Framework Fundamental Principles And Elements 62
Slide 63: Mission and Means Framework Goals Organize and specify operational purposes and goals Then relate, map, and allocate them to the proposed technical means for accomplishment • Warfare Representation – Specifying the military mission and quantitatively evaluating the mission utility of alternative warfighting: Doctrine, Training, Organization, Leadership, Materiel, Personnel, and Facilities • Services and Products Enable the warfighter, engineer, and comptroller to specify a common understanding of military operations, systems, and information – And provide quantitative mission assessment of alternative solutions 63
Slide 64: Mission and Means Framework Specific Objectives • Unify the warfighter, engineer, and comptoller understanding of the missions and means Account for the tangible, physical, objectively measurable factors as well as the intangible, cognitive, ultimately subjective factors that constitute mission success Be sufficiently credible, timely, and affordable to make hard decisions – and have those decisions stay made Be sufficiently consistent, concise, repeatable, and scalable to compete effectively with alternative methodologies 64 • • •
Slide 65: Mission and Means Framework Fundamental Elements Transformations (Synthesis, Mission Content Levels Employment) Stocking Assembly Missions • O1,2x • Level-7: Purpose Mission Level 1 Interaction Specifications • Level-6: Context Environment into Level 2 Component States • Level-5: Index Location/Time • O2,3x • Level-4: Tasks Operations Level 2 Component States • Level-3: Functions Capabilities into Level 3 Functional Performance • Level-2: Components Forces • O3,4x • Level-1: Interactions Effects Means Level 3 Functional Performance into Level 4 Task Effectiveness • O4,1x Level 4 Task Sequence 65 into Level 1 Interaction Conditions
Slide 66: Missions and Means Framework Mission Content Levels • Level-7: Purpose Mission • • • • • • Level-6: Context Environment “Under what circumstances” a mission is to be accomplished. Mission The “Why” and “Wherefore.” An assignment with a purpose that indicates the action to be taken. “What” the required outcomes are and “who” has been assigned them Level-5: Level-4: Index Tasks Location/Time Operations Capabilities Forces Effects “Where” (geo-spatial) and “when” with what TPFDD execution matrix Task-based, outcome-centric specification of Operations that provide the Means to accomplish the Mission. Objective: organize Task outcomes, evaluate Mission effectiveness Level-3: Functions Level-2: Components Level-1: Interactions Function-based, performance-centric “how well” specifications of Capabilities. Component-based, state-centric specifications of the Forces that provide the Means. Network of units, personnel, and equipment. Physical and logical networking. Interaction-based, phenomena-centric specification of Effects of Operations on Forces Means 66
Slide 67: Applicable Architecture View All Views (Context) All Views (Terms) Product Reference AV-1 AV-2 Architecture Product Overview and Summary Information Integrated Dictionary Essential or Supporting Essential Essential General Nature Scope, purpose, intended users, environment depicted, analytical findings, if applicable Definitions of all terms used in all products High-level graphical description of operational concept (high-level organizations, missions, geographic configuration, connectivity, etc.) Operational nodes, activities performed at each node, (4.2.1.1) (4.2.1.2) CADM Architecture Products Operational Operational Operational Operational Operational Operational Operational Operational Operational OV-1 OV-2 OV-3 OV-4 OV-5 OV-6a OV-6b OV-6c OV-7 High-level Operational Concept Graphic Operational Node Connectivity Description Operational Information Exchange Matrix Command Relationships Chart Activity Model Operational Rules Model Operational State Transition Description Operational Event/Trace Description Logical Data Model Essential Essential Essential Supporting Supporting Supporting Supporting Supporting Supporting (4.2.1.3) (4.2.1.4) (4.2.1.5) (4.2.2.1) connectivities & information flow between nodes Information exchanged between nodes and the relevant attributes of that exchange such as media, quality, quantity, and the level of interoperability required Command, control, coordination relationships among organizations Activities, relationships among activities, I/Os, constraints (e.g., policy, guidance), and mechanisms that perform those activities. In addition to showing mechanisms, overlays can show other pertinent information (4.2.2.2) One of the three products used to describe operational activity sequence and (4.2.2.3.1) timing that identifies the business rules that constrain the operation One of the three products used to describe operational activity sequence and timing that identifies responses of a business process to events (4.2.2.3.2) One of the three products used to describe operational activity sequence and timing that traces the actions in a scenario or critical sequence of events (4.2.2.3.3) Documentation of the data requirements and structural business process rules of the Operational View (4.2.2.4) Identification of systems and system components and their interfaces, within and between nodes Physical nodes and their related communications laydowns Systems Systems Systems Systems Systems Systems Systems Systems Systems Systems Systems Systems Systems Systems SV-1 SV-2 SV-3 SV-4 SV-5 SV-6 SV-7 SV-8 SV-9 SV-10a SV- 10b SV -10c SV-11 System Interface Description Systems Communications Description Systems 2 Matrix Systems Functionality Description Operational Activity to System Function Traceability Matrix System Information Exchange Matrix System Performance Parameters Matrix System Evolution Description System Technology Forecast Systems Rules Model Systems State Transition Description Systems Event/Trace Description Physical Data Model Essential Supporting Supporting Supporting Supporting Supporting Supporting Supporting Supporting Supporting Supporting Supporting Supporting (4.2.1.6) (4.2.2.5) Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. (4.2.2.6) existing interfaces, etc. Functions performed by systems and the information flow among system functions (4.2.2.7) Mapping of system functions back to operational activities (4.2.2.8) Detailing of information exchanges among system elements, applications and H/W allocated to system elements (4.2.2.9) Performance characteristics of each system(s) hardware and software elements, for the appropriate timeframe(s) (4.2.2.10) Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future (4.2.2.11) implementation Emerging technologies and software/hardware products that are expected to be available in a given set of timeframes, and that will affect future development of the architecture (4.2.2.12) One of three products used to describe systems activity sequence and timing -- Constraints that are imposed on systems functionality due to some aspect of systems design or implementation (4.2.2.13.1) One of three products used to describe systems activity sequence and timing -- Responses of a system to events (4.2.2.13.2) One of three products used to describe systems activity sequence and timing -- System-specific refinements of critical sequences of events described in the operational view (4.2.2.13.3) Physical implementation of the information of the Logical Data Model, e.g., message formats, file structures, physical schema (4.2.2.14) Technical Technical TV-1 TV-2 Technical Architecture Profile Standards Technology Forecast Essential Supporting Extraction of standards that apply to the given architecture (4.2.1.7) Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes (4.2.2.15) 67
Slide 68: Mapping MMF to DoDAF Products MMF Mission Architecture Views Operational View Level-7: Purpose Mission What is going on in the real world that is to be supported or enabled Activities performed as part of DoD missions Associated information exchanges among personnel or organizations Reveals requirements for capabilities and interoperability Systems View supports DoD needs documented in assignment with a purpose that operational view indicates the action to be taken. Existing and future systems “What” the required outcomes are Physical interconnections and “who” has been assigned Technical Standards View them Catalogs standard (COTS,GOTS) system parts or components Level-6: Environment Context and their interconnections “Under what circumstances” a mission Augments the systems view with technical detail and forecasts is to be accomplished. of standard technology evolution Level-5: Index “Where” (geo-spatial) and “when” with what TPFDD execution matrix The “Why” and “Wherefore.” An Location/Time All View – augments the other views by providing: Context, Summary Overview-Level Information – scope, purpose, environment Integrated Dictionary to define terms 68
Slide 69: Mapping MMF to DoDAF Products MMF Mission OV-1 OV-1 Architecture Views Operational View What is going on in the real world that is to be supported or enabled Activities performed as part of DoD missions Associated information exchanges among personnel or organizations Reveals requirements for capabilities and interoperability Level-7: Purpose Mission Systems View supports DoD needs documented in assignment with a purpose that operational view indicates the action to be taken. Existing and future systems “What” the required outcomes are Physical interconnections and “who” has been assigned Technical Standards View them Catalogs standard (COTS,GOTS) system parts or components Level-6: Environment Context and their interconnections “Under what circumstances” a mission Augments the systems view with technical detail and forecasts is to be accomplished. AV-1 of standard technology evolution Level-5: Index “Where” (geo-spatial) and “when” with what TPFDD execution matrix The “Why” and “Wherefore.” An AV-1 Location/Time All View – augments the other views by providing: Context, Summary Overview-Level Information – scope, purpose, environment Integrated Dictionary to define terms AV-1 69
Slide 70: Mapping MMF to DoDAF Products MMF Means Level-4: Tasks Operations Task-based, outcome-centric specification of Operations that provide the Means to accomplish the Mission. Objective: organize Task outcomes, evaluate Mission effectiveness Architecture Views Operational View What is going on in the real world that is to be supported or enabled Activities performed as part of DoD missions Associated information exchanges among personnel or organizations Reveals requirements for capabilities and interoperability Systems View supports DoD needs documented in operational view Level-3: Functions Capabilities Function-based, performance-centric “how well” specifications of Capabilities. Existing and future systems Physical interconnections Technical Standards View Catalogs standard (COTS,GOTS) system parts or components and their interconnections Augments the systems view with technical detail and forecasts of standard technology evolution Level-2: Components Forces Component-based, state-centric specifications of the Forces that provide the Means. Network of units, personnel, and equipment. Physical and logical networking. All View – augments the other views by providing: Context, Summary Overview-Level Information – scope, purpose, environment Integrated Dictionary to define terms Level-1: Interactions Effects Interaction-based, phenomena-centric specification of Effects of Operations on Forces 70
Slide 71: Mapping MMF to DoDAF Products MMF Means Level-4: Tasks OV-5 Architecture Views Operational View Operations Task-based, outcome-centric What is going on in the real world that is to be supported or enabled OV-5 specification of Operations that Activities performed as part of DoD missions provide the Means to accomplish the Associated information exchanges among personnel or organizations Mission. Objective: organize Task OV-2 OV-3 Reveals requirements for capabilities and interoperability outcomes, evaluate Mission OV-4 effectiveness Systems View supports DoD needs documented in Level-3: Functions Capabilities Function-based, performance-centric “how well” specifications of Capabilities. operational view Level-2: Components Forces Component-based, state-centric specifications of the Forces that provide the Means. Network of units, personnel, and equipment. Physical and logical networking. OV-6a OV-6b OV-6c Technical Standards View OV-7 Catalogs standard (COTS,GOTS) system parts or components Existing and future systems Physical interconnections and their interconnections Augments the systems view with technical detail and forecasts of standard technology evolution Context, Summary Overview-Level Information – scope, purpose, environment Integrated Dictionary to define terms All View – augments the other views by providing: Level-1: Interactions Effects Interaction-based, phenomena-centric specification of Effects of Operations on Forces 71
Slide 72: Mapping MMF to DoDAF Products MMF Means Level-4: Tasks Operations Task-based, outcome-centric specification of Operations that provide the Means to accomplish the Mission. Objective: organize Task outcomes, evaluate Mission effectiveness SV-1 Architecture Views SV-2 Operational View SV-5 SV-6 What is going on in the real world that is to be supported or enabled Activities performed as part of DoDSV-7 missions SV-8 personnel or organizations Associated information exchanges among SV-9 Reveals requirements for capabilities and interoperability SV-3 SV-4 Systems View supports DoD needs documented in operational view Level-3: Functions Capabilities SV-11 Existing and future systems Function-based, performance-centric Physical interconnections “how well” specifications of TV-1 Capabilities. Technical Standards View SV-10a TV-2 Catalogs standard (COTS,GOTS) system parts or components Level-2: Components Forces SV-10b SV-10c and their interconnections Component-based, state-centric Augments the systems view with technical detail and forecasts specifications of the Forces that of standard technology evolution provide the Means. Network of units, personnel, and equipment. Physical All View – augments the other views by providing: and logical networking. Level-1: Interactions Effects Interaction-based, phenomena-centric specification of Effects of Operations on Forces Context, Summary Overview-Level Information – scope, purpose, environment Integrated Dictionary to define terms 72
Slide 73: Linkages Among the Views Defines System Attributes OPCON Operational View Provides detail regarding -Information exchanges -Interoperability levels -Performance parameters Required to support the mission or task Provides basis for comparing system performance against operational requirements Systems View Technical Standards View Defines the specific implementation criteria that will result in the fielding of an interoperable system 73
Slide 74: Linkages Among the Views MMF Levels OPCON Levels 1-7 Level 2 Defines System Attributes Provides basis for comparing system performance against operational requirements Operational View Provides detail regarding -Information exchanges -Interoperability levels -Performance parameters Required to support the mission or task Systems View Technical Standards View Defines the specific implementation criteria that will result in the fielding of an interoperable system 74
Slide 75: Summary – MMF Mission Content Levels • Level-7: Purpose Mission OV-1 AV-1 The “Why” and “Wherefore.” An assignment with a purpose that indicates the action to be taken. “What” the required outcomes are and “who” has been assigned them Level-6: Environment Context AV-1 “Under what circumstances” a mission is to be accomplished. Level-5: Index Location/Time OV-1 AV-1 “Where” (geo-spatial) and “when” with what TPFDD execution matrix Level-4: Tasks Operations OV-5 Task-based, outcome-centric specification of Operations that provide the Means to accomplish the Mission. Objective: organize Task outcomes, evaluate Mission effectiveness Level-3: Functions Capabilities OV-5 SV-11 Function-based, performance-centric “how well” specifications of Capabilities. Level-2: Components Forces OV-2 OV-3 OV-4 All SV Component-based, state-centric specifications of the Forces that provide the Means. Network of units, personnel, and equipment. Physical and logical networking. Level-1: Interactions Effects OV-6a,OV-6b,OV-6c,OV-7 SV-10a,SV-10b,SV-10c Interaction-based, phenomena-centric specification of Effects of Operations on Forces 75 • • • • • •
Slide 76: MMF Transformational Operators • Level-7: Purpose Mission OV-1 AV-1 The “Why” and “Wherefore.” An assignment with a purpose that indicates the action to be taken. “What” the required outcomes are and “who” has been assigned them Level-6: Environment Context AV-1 “Under what circumstances” a mission is to be accomplished. Level-5: Index Location/Time OV-1 AV-1 “Where” (geo-spatial) and “when” with what TPFDD execution matrix Level-4: Tasks Operations OV-5 Task-based, outcome-centric specification of Operations that provide the Means to accomplish the Mission. Objective: organize Task outcomes, evaluate Mission effectiveness Level-3: Functions Capabilities OV-5 SV-11 Function-based, performance-centric “how well” specifications of Capabilities. Level-2: Components Forces OV-2 OV-3 OV-4 All SV Component-based, state-centric specifications of the Forces that provide the Means. Network of units, personnel, and equipment. Physical and logical networking. Level-1: Interactions Effects OV-6a,OV-6b,OV-6c,OV-7 SV-10a,SV-10b,SV-10c Interaction-based, phenomena-centric specification of Effects of Operations on Forces 76 • • • • • •
Slide 77: Data-Centric Build Sequence SV-9 OV-4 TV-2 TV-1 TV-2 OV-3 OV-2 AV-1 OV-1 TV-1 SV-8 SV-4 As-Is To-Be SV-1 SV-7 OV-5 OV-6a OV-6b OV-6c AV-2 OV-7 SV-5 SV-10a SV-10b SV-10c SV-6 SV-2 SV-3 SV-11 77
Slide 78: Data-Centric Build Sequence MMF Operators OV-2 TV-2 SV-9 OV-4 TV-2 TV-1 OV-3 SV-8 AV-1 OV-1 TV-1 SV-4 As-Is To-Be SV-1 SV-7 OV-5 etc. OV-6a OV-6b OV-6c OV-7 SV-5 SV-10a SV-10b SV-10c SV-6 SV-2 SV-3 AV-2 SV-11 78
Slide 79: Conclusions • The Seven Fundamental Levels of Analysis for the Mission and Means Framework can be successfully mapped to specific products of the DoD Architecture Framework The following aspects of the MMF could be logically captured in the natural construction and refinement process for each Architecture View; – Transformational Operators (O1,2S,etc) – Stocking and Assembly Perspectives – Synthesis and Employment processes • • DoD AF architecture products are particularly well-suited to explicitly specifying the military mission of the MMF The quantitative evaluation of the mission utility of alternative warfighting DTLOMPF services and products will be difficult • 79