Presentation is loading. Please wait.

Presentation is loading. Please wait.

Architecture Ignore at your own risk (DODAF 2.0 – Its the law for all future DOD programs) Dale Waldo Boeing Associate Technical Fellow - Systems Engineering.

Similar presentations


Presentation on theme: "Architecture Ignore at your own risk (DODAF 2.0 – Its the law for all future DOD programs) Dale Waldo Boeing Associate Technical Fellow - Systems Engineering."— Presentation transcript:

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

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

3 6/23/201033 What is Systems Architecture

4 6/23/201044 Systems Architecture Wikipedia A system architecture or systems architecture is the conceptual design that defines the structure and/or behavior of a system.structure behaviorsystem 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 systembusiness

5 6/23/201055 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 6/23/201066 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

7 6/23/20107 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 doesnt tell you how to architect, it tells you how to title and organize your systems descriptive artifacts 7

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

9 6/23/20109 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 Dont 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 6/23/201010 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

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

12 6/23/201012 KISS (Keep It Simple,Stupid) The architect should strive to adhere to the KISS principle, "keep it simple, stupid." KISS principle 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 RazorOccam's Razor

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

14 6/23/201014 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,%20 DoDAF%20V2,%2020090916.ppt http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_web.pdf http://www.updm.com/document/OSD,%20EA&S,%20Brief%20to%20OMG,%20 DoDAF%20V2,%2020090916.ppt

15 6/23/201015 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 DOD Acquisition Landscape has Changed

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

18 6/23/201018 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 6/23/201019 Data & Information Viewpoint OV-7 Services Viewpoint SV-11 All Service Versions of SV Products Systems Viewpoint All Systems Versions of SV Products DoDAF V1.5 Capability Viewpoint Project Viewpoint Standards Viewpoint Operational Viewpoint Rest of OVs All TVs All Viewpoint All AVs DoDAF V2.0 New Updated Moved DoDAF Metamodel (DM2) Fit For Purpose Presentation Dashboards Graphical Depictions Reference Models Fusion Products Composite Products

20 6/23/2010 Perspectives: Viewpoints That Fit-the- Purpose Architecture viewpoints are composed of data that has been organized to facilitate understanding. All Viewpoint Overarching aspects of architecture context that relate to all models Data and Information Viewpoint Articulate the data relationships and alignment structures in the architecture content Standards Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts 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 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.

21 6/23/201021 DoDAF V2.0 Focus: Terms DoDAF V1.5DoDAF V2.0 ArchitectureArchitectural Description Architecture dataArchitectural data ProductModel (a template for collecting data) ProductView (a model with data for an architecture) ViewViewpoint 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 6/23/201022 Methodology: DoDAF V2.0 Six-Step Architecture Development Process Determine the intended use of the architecture Determine the intended use of the architecture 1 Determine scope of architecture Determine scope of architecture 2 Determine data required to support architecture development Determine data required to support architecture development 3 Collect, organize, correlate, and store architecture data Collect, organize, correlate, and store architecture data 4 Conduct analyses in support of architecture objectives Conduct analyses in support of architecture objectives 5 Document Results IAW Decision-Maker needs Document Results IAW Decision-Maker needs 6 Provide list of data needed and use cases Provide list of data needed and use cases 3.1 Model to DM2 Concept List Model to DM2 Concept List Review list of architecture data and determine if it meets the use cases Review list of architecture data and determine if it meets the use cases 3.2 DM2 Conceptual Data Model & Logical Data Model DM2 Conceptual Data Model & Logical Data Model Assist with the Architects data collection processes Assist with the Architects data collection processes 4.1 List of architecture data List of architecture data Potential Collection Methods Potential Collection Methods Selected Collection Methods Selected Collection Methods Verify the data collected meets the use cases Verify the data collected meets the use cases 5.1 Example Uses Example Uses Fit-for-Purpose Use Fit-for-Purpose Use Determine how data needs to be presented Determine how data needs to be presented 6.1 Legacy Products Legacy Products User Requirements User Requirements Example Presentations Example Presentations Fit-for-Purpose Presentations Fit-for-Purpose Presentations 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 6/23/201023 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 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 OV -2 is:

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

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

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

27 6/23/201027 A (Not Exactly) Fortuitous Coming Together of UML & DoDAF… OV-1High-Level Operational Concept Graphic HLOCHigh-Level Operational Concept Graphic (not really UML; more.ppt) OV-2Operational Node Connectivity Description NCDNode Connectivity Description OV-3Operational Information Exchange Matrix SOSSystem Operational Sequence OV-4Organizational Relationships ChartNRDNode Relationship Diagram OV-5Operational Activity ModelUCDUse Case Diagram or Activity Diagram OV-6aOperational Rules ModelUCSUse Case Specification (Text) OV-6bOperational State Transition Description StCDState Chart Diagram OV-6c Operational Event-Trace Description OTSOperational Trace Sequences OV-7Logical Data Model (Related to AV-2, Dictionary) CRD, LDM Class Relationship Diagram, Logical Data Model DoDAFUML

28 6/23/201028 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 TPMs 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 Integratio n System Test Validated System Systems Engineering Process

29 6/23/201029 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 TPMs 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 Integratio n System Test Validated System Systems Engineering Process

30 6/23/201030 System Architecture Selection Process Steps

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


Download ppt "Architecture Ignore at your own risk (DODAF 2.0 – Its the law for all future DOD programs) Dale Waldo Boeing Associate Technical Fellow - Systems Engineering."

Similar presentations


Ads by Google