Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Practical DoDAF Presentation to INCOSE WMA

5,506 views

Published on

Practical DoDAF Presentation to International Council on Systems Engineering Washington Metro Area by Steven H. Dam Ph.D., ESEP, founder of SPEC Innovations

Practical DoDAF Presentation to INCOSE WMA

  1. 1. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Practical DoDAF: Applying MBSE to Cost Effectively Develop Architectures October 2014 Presented by: Steven H. Dam, Ph.D. (571) 485-7805 steven.dam @specinnovations.com
  2. 2. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Presentation Overview  What Is Architecture?  What is the DoD Architecture Framework (DoDAF)?  What do we mean by MBSE?  How does MBSE produce DoDAF models and viewpoints?  How can we develop architectures more cost effectively? 2
  3. 3. © 2014 Systems and Proposal Engineering Company. All Rights Reserved “Architectures are a primary tool for enterprise-level systems integration.” DoD Architecture Framework, Version 1.0 (09 February 2004) Volume I, p. 1-5 WHAT IS ARCHITECTURE? 3
  4. 4. © 2014 Systems and Proposal Engineering Company. All Rights Reserved All Kinds of Architectures • House/Building Architecture • Information Architecture • Enterprise Architecture • Technical Architecture • Logical Architecture • Physical Architecture • … 4 Architecture is perhaps one of the most abused words in the English language today
  5. 5. © 2014 Systems and Proposal Engineering Company. All Rights Reserved DoDAF Architecture Definition • Architecture: “The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.” DoD Integrated Architecture Panel, 1995 • DoDAF 1.5 defined three views: – Operational – Systems – Technical Standards 5 “Integrated Architectures are a primary tool for enterprise-level systems integration.” DoD Architecture Framework, Version 1.0 (09 February 2004) Volume I, p. 1-5 From “Integrated DoD Architectures” brochure, available at http://www.dod.mil/c3i/org/cio/i3/AWG_Digital_Library/pdfdocs/brochure.pdf What’s Missing?
  6. 6. © 2014 Systems and Proposal Engineering Company. All Rights Reserved A Practical Definition? • Architecture: “A fundamental and unifying structure defined in terms of elements, information, interfaces, processes, constraints, and behaviors.” – This definition implies that we need many dimensions (or schema) to completely describe the architecture, including risk, decisions, data, systems, components, organizations, functions, requirements, performance. – This definition also implies that architecture forms the foundation for dynamic analysis. 6 This means that we need a way to define the dimensions and make sure they link together to capture the information needed to describe and apply an architecture.
  7. 7. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Elements of an Architecture • Operational Context in which to operate • Mission to accomplish • Requirements to decompose, maintain and evolve to accomplish Mission • Relationships among Requirements • Organizations and Roles to operate in Context and accomplish Mission • Relationships among Organizations • Behavior and Functions necessary to accomplish Mission and Tasks • Relationships among Functions • Data and Information from Analyses • Constraints on Design and Execution • The highest level of Design • Decisions 7
  8. 8. © 2014 Systems and Proposal Engineering Company. All Rights Reserved WHAT IS THE DOD ARCHITECTURE FRAMEWORK? 8
  9. 9. © 2014 Systems and Proposal Engineering Company. All Rights Reserved What is the DoD Architecture Framework? • The DoDAF provides a means to compare architectures. • It enables this comparison by defining a set of views of an architecture (a.k.a. products). • In Version 1.5 and previously, these products were grouped into 4 views: – Operational View – Technical Standards View – Systems and Services View – All-View • In Version 2.0 they added the – Capability View – Data and Information View – Program View – Services View (separate from Systems) 9
  10. 10. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Perspectives: Viewpoints That Fit-the-Purpose 10 Architectural viewpoints are composed of data that has been organized to facilitate understanding DoDAF V 2.0 PDF p 106
  11. 11. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Models, Views and Viewpoints 11 Model X View X + Data Model Y View Y + Data Model Z View Z + Data Viewpoint N View N View Z View Y View X • All Viewpoint • Capability Viewpoint • Data and Information Viewpoint • Operational Viewpoint • Project Viewpoint • Services Viewpoint • Standards Viewpoint Derived from text on DoDAF 2.02 PDF page 3 • Systems Viewpoint http://cio-nii.defense.gov/sites/dodaf20/background.html “Products”
  12. 12. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Building the Architecture from “Viewpoints” Viewpoint A View N View Z View Y Architectural Description View X Viewpoint N Viewpoint C Viewpoint B Viewpoint A Derived from text on DoDAF 2.02 PDF page 3 http://cio-nii.defense.gov/sites/dodaf20/background.html Viewpoint N View N View Z View Y View X Viewpoint B View N View Z View Y View X 12
  13. 13. © 2014 Systems and Proposal Engineering Company. All Rights Reserved DoDAF 2.0 Models Model Name General Description All VP AV-1 Overview and Summary Information Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects AV-2 Integrated Dictionary Architecture data repository with definitions of all terms used throughout the architecture data and presentations Capability Viewpoint CV-1 Vision Overall vision for transformational endeavors, provides a strategic context for the capabilities described, and provides a high-level scope CV-2 Capability Taxonomy A hierarchy of capabilities specifies all the capabilities that are referenced throughout one or more architectures CV-3 Capability Phasing Planned achievement of capability at different points in time or during specific periods of time CV-4 Capability Dependences Dependencies between planned capabilities and defines logical groupings of capabilities CV-5 Capability to Organizational Development Mapping The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular Capability Phase CV-6 Capability to Operational Activities Mapping Mapping between the capabilities required and the operational activities that those capabilities support CV-7 Capability to Services Mapping Mapping between capabilities and the services that these capabilities enable Data and Info VP DIV-1 Conceptual Data Model Required High level data concepts and their relationships DIV-2 Logical Data Model Documentation of the data requirements and structural business process rules (In DoDAF V1.5, this was the OV-7) DIV-3 Physical Data Model Physical implementation of the Logical Data Model entities, e.g., message formats, file structures, physical schema (In DoDAF V1.5, this was the SV- 11)
  14. 14. © 2014 Systems and Proposal Engineering Company. All Rights Reserved DoDAF 2.0 Models Model Name General Description Operational Viewpoint OV-1 High-Level Operational Concept Graphic High-level graphical/textual description of operational concept OV-2 Operational Resource Flow Description Operational resource flow needlines OV-3 Operational Resource Flow Matrix Resource exchanged and the relevant attributes of that exchange OV-4 Organizational Relationships Chart Organizational, role, or other relationships among Organizations OV-5a & b Operational Activity Decomposition Tree & Model Capabilities, activities (operational activities), relationships among activities, inputs, and outputs; overlays can show cost, performers or other pertinent information OV-6a Operational Rules Model One of three models used to describe activity (operational activity) -identifies business rules that constrain operations OV-6b State Transition Description One of three models used to describe activity (operational activity) -identifies business process responses to events OV-6c Event-Trace Description One of three models used to describe activity (operational activity) -traces actions in a scenario or sequence of events Project Viewpoint PV-1 Project Portfolio Relationships Organizational structures needed to manage a portfolio of projects and shows dependency relationships between the organizations and projects PV-2 Project Timelines A timeline perspective on programs or projects, with the key milestones and interdependencies PV-3 Project to Capability Mapping Mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability
  15. 15. © 2014 Systems and Proposal Engineering Company. All Rights Reserved DoDAF 2.0 Model Model Name General Description Services Viewpoint SvcV-1 Services Interface Description Identification of services and service items and their interconnections SvcV-2 Services Resource Flow Description Services and service items and their related resource flows SvcV-3a Systems-Services Matrix Relationships among between systems and services in a given architecture SvcV-3b Services-Services Matrix Relationships among services in a given architecture; can be designed to show relationships of interest, e.g., service-type interfaces, planned vs. existing interfaces, etc. SvcV-4 Services Functionality Description Functions performed by services and the service data flows among service functions (activities) SvcV-5 Operational Activity to Services Traceability Matrix Mapping of services (activities) back to operational activities (activities) SvcV-6 Services Resource Flow Matrix Provides details of service resource flow elements being exchanged between services and the attributes of that exchange SvcV-7 Services Measures Matrix Measures (metrics) of Services View elements for the appropriate time frame(s) SvcV-8 Services Evolution Description Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving current services to a future implementation SvcV-9 Services Technology Forecast Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture SvcV-10a Services Rules Model One of three models used to describe service functionality- - identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation SvcV-10b Services State Transition Description One of three models used to describe service functionality- - identifies responses of a services to events SvcV-10c Services Event-Trace Description One of three models used to describe service functionality- - identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint
  16. 16. © 2014 Systems and Proposal Engineering Company. All Rights Reserved DoDAF 2.0 Models 16 Model Name General Description Systems Viewpoint SV-1 Systems Interface Description Identification of systems and system items and their interconnections SV-2 Systems Resource Flow Description Systems and system items and their related resource flows SV-3 Systems-Systems Matrix Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing interfaces, etc. SV-4 Systems Functionality Description Functions (activities) performed by systems and the system data flows among system functions (activities) SV-5a Operational Activity to Systems Function Traceability Matrix Mapping of system functions (activities) back to operational activities (activities) SV-5b Operational Activity to Systems Traceability Matrix Mapping of systems back to capabilities or operational activities (activities) SV-6 Systems Resource Flow Exchange Matrix Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange SV-7 Systems Measures Matrix Measures (metrics) of Systems View elements for the appropriate time frame(s) SV-8 Systems Evolution Description Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation SV-9 Systems Technology Forecast Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture SV-10a Systems Rules Model One of three models used to describe system functionality— identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation SV-10b Systems State Transition Description One of three models used to describe system functionality— identifies responses of a system to events SV-10c Systems Event-Trace Description One of three models used to describe system functionality— identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint Standards Viewpoint StdV-1 Standards Profile Listing of standards that apply to solution elements in a given architecture StdV-2 Standards Forecast Description of emerging standards and potential impact on current solution elements, within a set of time frames
  17. 17. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Framework “Products” • Specific information content for products in each view • They are expressed in graphical, textual, and tabular form • The specific products developed depend on the intended use of the architecture • Additional products are allowed if they improve communication of the architecture Presented by Mr. Truman Parmele at the DoD Architectures Conference February 24, 2004 17 “The Framework does not advocate the use of any one methodology (e.g., structured analysis vs. object orientation), or one notation over another (IDEF1X or ER notation) to complete this step, but products should contain the required information and relationships.” DoD Architecture Framework, Version 1.5 (23 April 2007) Vol. II, p. 2-6
  18. 18. © 2014 Systems and Proposal Engineering Company. All Rights Reserved What does an architecture look like? • To some, it’s a collection of diagrams and documents: 18 cc#2 3 times cc#1 1 Serial Function AND 2 Function in Concurrency 3 Multi-exit Function IT 4 Function in Iterate IT OR OR 5 Function in Select Construct 6 Function 2 in Select Construct OR AND 7 Output Function External Data 1 Input Data 5 Data 2 Data 3 Data 4 External Output 0 Constructs Function 1 Serial Function Function 2 Function in Concurrency Function 3 Multi-exit Function Function 4 Function in Iterate Function 5 Function in Select Constr... Function 6 Function 2 in Select Constr... Function 7 Output Function Function
  19. 19. © 2014 Systems and Proposal Engineering Company. All Rights Reserved What does an architecture look like? 19 • To others it’s a decision database: Architecture Repository
  20. 20. © 2014 Systems and Proposal Engineering Company. All Rights Reserved WHAT DO WE MEAN BY MBSE? 20
  21. 21. © 2014 Systems and Proposal Engineering Company. All Rights Reserved INCOSE’s MBSE Definition “Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” From INCOSE Model Based Systems Engineering (MBSE) • Some have equated MBSE to a specific technique (e.g., SysML) • But MBSE has been around for a long, long time • Recently (IW 2014) I saw a viewgraph that said: MBSE = SE 21 Initiative presentation at INCOSE IS 2007
  22. 22. © 2014 Systems and Proposal Engineering Company. All Rights Reserved What Techniques Are Used? • Viewgraph engineering • Model-Based Systems Engineering (MBSE) – Structured Analysis with and without real-time extensions – Integration DEFinition (IDEF) – Unified/Systems Modeling Language (UML/SysML) – Business Process Model and Notation (BPMN) – Lifecycle Modeling Language (LML) 22 Make sure the technique you choose will provide a broad, complete foundation for analysis and specification
  23. 23. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Characteristics of a “Good” MBSE Technique • Interactive models, not just drawings with a database (e.g., Visio) • Simulation (discrete event and Monte Carlo) to verify the models • Ontology + Visualization • Various visualizations from database • Report creation from database 23
  24. 24. © 2014 Systems and Proposal Engineering Company. All Rights Reserved HOW DOES MBSE PRODUCE DODAF MODELS AND VIEWPOINTS? 24
  25. 25. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Tools That Support DoDAF • A number of tool have support for DoDAF today • Some support a specific technique, others claim to be “technique or methodology” independent • Select a technique, tool and process that make it easy for you to apply “good” MBSE characteristics 25
  26. 26. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Have Easy Access to DoDAF Products • e.g., a dedicated DoDAF Dashboard provides access to all DoDAF products • DM2 Statistics • PES export 26 DM2 = DoDAF MetaModel 2.0
  27. 27. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Build One Diagram and Get Many DoDAF Products Action Diagram = combined OV-5b/OV6c, SvcV-4/SvcV-10c, SV-4/SV-10c) • Highly expressive and model-based functional modeling (sequencing and data flow, with allocation and resource modeling explicit) • Drag/drop capable • Executable in both Discrete Event and Monte Carlo simulators 27
  28. 28. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Or Use a Sequence Diagram for the OV-6c/ SvcV-10c/SV-10c • Functional sequencing only • Another view from the database, not a separate “drawing” • Can generate from Action Diagram or be used to generate an Action Diagram • Also, drag and drop capable, with sidebar for information on entities 28
  29. 29. © 2014 Systems and Proposal Engineering Company. All Rights Reserved And an IDEF0 Diagram for the OV-5b/ SvcV-4/SV-4 • Classic data flow modeling • Drag and drop • Sidebar enabled • ICOM view also available 29
  30. 30. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Use Simulations for Analysis and Verification 30 Monte Carlo result Discrete Event result Note the simulator is compatible with the Action and Sequence Diagrams. Do not try to simulate IDEF0s – they are non-executable diagrams.
  31. 31. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Then Build the Physical Model for the OV-1, SvcV-1 & 2, and SV-1 & 2 Create a classic block diagram for SvcV-1/2 and SV-1/2… • Highly expressive and model-based physical modeling • Drag/drop capable • Add picture, special lines and backgrounds 31 … or add pictures and special lines for concept diagram (OV-1)
  32. 32. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Use Traceability Diagrams to See Link between Entities • Shows how a single entity (database object) is related to the rest of the system • Drag and drop new entities and create relationships right from the diagram • Sidebar enabled 32
  33. 33. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Include Development of AV-1 • Enables complete architecture study management • Uses new Document View • Trace findings to other aspects of the database • Can provide requirements for tracing to other entities • Link to Risk and Decision entities 33
  34. 34. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Interactive DoDAF matrices • Easy to use matrices for: – CV-4, CV-5, CV-6, CV-7 – PV-1, PV-3 – SvcV-3a, SvcV-3b, SvcV-5, SvcV- 7 – SV-3, SV-5a, SV-5b, SV-7 34
  35. 35. © 2014 Systems and Proposal Engineering Company. All Rights Reserved HOW CAN WE DEVELOP ARCHITECTURES MORE COST EFFECTIVELY? 35
  36. 36. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Why Do a Lot of Our Architectures Become “Shelfware?” • No clear relationship to mission or design • Done in the abstract … users not involved • Focus on “To-Be” without understanding the “As-Is” • No way to develop a real transition plan • No internal governance process • “Paper” architectures, not living models • Lack of complete traceability … all elements, not just requirements 36
  37. 37. © 2014 Systems and Proposal Engineering Company. All Rights Reserved How Can We Avoid Learning the “Lessons Learned” Again? • Developing and using a clear, simple methodology 37 – Techniques (the theory) – Process (the application) – Tools (the hammer) • Planning and replanning • Training – Train complete team – Provide refresher training as needed
  38. 38. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Techniques • Provide the theoretical 38 underpinnings for the architecture development or system design • Provides a set of “bins” to capture information • Provides standards for communicating the information, usually in graphical form
  39. 39. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Requirements Analysis Functional Analysis Synthesis System Analysis and Control SV-8 SV-9 14. Provide Options Processes 39 1. Capture and Analyze Related Artifacts 2. Identify Assumptions AV-1 Draft 5. Develop the Operational Context Diagram DIV-2 6. Develop Operational Scenarios 7. Derive Functional Behavior 8. Derive Assets 9. Allocate Actions to Assets 4. Capture Constraints 3. Identify Existing/Planned Systems 15. Conduct Trade-off Analyses 10. Prepare Interface Diagrams SV-10 12. Perform Dynamic Analysis 11. Define Resources, Error Detection & Recovery 13. Develop Operational Demonstration Master Plan 16. Generate Operational and System Architecture Graphics, Briefings and Reports AV-1 AV-2 OV-1 OV-2 OV-3 OV-4 OV-5 OV-6 SV-1 SV-2 SV-3 SV-4 SV-6 SV-5 SV-7 StdV-1 StdV-2 DIV-3 DIV-1 CV-1 CV-2 CV-3 CV-4 CV-5 CV-6 CV-7 PV-2 PV-3 PV-1 CONOPS Time
  40. 40. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Tools • Enhance efficiency of the architect/system engineer • Capture the information required by standards • Enforce consistency by applying standards • Make generation of products and reports much easier 40 Database Requirements Analysis Automatically Generated Diagrams Simulation
  41. 41. © 2014 Systems and Proposal Engineering Company. All Rights Reserved How Do We Determine the Appropriate Mix of Technique, Process, and Tool(s)? • Choose the technique(s) you want to use first (get the theory right) • Identify tools that support the technique • Obtain/develop your process • Optimize all three … don’t be afraid to use a different technique, tool or process if one doesn’t work • Work with your customer to make sure that whatever you produce is what they want 41
  42. 42. © 2014 Systems and Proposal Engineering Company. All Rights Reserved Summary • Practical DoDAF means using MBSE techniques, processes and tools to develop the DoDAF models – Use common language (technique & DoDAF terms) – Apply a process that works for your situation (architecture usually needs middle-out) – Use comprehensive tools to capture the information and produce DoDAF products 42

×