Architecture Ignore at your own risk (DODAF 2 Architecture Ignore at your own risk (DODAF 2.0 – It’s the law for all future DOD programs) Dale Waldo Boeing Associate Technical Fellow - Systems Engineering dale.f.waldo@Boeing.com Lou Pape Boeing Associate Technical Fellow - Systems Engineering louis.e.pape@Boeing.com

Outline What is System Architecture DoDAF V2.0 6/23/2010 2

What is Systems Architecture 6/23/2010 3

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 6/23/2010 4

Table 1: Four Architecting Methodologies Systems Architecture Architecting: the art and science of designing and building systems Table 1: Four Architecting Methodologies Normative (solution-based) Examples: building codes and communications standards Rational (method based) Example: systems analysis and engineering Participative (stakeholder based) Examples: concurrent engineering and brainstorming Heuristic (lessons learned) Examples: Simplify, Simplify, Simplify… and Scope Maier & Rechtin- “The Art of Systems Architecting” 6/23/2010 5

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/23/2010 6

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 6/23/2010 7

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 6/23/2010 8

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 6/23/2010 9

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 6/23/2010 10

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 6/23/2010 11

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 6/23/2010 12

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 6/23/2010 13

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

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 6/23/2010 15

VERSION 15 3/27/2017 22:52 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 Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers I didn’t know what you meant by this one Adoption of DoDAF V2.0 benefits the decision-maker by organizing architecture information but allows the architect the freedom of presenting the data in his own format as long as it answers the questions that need to be addressed 6/23/2010 16

DoD Architecture Framework (DoDAF V2 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 6/23/2010 17

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 6/23/2010

DoDAF V2.0 DoDAF Metamodel (DM2) DoDAF V1.5 6/23/2010 Data & Information Viewpoint OV-7 Services SV-11 All “Service” Versions of SV Products Systems All “Systems” DoDAF V1.5 Capability Project Standards Operational Rest of OVs All TVs All All AVs DoDAF V2.0 New Updated Moved DoDAF Metamodel (DM2) Fit For Purpose Presentation Dashboards Graphical Depictions Reference Models Fusion Products Composite DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions. In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.). Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience. DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues. BUILD ONE: The original views (OV, SV,TV, AV) have had their content reorganized to better address their purpose The Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementations All of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views. BUILD TWO: The new Systems view better accommodates our legacy system descriptions. The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services. The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships. The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective. BUILD THREE: The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both. Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View. There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker. 6/23/2010

Perspectives: Viewpoints That Fit-the-Purpose Renamed New New New Overarching aspects of architecture context that relate to all models All Viewpoint Articulate the data relationships and alignment structures in the architecture content Data and Information Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Standards Viewpoint Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions Operational Viewpoint Articulate operational scenarios, processes, activities & requirements Capability Viewpoint Articulate the capability requirement, delivery timing, and deployed capability 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. Project Viewpoint New DoDAF organizes the DoDAF-described Models into the following viewpoints: The All Viewpoint describes the overarching aspects of architecture context that relate to all viewpoints. The Capability Viewpoint articulates the capability requirements, the delivery timing, and the deployed capability. The Data and Information Viewpoint articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services. The Operational Viewpoint includes the operational scenarios, activities, and requirements that support capabilities. The Project Viewpoint describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. An example is the Vcharts in Chapter 4 of the Defense Acquisition Guide. The Services Viewpoint is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions. The Standards Viewpoint articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services. The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions. Architecture viewpoints are composed of data that has been organized to facilitate understanding. 6/23/2010 20

DoDAF V2.0 Focus: Terms DoDAF V1.5 DoDAF V2.0 Architecture Alignment with ISO 42010 and 15407 DoDAF V1.5 DoDAF V2.0 Architecture Architectural Description Architecture data Architectural data Product Model (a template for collecting data) View (a model with data for an architecture) View Viewpoint 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’ A few words about terminology before we go very far. There is a lot of terminology in the presentation, and you will be faced with it each time you discuss an architecture. In addition, there are changes from previous versions of DoDAF that you might be familiar with, and normally use. In our part of the engineering world, everything starts will identifying a need, developing a plan for action, and collecting information about whatever it is that seems to need update or other types of change. Unfortunately, data or information is not easy to read or even pretty to look at. For that reason, people create presentations, such as this, to explain what they mean, seek further information, do analysis, and eventually gain concurrence. To do those things, we in the community look for ways to explain what we mean. Generally, for technical things, we use models—templates that look the way we usually express ourselves. When we ‘fill in’ the data, we have a view of the data. We used to call a view a ‘product’. A collection of these views is called a viewpoint, and becomes the architectural description. The difference is that you don’t have to use the examples contained in DoDAF—they are NOT required. You can create your own if you wish from the data collected. These are called User-created Views or Fit-for-Purpose Views. If you are comfortable with the older DoDAF ‘products’, then you can use the DoDAF-described Views—all of the old products are listed among the DoDAF-described products. DoDAF does describe a number of new views, as you will soon see. There is a lot of new material in DoDAF 2.0 6/23/2010

Methodology: DoDAF V2.0 Six-Step Architecture Development Process Determine the intended use of the architecture 1 Determine scope of architecture 2 Determine data required to support development 3 Collect, organize, correlate, and store architecture data 4 Conduct analyses in support of objectives 5 Document Results IAW Decision-Maker needs 6 Provide list of data needed and use cases 3.1 Model to DM2 Concept List Review list of architecture data and determine if it meets the use 3.2 DM2 Conceptual Data Model & Logical Data Model Assist with the Architect’s data collection processes 4.1 List of Potential Collection Methods Selected Verify the data collected meets the use cases 5.1 Example Uses Fit-for-Purpose Use Determine how data needs to be presented 6.1 Legacy Products User Requirements Presentations Detailed Steps for Decision- Maker It is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience. If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts. There are six steps is the DoDAF methodology: 1-Determine the intended use of the architecture 2- Determine the scope of the architecture 3- Determine data required to support architecture development 4- Collect, organize, correlate and store data 5- Conduct analysis in support of architecture objectives 6- Document results Managers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed. With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort. 6/23/2010

OV -1 is: OV -2 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 6/23/2010 23

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 6/23/2010 24

Operational Node Connectivity Description OV-2 Example 6/23/2010 25

The Development Process for Operational Views 6/23/2010 26

A (Not Exactly) Fortuitous Coming Together of UML & DoDAF… OV-1 High-Level Operational Concept Graphic HLOC High-Level Operational Concept Graphic (not really UML; more .ppt) OV-2 Operational Node Connectivity Description NCD Node Connectivity Description OV-3 Operational Information Exchange Matrix SOS System Operational Sequence OV-4 Organizational Relationships Chart NRD Node Relationship Diagram OV-5 Operational Activity Model UCD Use Case Diagram or Activity Diagram OV-6a Operational Rules Model UCS Use Case Specification (Text) OV-6b Operational State Transition Description StCD State Chart Diagram OV-6c Operational Event-Trace Description OTS Operational Trace Sequences OV-7 Logical Data Model (Related to AV-2, Dictionary) CRD, LDM Class Relationship Diagram, Logical Data Model 6/23/2010 27

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

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

System Architecture Selection Process Steps Down Select Was Based Upon Critical Measures, their Weighting, and the selected Figure of Merit (FOM) Requirements Analysis (S&C SEPM 1.2) Functional Analysis System Synthesis (S&C SEPM 1.3) Down Select Was Based Upon All Measures, their Weighting, and the selected Figure Determine Which Measures Should Be Used In the Selection Process Establish Weights For Each Measure Architecture-1 Architecture-2 Architecture-(N) Concept-1A Concept-1B Concept-1N Concept-2A Concept-2B Concept-2N Testability Risk Maintainability LCC Non- Recurring Cost Schedule Competitive Discriminators Customer Bias Producibility System A System B System (M) “Best Value” System Concept System Analysis and Control (S&C SEPM 1.4) Functional Performance Cost Estimate (DTUPC) Concept-NN Concept-NA Perform Sensitivity System Architecture Development Process Verification Loop Document the Process Risk Analysis of Final System Concept Modify concepts to combine the best features of each Legacy Components Transform Architectures (Functional to Physical) Define Alternative System Concepts Define Physical Interfaces Grade Each Concept For The Selected Critical Measures Select Preferred Product and Solutions Grade Each Candidate Concept for All Measures Concept-NB Design Loop 1. Emphasizing the process of mapping the system functional architecture into a number of physical elements that comprise the architecture candidates. 2. The insertion of legacy subsystems into the candidate physical architectures is done here. The use of legacy subsystems or elements can require a repartition of the functional architecture if the grouped functions assigned to that object cannot all be accomplished by the legacy item. 3. The architecture alternatives evaluation is accomplished by performing a trade study using an executable model of the architecture. The executable model is a integration of the static and dynamic models used to define the architecture and a computer simulation engine. 6/23/2010

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