Systems Architecting An introduction

Agenda Evolution of Systems Relating Systems Engineering & Architectures Representing an Architecture Using Architectures Summary

Evolution of Systems

Evolution of Systems

Evolution of Systems

Systems are becoming increasingly large and complex Evolution of Systems Systems are becoming increasingly large and complex

No Easy Answer Modern Systems: Ill-Structured Involve New & Untested Ideas Complex

Overcoming these Problems Maybe he doesn’t want to be in charge of the next customer review How will we: Manage uncertainty Manage complexity Manage technological change

Systems Engineering: the Process A process that transforms an operational need or market opportunity into a system description to support detail design. Requirements Analysis Functional Analysis Synthesis Systems Analysis / Management

Systems Architecture: a Product The design team’s interpretation / implementation of customer requirements communicated thru: System Usage Scenarios (i.e., Use Cases) Functional Components & Interrelationships Physical Subsystems & Interfaces Etc…

Systems Architecting: a Methodology A Segment of the Systems Engineering Process Which Facilitates the Identification of: System Elements Relationships Design Principles That Collectively Satisfy Customer Requirements and Meet User Needs.

Architecting in the Systems Engineering Process Inputs Stakeholder Inputs Operational Requirements MOE’s Environments Constraints Capability-Based Acquisition Quality Attributes Interoperability COTS/GOTS/BOTS Re-Use and Legacy Technology Base Prior Phase Results Applied Standards System Analysis Modeling & Simulation Trade Studies Effectiveness Analysis Requirements Analysis Analyze Missions and Environments Identify Functional Requirements Define/Refine Performance and Design Constraints Identify Quality Attributes Validate Requirements Goal/Mission Analysis/Validation Functional Architecture Analysis System Management Risk Management Data Management Configuration Management Progress Measurement IMP/IMS & TPMs Technical Reviews Requirements Loop Functional Analysis & Allocation Decompose to Next-Lower Level Functions Define/Refine Functional Interfaces (Internal/External) Define/Refine/Integrate Functional Architecture Allocate Performance & Other Requirements Physical Architecture Analysis Design Loop Verification Loop Synthesis Transform Each Level’s Architecture from Functional to Physical Define Alternative System Concepts & Configuration Items Define/Refine Physical Interfaces (Internal/External) Identify Candidate Architecture Styles Select “Best Value” Design Iteration Loop (Derived Requirements for the Next Level of Decomposition) Process Outputs “Best Value” System Architecture System Architecture Models and Specifications

The Two Primary Methods of Architecting Structured Analysis and Design Technique (SADT) Graphical Representation of System Requirements Boxes and Arrows Logical Flows Object-Oriented Analysis (OOA) and the Unified Modeling Language (UML) Structure Diagrams Behavior Diagrams Interaction Diagrams

Goals of Systems Architecting Take into account the whole picture Life cycle phases, boundaries, external elements… Users, builders, benefactors, supporters, environments Affordability, safety, availability, survivability, security, etc. Communicate clearly the components and their inter-relationships from user and engineering perspectives for customer validation for use in analysis and design by all engineering disciplines

Describing the Architecture Physical Descriptions Operational Expectations Many perspectives: physical, functional, operational, technical… Behavioral Descriptions

Physical View to an Architecture

Functional View to an Architecture (Example Based on Unified Modeling Language)

Product Diagrams of the Systems Architecture Use Case Diagrams Class Diagrams Activity & State Diagrams Sequence Diagrams

DoDAF – DoD Architecture Framework Customer Defined Views of the Model

Operational View (OV) What needs to be done & Who does it High Level Operational Concept Graphic (OV-1) Operational Exchange Matrix (OV-3) The OV is a description of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. DoD missions include both war fighting missions and business processes. The OV contains graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges. An Operational View (OV) describes the tasks and activities, operational elements, and information exchanges required to conduct operations. A pure OV is materiel independent. However, operations and their relationships may be influenced by new technologies such as collaboration technology, where process improvements are in practice before policy can reflect the new procedures. There may be some cases, as well, in which it is necessary to document the way processes are performed given the restrictions of current systems, in order to examine ways in which new systems could facilitate streamlining the processes. In such cases, an OV may have materiel constraints and requirements that must be addressed. For this reason, it may be necessary to include some high- level Systems View (SV) architecture data as overlays or augmenting information onto the OV products. There are seven OV products described in this section: · High-Level Operational Concept Graphic (OV-1) · Operational Node Connectivity Description (OV-2) · Operational Information Exchange Matrix (OV-3) · Organizational Relationships Chart (OV-4) · Operational Activity Model (OV-5) · Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, and 6c) · Logical Data Model (OV-7) Operational Node Connectivity Diagram (OV-2) Organizational Relationships Chart (OV-4)

System View (SV) Relates Systems and Characteristics to Operational Needs System Interface Description (SV-1) System – Systems Matrix (SV-3) The SV is a set of graphical and textual products that describes systems and interconnections providing for, or supporting, DoD functions. DoD functions include both warfighting and business functions. The SV associates system resources to the OV. These system resources support the operational activities and facilitate the exchange of information among operational nodes. The Systems View (SV) is a set of graphical and textual products that describe systems and interconnections providing for, or supporting, DoD functions. SV products focus on specific physical systems with specific physical (geographical) locations. The relationship between architecture data elements across the SV to the Operational View (OV) can be exemplified as systems are procured and fielded to support organizations and their operations. There are eleven SV products: · Systems Interface Description (SV-1) · Systems Communications Description (SV-2) · Systems-Systems Matrix (SV-3) · Systems Functionality Description (SV-4) · Operational Activity to Systems Functionality Traceability Matrix (SV-5) · Systems Data Exchange Matrix (SV-6) · Systems Performance Parameters Matrix (SV-7) · Systems Evolution Description (SV-8) · Systems Technology Forecasts (SV-9) · Systems Functionality and Timing Descriptions (SV-10a, 10b, and 10c) · Physical Schema (SV-11) System Functionality Description (SV-4) UML Version System Functionality Description (SV-4)

Technical View (TV) Prescribes Standards and Conventions System Products Associated With Standards (TV – 1) Template for Time Records (TV-1) The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. The TV includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria organized into profile(s) that govern systems and system elements for a given architecture. The Technical Standards View (TV) provides the technical systems-implementation standards upon which engineering specifications are based, common building blocks are established, and product lines are developed. The TV includes two products: · Technical Standards Profile (TV-1) · Technical Standards Forecast (TV-2) Technical Standards Profile Template (TV-1)

25 Views Integrated Together AV – 1 Overview & Summary Information AV – 2 Integrated Dictionary OV – 1 High Level Operational Concept OV – 2 Op. Node Connectivity Description OV – 3 Op. Informational Exchange Matrix OV – 4 Org. Relationships Chart OV – 5 Activity Model OV – 6a Operational Rules OV – 6b Operational State Transition OV – 6c Op. Event Trace Description OV – 7 Logical Data Mode SV – 1 Systems Interface Description SV – 2 Systems Communication Description SV – 3 Systems Matrix SV – 4 System Functionality Description SV – 5 Op. Activity to Systems Function Traceability Matrix SV – 6 System Data Exchange Matrix SV – 7 System Performance Parameters SV – 8 System Evolution Description SV – 9 System Technology Forecast SV – 10a System Rules Model SV – 10b System State Transition Description SV – 11 Physical Data Model TV – 1 Technical Architecture Profile TV – 2 Standards Technology Forecast

DoDAF Summary DoDAF is a way of describing a system. DoDAF represents a number of different views of the architecture. DoDAF is a required output to our customers. DoDAF is NOT a methodology or process. DoDAF is NOT a UML based set of views.

Benefits of Architecting Identifies All System Elements Earlier vs. Later Matches Function to Requirements Capture & Communicate Key concepts Results in ONE design Manages Increasing Complexity Allows Modular Design

Users of the Architecture Systems Architect: Translate Client Needs into Builder Requirements System Designers: Design Guidance Program Managers: Program Performance Measurement and Guidance Customers: Validation of Requirements and Design Other Stakeholders: Various Views of the System* Manufacturers - Trainers Testers - Users Purchasers - Logistics Personnel Handlers - Maintainers * Adapted from: Agile Systems Engineering Architecting: Methods, Processes, and Practices Stevens Institute of Technology, March 15, 2004

Architecture Used In … Analysis of Alternatives (AoA) Business and Technical Planning Communications among Organizations Internal to Internal Internal to External Input to Subsequent System Design and Development Criteria for Certifying Conformance of Implementations Development, Maintenance, and Reuse Repositories Review, analysis, and evaluation of the system across the life cycle Basis for incremental/spiral development

Characteristics of a Systems Architect Analytical Attention to Detail Visionary Generalist Common Sense Know-How Drive Critical Attitude Multi-tasking Teamwork Communicator/Documenter Flexible Process Insight Political Insight/Negotiation

The Risks of Architecting Early Identification of Problems Perception of Program Delay Inconsistent Application of Methodologies Limited Numbers of Skilled Creators/ Reviewers

Risks of Not Architecting Late Identification of Problems Lack of Unified Design Issues of Complexity Management

Example Architecture Issues Audi 2006 A8, A8 L, and A8 L W12 Passenger Vehicles On certain passenger vehicles, a wiring harness condition exists that may deactivate the passenger side frontal air bag even under circumstances when it should remain activated. Starbucks Coffee Company Recall of Ceramic Teapots The teapots are labeled safe for microwave use, but the handles can become hot in the microwave oven. This poses a possible burn hazard to consumers. Microsoft Xbox 360 – Class Action Lawsuit There may be a design flaw which causes the console's power supply and CPU to overheat, causing the whole system to seize up. Complaints of similar freezing problems began to surface almost as soon as the Xbox 360 went on sale November 22.

Summary Increasingly complex systems drive a need for better, clearer design descriptions Architectures convey the system designer’s interpretation of the requirements Architectures may be presented by a variety of views which collectively describe the system As part of the systems engineering process, systems architecting defines and manages development of a system

References Boeing Systems Architecture Development Guidebook “The Art of Systems Architecting”, Eberhardt Rechtin, Mark W. Maier DoD Architecture Framework (DoDAF)

Recommended Use of DoDAF Products Suggest that the lecturer doesn’t go over the details but just makes the point that there are ways to use the dodaf products in different phases of the architecture process – reuse means we don’t need to do some other diagrams if we can use the ones we created for the customer to help us describe some aspects of our design

DoDAF View Extraction

Evolving Architectures: Impact of Spiral Development

Model-Based Architecture Why Model-Based Architectures? Help to Explain How Things Work Broaden Our Perspective Provide a Common Conceptual Frame of Reference Express Rules More Simply Clarify Relationships, Identify Key Elements, and Consciously Eliminate Confusion Factors From: Forsbert, Kevin; “Visualizing Project Management”, Pg. 14