1. Systems Architecting
An introduction

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

3. Evolution of Systems

4. Evolution of Systems

5. Evolution of Systems

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

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

8. 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

9. 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

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

11. 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.

12. 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

13. 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

14. 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

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

16. Physical View to an Architecture

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

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

19. DoDAF – DoD Architecture Framework Customer Defined Views of the Model

20. 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)

21. 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)

22. 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)

23. 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

24. 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.

25. 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

26. 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

27. 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

28. 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

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

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

31. 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.

32. 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

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

35. 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

36. DoDAF View Extraction

37. Evolving Architectures: Impact of Spiral Development

38. 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