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 • Do. DAF V 2. 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

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… 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

Do. DAF Definition Do. DAF V 2. 0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate Do. D 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, Sys. ML 6/23/2010 13

Intro to Do. DAF V 2. 0 Overview: http: //cio-nii. defense. gov/sites/dodaf 20/products/Do. DAF_2 -0_web. pdf Slides: http: //www. updm. com/document/OSD, %20 EA&S, %20 Brief%20 to%20 OMG, %20 Do. DAF%20 V 2, %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

Value of Do. DAF V 2. 0 § Do. DAF V 2. 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 Do. D 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 Do. D Acquisition Life Cycle methodologies contained in the Do. D Acquisition Guide § Can be used in conjunction with Lean, Six Sigma and other Process Improvement methods 6/23/2010

Do. D Architecture Framework (Do. DAF V 2. 0) Original Do. DAF Views have been expanded to better organize information and reflect data that practitioners actually use Modified Viewpoints • The original Do. DAF Systems View has been separated into a Systems Viewpoint (SV) and a Service Viewpoint (Svc. V) 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 (Std. V) to describe business, commercial, and doctrinal standards in addition to technical standards • The All Viewpoint (AV) is essentially the same 6/23/2010 17

Do. D Architecture Framework (Do. DAF V 2. 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 V 2. 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 18

Dashboards Graphical Depictions Do. DAF V 2. 0 Composite Products Do. DAF V 1. 5 All AVs All “Systems” Versions of SV Products Systems Viewpoint Services Fusion Products Reference Models Fit For Purpose Presentation All “Service” Versions of SV Products All Viewpoint All TVs Standards Viewpoint SV-11 OV-7 Data & Rest of OVs Information Operational Viewpoint Updated Viewpoint Moved 6/23/2010 New Capability Project Viewpoint Do. DAF Metamodel (DM 2) 19

Perspectives: Viewpoints That Fit-the. Purpose Articulate the capability requirement, delivery timing, and deployed capability Articulate operational scenarios, processes, activities & requirements Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, Do. D functions Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, Do. D functions Project Viewpoint Operational 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 Capability Viewpoint 6/23/2010 Architecture viewpoints are composed of data that has been organized to facilitate understanding.

Do. DAF V 2. 0 Focus: Terms • • Alignment with ISO 42010 and 15407 Do. DAF V 1. 5 Do. DAF V 2. 0 Architecture Architectural Description Architecture data Architectural data Product Model (a template for collecting data) Product View (a model with data for an architecture) Viewpoint Models are templates for organizing and displaying data in Do. DAF 2. 0 – Previous versions of Do. DAF 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 Do. DAF 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 Do. DAF referred to these as just an ‘Architecture’ 6/23/2010 21

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

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

GIG Tactical Theater Communications Infrastructure (OV-1 Example) Broadband LOS Radio Access Point 6/23/2010 Wideband Networking Waveform Capability Broadband LOS Central to Tactical GIG Radio Access Point 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 & Do. DAF… Do. DAF UML 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-6 a Operational Rules Model UCS Use Case Specification (Text) OV-6 b Operational State Transition Description St. CD State Chart Diagram OV-6 c 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 Customer Requirements System Definition Requirements Analysis • • Functional Analysis/ Allocation Mission Requirements • Functional Analysis • Functional Trade Studies • Requirements Flowdown Requirements Trades TPMs Requirements Capture Legacy Program Information System Synthesis SRR • • Design Trade Studies Specialty Engineering Integration CAIV Subsystem Requirements Flowdown SDR Optimized System Design Systems Engineering Management and Analysis • • Detailed Design Plans/Schedules Requirements Management Risk Management SEIT Coordination Prototype I&T Design Reviews • Subcontractor Management • Closed Loop Corrective Action • TPMs System Integratio n System Test Validated System Verification & Evaluation 6/23/2010 28

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

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

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