Unlocking DoDAF 2.0: Systems Architecture Essentials

1. Architecture Ignore at your own risk(DODAF 2.0 – It’s the law for all future DOD programs) Lou PapeBoeing Associate Technical Fellow - Systems Engineeringlouis.e.pape@Boeing.com Dale WaldoBoeing Associate Technical Fellow - Systems Engineeringdale.f.waldo@Boeing.com

2. Outline • What is System Architecture • DoDAF V2.0 2

3. What is Systems Architecture 3

4. Systems Architecture Wikipedia • A system architecture or systems architecture is the conceptual design that defines the structure and/or behavior of a system. • An architecture description is a formal description of a system, organized in a way that supports reasoning about the structural properties of the system. It defines the system components or building blocks...and provides a plan from which component products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage...investment in a way that meets business needs 4

5. Systems Architecture Architecting: the art and science of designing and building systems Maier & Rechtin- “The Art of Systems Architecting” 5

6. Systems Architecture • A system is a collection of different things that together produce results unachievable by themselves alone. The value added by systems is in the interrelationships of their elements • Architecting is creating and building structures, i.e., “structuring.” Systems architecting is creating and building systems. It strives for fit, balance, and compromise among the tensions of client needs and resources, technology, and multiple stakeholder interests • Architecting is both an art and a science -- synthesis and analysis, induction and deduction, and conceptualization and certification - using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the customer, and particular concern with certification standards and readiness for use Maier & Rechtin- “The Art of Systems Architecting” 6

7. DoDAF Definition DoDAF V2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries It doesn’t tell you how to architect, it tells you how to title and organize your system’s descriptive artifacts 7

8. What is Good Architecture • A good architecture meets the needs of the stakeholders (especially the users) to their satisfaction, does not violate principles of system architecture, and takes into account the relevant -ilities by allowing for maintenance, evolution, further development, embedding, etc. as the customer requires • Really good architectures are also elegant (intellectually clean of unnecessary complexities or 'exceptions'), can direct a builder to cost-effective structures that can be completed within a reasonable time frame, conceptually pleasing to all stakeholders (especially the user), and provide some special advantage (such as a competitive advantage) or utility to the customer 8

9. Some Powerful Systems Engineering Heuristics • All designs are valid if they deliver the performance within the constraints • System Level Architecture optimizes the specialist disciplines, and constrains them • Systems need to be built to tolerate change and expansion beyond current stakeholder needs • System Stakeholders are one more than you know about; and known stakeholders have at least one more need than you know about now • You cannot economically satisfy all critical stakeholder needs, so the job is to increase value-to-cost ratios in the long term, over current systems • Don’t ever try to build it all at once – evolve the system based on highest value early, and rapid learning about realities • Manage the details through focus on high-level measurable objectives, not through bureaucracy 9

10. All Design Processes Should Involve Iteration • All design processes can and should involve iteration • Many systems are too complex, and many architects are not competent enough, to do a perfect job on the first pass • Many data points only become available later in the architecture or design process • Therefore, every architecture design process should involve iteration; the process should be designed to be conducted over and over again until a satisfactory solution is reached 10

11. The Customer is the Judge of Quality • An architecture that satisfies the architect but not the customer is useless • The customer should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture • While the architect may attempt to educate the customer to their mutual benefit, in cases of difference of opinion it is the customer's opinion that matters 11

12. KISS (Keep It Simple,Stupid) • The architect should strive to adhere to the KISS principle, "keep it simple, stupid." • The system architecture should be as simple as possible without conflicting with other design principles • Architectures that are more complex than necessary will result in sub-optimal systems • This principle is also known as Occam's Razor 12

13. Modeling as a Architectural Tool • The “systems” we deal with are increasingly complex, as is the environment they operate in • Difficult to comprehend, understand, predict, control, interface with, explain, etc. • Larger, more complex tasks • Increasingly “Systems of Systems” • Modeling allows fuller, cheaper exploration of the design space (within limitations) • Object Mgmt Group (OMG) and INCOSE are Driving Toward Model Driven Development (MDD)/Model Driven Architecture (MDA) • UML 2.0, SysML 13

14. Intro to DoDAF V2.0Overview:http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_web.pdfSlides:http://www.updm.com/document/OSD,%20EA&S,%20Brief%20to%20OMG,%20DoDAF%20V2,%2020090916.ppt 14

15. DOD Acquisition Landscape has Changed • The DOD is: • No longer telling the contractor the solution they have chosen • Now seeking to leverage the expertise of the contractor • Seeking to have a choice of the best options available against which they will write the Systems Requirements Document (SRD) • Stating their goals for the product in a Statement of Objectives (SOO) • Asking the contractor to tell them what it really takes to achieve that SOO 15

16. Value of DoDAF V2.0 • DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development in a way that will aid DoD managers • Fit-for-Purpose describes an architecture that is appropriately focused and directly supports customer needs or improves the overall process undergoing change. The models provide choices, based upon the decision-maker needs • Facilitates development of architectural descriptions under Service-Oriented Architecture (SOA) - related techniques and tools • Adheres to the DoD Acquisition Life Cycle methodologies contained in the DoD Acquisition Guide • Can be used in conjunction with Lean, Six Sigma and other Process Improvement methods

17. DoD Architecture Framework (DoDAF V2.0)Original DoDAF Views have been expanded to better organize information and reflect data that practitioners actually use Modified Viewpoints • The original DoDAF Systems View has been separated into a Systems Viewpoint (SV) and a Service Viewpoint (SvcV) to accommodate extension to both systems and software/services engineering practice • All the models of data (Conceptual, Logical, and Physical) have been moved into the Data & Information Viewpoint (DIV) • The Operational Viewpoint (OV) now describes rules and constraints for any function (business, intelligence, warfighting, etc) • Technical View (TV) has been updated to the Standards Viewpoint (StdV) to describe business, commercial, and doctrinal standards in addition to technical standards • The All Viewpoint (AV) is essentially the same 17

18. DoD Architecture Framework(DoDAF V2.0) New Viewpoints • Capability Viewpoint (CV) focuses on Capability data in support of Capability development and to standardize the capture of capability data • Project Viewpoint (PV) focuses on the Portfolio Management/Cost Performance information to explicitly tie architecture data to project efforts (what used to be called status charts) A major new thrust of V2.0 is the term “fit for purpose” • The individual artifacts are intended to be “fit for their purpose” of documenting, managing, and guiding the system development – not generated specially and uniquely for a high level review

19. Fit For Purpose Presentation Dashboards Fusion Products Reference Models Composite Products Graphical Depictions All Viewpoint All AVs All “Systems” Versions of SV Products Systems Viewpoint All TVs Standards Viewpoint All “Service” Versions of SV Products Services Viewpoint SV-11 OV-7 Rest of OVs Data & Information Viewpoint Operational Viewpoint Capability Viewpoint Project Viewpoint DoDAF Metamodel (DM2) Updated Moved New DoDAF V2.0 DoDAF V1.5

20. Perspectives: Viewpoints That Fit-the-Purpose Capability Viewpoint Articulate the capability requirement, delivery timing, and deployed capability Operational Viewpoint Articulate operational scenarios, processes, activities & requirements Project Viewpoint Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process. Standards Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Data and Information Viewpoint Articulate the data relationships and alignment structures in the architecture content All Viewpoint Overarching aspects of architecture context that relate to all models Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions Renamed New New New New Architecture viewpoints are composed of data that has been organized to facilitate understanding.

21. DoDAF V2.0 Focus: Terms Models are templates for organizing and displaying data in DoDAF 2.0 Previous versions of DoDAF referred to these as ‘Products’ An example of a Model is an OV-2, OV-5, SV-1, CV-5 Views are the result of collecting and populating Models with data and then presenting it Views are a Model populated with specific data Viewpoints are a collection of models/views Previous versions of DoDAF just referred to these as ‘Views’ Examples include: All Viewpoint (AV), Operational Viewpoints (OV), Capability Viewpoint (CV) The collection of information, specifically Views and/or Viewpoints, used to document the architecture is referred to as an Architectural Description Previous versions of DoDAF referred to these as just an ‘Architecture’ Alignment with ISO 42010 and 15407

22. 1 Determine the intended use of the architecture 5 2 3 4 6 Conduct analyses in support of architecture objectives Collect, organize, correlate, and store architecture data Determine scope of architecture Determine data required to support architecture development Document Results IAW Decision-Maker needs List of architecture data Fit-for-Purpose Presentations Fit-for-Purpose Use Selected Collection Methods 3.2 5.1 6.1 4.1 3.1 Review list of architecture data and determine if it meets the use cases Assist with the Architect’s data collection processes Verify the data collected meets the use cases Determine how data needs to be presented Provide list of data needed and use cases DM2 Conceptual Data Model & Logical Data Model Model to DM2 Concept List Potential Collection Methods Example Uses Legacy Products User Requirements Example Presentations Methodology: DoDAF V2.0 Six-Step Architecture Development Process Detailed Steps for Decision- Maker With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort.

23. OV -1 is: • Graphical in nature • An easy way to understand what is trying to be explained by the architecture as a whole • Provides an excellent summary of the architecture when combined with AV-1 • A mission and highlighted primary operational nodes OV -2 is: • Graphical in nature • One of the work products required for an integrated architecture • A way to track the need to exchange information from specific Operational Nodes (that play a key role in the architecture) to other Nodes 23

24. GIG Tactical Theater Communications Infrastructure (OV-1 Example) Wideband Networking Waveform Capability Central to Tactical GIG Broadband LOS Radio Access Point Broadband LOS Radio Access Point 24

25. Operational Node Connectivity Description OV-2 Example 25

26. The Development Process for Operational Views 26

27. A (Not Exactly) Fortuitous Coming Together of UML & DoDAF… DoDAF UML 27

28. Customer Requirements System Definition • Requirements Analysis • Mission Requirements • Requirements Trades • TPMs • Requirements Capture • Functional Analysis/ Allocation • Functional Analysis • Functional Trade Studies • Requirements Flowdown • System Synthesis • Design Trade Studies • Specialty Engineering Integration • CAIV • Subsystem Requirements Flowdown SDR Optimized System Design SRR Legacy Program Information • Systems Engineering Management and Analysis • Plans/Schedules • Requirements Management • Risk Management • SEIT Coordination • Subcontractor Management • Closed Loop Corrective Action • TPMs Validated System Design Reviews Prototype I&T Detailed Design System Integration System Test System Verification & Evaluation Systems Engineering Process 28

29. Customer Requirements System Definition • Requirements Analysis • Mission Requirements • Requirements Trades • TPMs • Requirements Capture • Functional Analysis/ Allocation • Functional Analysis • Functional Trade Studies • Requirements Flowdown • System Synthesis • Design Trade Studies • Specialty Engineering Integration • CAIV • Subsystem Requirements Flowdown SDR Optimized System Design SRR Legacy Program Information • Systems Engineering Management and Analysis • Plans/Schedules • Requirements Management • Risk Management • SEIT Coordination • Subcontractor Management • Closed Loop Corrective Action • TPMs Validated System Design Reviews Prototype I&T Detailed Design System Integration System Test Architecture holds it all together System Verification & Evaluation Systems Engineering Process 29

30. System Architecture Development Process Grade Each Concept For The Selected Critical Measures Select Preferred Product and Process Solutions Grade EachCandidate Concept for All Measures • Define Alternative • System Concepts • Define Physical • Interfaces Transform Architectures (Functional to Physical) Verification Loop Cost Estimate (DTUPC) Concept-1A Cost Estimate (DTUPC) Testability Modify concepts to combine the best features of each Testability Architecture-1 Concept-1B Requirements Analysis (S&C SEPM 1.2) Producibility Producibility Document the Process Concept-1N Risk Risk System A Risk Analysis of Final System Concept Design Loop Functional Performance Functional Performance Concept-2A Functional Analysis (S&C SEPM 1.2) System B Maintainability Maintainability “Best Value” System Concept Concept-2B Architecture-2 LCC LCC System (M) Concept-2N Non- Recurring Cost Non- Recurring Cost Down Select Was Based Upon All Measures, their Weighting, and the selected Figure of Merit (FOM) System Analysis and Control (S&C SEPM 1.4) Down Select Was Based Upon Critical Measures, their Weighting, and the selected Figure of Merit (FOM) Schedule Schedule Concept-NA Competitive Discriminators Competitive Discriminators Architecture-(N) Concept-NB Customer Bias Customer Bias • Determine Which • Measures Should Be • Used In the Selection Process • Establish Weights For • Each Measure Concept-NN Perform Sensitivity Analysis Legacy Components Legacy Components Perform Sensitivity Analysis System Synthesis (S&C SEPM 1.3) System Architecture Selection Process Steps

31. "YOU ARE THE STEWARD OF THE WHOLE,NOT THE OWNER OF THE PART.” Dr. John Pickering 31