Lect 2: Systems Thinking and System Architecturesmslab.kaist.ac.kr/Course/EE612/2014/lecture_note/Lect2.pdf · EE612: Lect. 2 – Systems Thinking and Architecture © 2014 Tag Gon

Lect 2: Systems Thinking and

System Architecture

2 of 31

© 2014 Tag Gon Kim EE612: Lect. 2 – Systems Thinking and Architecture

Systems Thinking

Motivation from the Einstein’s comment

“Problems cannot be solved by the same level of thinking that created them.”

- Albert Einstein-

Definition

“Any process of estimating or inferring how local policies, actions, or changes

influences the state of the neighboring universe” [Wikipedia Encyclopedia]

“Systems thinking is a discipline for seeing wholes, recognizing patterns and

interrelationships, and learning how to structure those interrelationships in more

effective, efficient ways.” [Senge, P. & Lannon-Kim, C., 1991]

Objective of Systems Thinking

Learning to see the world systemically

Reasoning of Multi-levels for a system

Reasoning of Multi-aspects for a system

PARTS WHOLE

System

+ +

3 of 31


See the whole picture

See the forest and trees

View from different aspects

Look for interdependencies

Understand different models

Think long term

Think about cause and effect relationships widely

Think potential opportunities and unintended risks

Focus on problem solving, not finding blame

Purposes of Systems Thinking

4 of 31


Understanding of system requirements

Understanding the system requirements regardless of

the position of one’s product in the system

decomposition hierarchy

Impact of system requirements on subsystems

Assessing the impact of system requirements on

subsystems for which ones are responsible

Impact of subsystem constraints on the system

Assessing the impact of subsystem constraints on the

system

Impact of the subsystem’s requirements on lower level

products

Assessing the impact of the subsystem’s requirements

on lower level products before selecting a subsystem

concept

What Does “Systems Thinking” Involve?

How do I define

this as a system?

5 of 31


Why Systems Thinking is Important?

To comprehend and manage the requirements, and to develop the solution, we have to understand how it fits into the larger system of which it is a part.

System

Customers Authorities

Regulations

Impacts

When our response to opportunities and challenges is fragmented, the results are often insufficient or short sighted.

Life Cycle (Disposal)

* Dennis M. Buede, The Engineering Design of Systems, 2000, John Wiley & Sons.

“Never forget that the system being addressed by one group of engineers is the subsystem of another group and the super-system of yet a third group.”*

6 of 31


Traditional vs. Systems Thinking

Systems Thinking

(Strategic, Systematic Thinking)

Identify a whole that contains the “Thing” of interest

Explain the behavior of the containing whole

Explain the behavior of the “Thing” to be explained in terms

of its functions within its containing whole

Thing

“Containing”

environment

“Containing”

environment

Thing

Function 1

Function 2

Function K

Step Traditional Thinking

(Analytic, Reductionistic, Mechanistic Thinking)

1

2

3

Decompose

Explain the behavior of each part, separately, in isolation

Aggregate the part behaviors into an explanation of the whole

Thing

Part 1

Part 2

Part N

Part 1

Part 2

Part N

Thing

Part 1

Part 2

Part N

7 of 31


Diagrams for Systems Thinking

Elements Visual Form

Spray Diagram

Central circle or blob for main topic;

Blobs for sub-topics(optional);

Words on the lines or at the ends of lines;

Branching sets of lines; Title

Rich Picture Pictorial symbols;

Keywords; Cartoons;

Sketches; Symbols; Title

Systems Map Blobs of varying sizes;

Words; Title

Influence Diagram Blobs of varying sizes; Assorted arrows;

Words labeling and possibly also labeling arrows;

Key for arrows; Title

Multiple Cause

Diagram

System boundary(optional); Phrases;

Arrows(which may occasionally be labeled);

Title

Causal Loop

Diagram

Phrases;

Arrows labeled with either + or – sign;

Title

Main

Topic

Sub

Topic2 Sub

Topic1

aaa bbb ccc ddd

eee

fff

ggg hhh

ccc

ccc

bbb aaa

ddd

ddd

eee

eee

fff ggg

1 2

3

3

4

4

5

5

6

bbb

ccc ddd eee

aaa

fff

1 2

3

4

5 6

ggg

bbb

ccc ddd

eee aaa

fff

ggg

bbb

ccc ddd

eee aaa

fff

+

+

+ +

+

- -

-

-

-

questions accurate

relevant

records

treasurer

How used?

What use?

8 of 31


Example: Causal Loop Diagram

Deficit

Spending

Tax Rate

Tax-able

Economy

Manipulating

Income

Incentive to

Avoid Taxes

Tax Collected

Tax Driven

Investing

+

+

-

[Higher Tax Rates Mean More Taxes Collected]

-

+ +

[Business Management]

Invest in

Capacity

Reduce Free

Capacity

Increase

Lead Time

Cash in

Manufacture

Reduce Customer

Satisfaction

Sell

Invest in

Sales Force

+

+

-

+

+ +

+

- -

-

-

- -

9 of 31


Example: Systems Map

10 of 31


System of Interest

Hierarchical Relationships of Enabling Systems

System of Interest

System of Interest

Project Project

Program

Enabling Systems

Enabling Systems

Enabling Systems

Systems engineering focus must include all aspects of the

environment in which the system of interest operates.

Subsystem Subsystem

Assembly Assembly

11 of 31


Techniques That Promote Systems Thinking

USER Manual

Concurrent Engineering

Concurrent product and process development Consider all phases of the product life cycle Consider all stakeholders need

Validation Planning and Solution Requirements

Early determination of the customer validation Clarify requirements Verification planning at concept development Eliminate flawed concepts that lead to failure.

Discovery and Analysis

Consideration of all needs through stakeholder

involvement

Identify alternate solutions

Rigorous analysis

Define the best solution

12 of 31


What is System Architecture?

It is the fundamental organization of a system embodied

in its environments, their relationships to each other, and

to the environment, and the principles guiding its design

and evolution.”

[ IEEE 1471-2000 (Sept 21, 2000) ]

It is the fundamental and unifying system structure

defined in terms of system elements, interfaces, processes,

constraints, and behaviors.

[ INCOSE System Architecture Working Group]

It is the structure of components, their relationships, and

the principles and guidelines governing their design and

evolution over time.

[ Department of Defense (DOD) Architecture Framework v1.0 ]

Building Architecture

13 of 31


What is good Architecture?

Role of System Architecture is the link between requirement and design

What is good architecture?

Satisfaction to stakeholders (users)

Allowing maintenance, evolution, further development,

embedding per users’ requests

Elegance

Intellectually clean of unnecessary complexities

Feasible implementation

Cost-effective structures that can be buildable in limited time and budget

Needs analysis

Project scoping

Functional analysis

First descriptions

of the system structure

Link

14 of 31


Principles of System Architecture

Robust functionality derives essential complexity

All design process should involve iteration

Only customer judges quality

Holistic thinking

Modularity

Identity

Conceptual brilliance doesn’t blind the laws of physics

Standardized process improvement

Early defect elimination

Value is identified outside

KISS(Keep It Simple, Stupid)

* Adapted from ESD.34 system architecture at MIT

15 of 31


Essence and Balance for System Architecting

The essence of architecting is structuring, simplification, compromise,

and balance.

This balance is achieved by appropriate compromise between:

System requirements

Function

Form

Simplicity

Robustness

Affordability

Complexity

Environmental imperatives

Human factors

16 of 31


Development of System Architecture

Creating an architecture is the beginning of the system design process

with the typical development sequence is:

1. Establish initial system requirements

- needs analysis, project scoping, and the

- development of the concept of operations (conops).

2. Define the following

- external boundaries

- constraints, scope, context, environment

- assumptions

3. Develop candidate system architectures

- iterative process using these initial requirements.

4. For each architecture,

- compare the benefits, costs, risks

- consider modifying their conops, system performance and

even their system functions

AoA: Analysis of Alternatives

17 of 31


What needs are we trying to fill?

How are current solutions insufficient?

Are the needs completely described?

Who are the intended users?

How will the system be used?

How is this use different from heritage

systems?

What capabilities are required?

At what level of performance?

Are segment interfaces well defined?

What is the overall approach?

What elements make up this approach?

Are these elements complete, logical, and

consistent?

Needs Analysis

ConOps

Functional

Requirements

System Architectures

Work With Customer

to Potentially Modify

Problem Statement

Based on Solution

Options

Work With Customer

to Potentially Modify

Problem Statement

Based on Solution

Options

Developing Candidate S.A.:Recursive and Iterative

18 of 31


How Do We Create Architectures?

There are two primary techniques to create architectures, both benefit from

understanding the performance and limitations of heritage systems.

Synthesis

Modifying or combining existing systems to satisfy stated needs

Requires logic and good knowledge of existing systems

What functions do I need to get the job done?

Can I combine existing systems without too much baggage?

Discovery

Leverage knowledge of existing architectures to ‘discover’ a new one

Requires knowledge of existing systems and abstraction skills

Is there an analogous system in another domain?

What are the good or bad properties of a given architecture?

19 of 31


Deductive/Inductive Methods for Arch. Creation

Science-based, deductive methods: (일반적 명제들구체적 결론)

Normative (규범적)

Hard rules are provided (from somewhere), success is defined by following

the rules

“If it doesn’t look like what we are doing now it must be wrong.”

Rational (합리적)

Solutions derived from objectives

General systems problem solvers, optimization and formal techniques

Rule based

Art-based, inductive methods: (구체적 사실 일반화된 결론)

Participative (참여적)

Solution from group process, design by group consensus. Stakeholders

involved

Heuristic (체험적)

Lessons learned based

Develop solutions through soft rules that are driven by experience

20 of 31


Architecture vs. Design

A system architecture creates the conceptual structure within which subsequent system design occurs.

Both a system architecture and a system design support system synthesis, but they have different uses.

System architecture is used:

To establish the framework for subsequent system design

To support make-buy decisions

To discriminate between alternative solutions

To ‘discover’ the true requirements or the ‘true’ priorities

System design is used:

To develop system components that meet functional and performance requirements and constraints

To build the system

To understand the system-wide ripple effects of configuration changes

21 of 31


Example : The James Webb Space Telescope Communications Architecture

The launch vehicle injects observatory into an L2 transfer trajectory

The observatory operates at L2 point for 5 years with a goal of 10 years, providing imagery and spectroscopy in the Near and Mid Infrared wavebands.

The Ground Segment receives downloads of science data and sends command uploads during daily 4 hour contacts

Ground Segment uploads plans to the Observatory ~once a week and the observatory autonomously executes these plans

JPL

Deep Space

Network

(DSN)

GSFC

Flight

Dynamics

Facility (FDF)

STScI Science & Operations

Center (S&OC)

Flight

Operations

Subsystem

(FOS)

Data

Management

Subsystem

(DMS)

Wavefront

Sensing &

Control Exec

(WFSC Exec)

Proposal

Planning

Subsystem

(PPS)

Operations

Script

Subsystem

(OSS)

Project

Reference DB

Subsystem

(PRDS)

Observatory

Simulators

(OTB/STS)

Madrid

NA

SA

In

teg

rate

d S

erv

ices N

etw

ork

(N

ISN

)

L2 Point

Launch

Segment

Observatory

Segment

L2 Transfer Trajectory

Ground Segment

Goldstone Canberra

L2 Lissajous Orbit

NASA Provided

Communication

Asset for Early

Orbit Phase

22 of 31


Example II: JWST Observatory Architecture

23 of 31


System Architecture Frameworks

Architecture Framework (AF)

Description/Specification/modeling of System Architecture

Using Picture, Text, Graph, Diagram, Table and other means

Many standard AFs exist including:

C4ISR & DODAF(Department of Defense Architecture Framework)

Zachman Framework

FEAF(Federal Enterprise Architecture Framework)

TEAF(Treasury Enterprise Architecture Framework )

TOGAF(The Open Group Architecture Framework)

etc.

24 of 31


DoD Architecture Framework (DoDAF)

Overview

The United States Department of Defense(DoD) developed the DoD

Architecture Framework(DoDAF) for describing, presenting, and

comparing DoD Enterprise Architecture

History

DoDAF v1.0, Aug 2003 : Broaden of C4ISR AF v2.0 (1997) to all areas

DoDAF v1.5, April 2007: Incorporation of Network Centric concepts

DoDAF specifies architecture in three consistent views

Standards Rules Conventions

Platforms/Components Data flows

Networks Interfaces

Tasks, activities

Operational elements

Information exchange

Operational View

Service/system View

Technical View

25 of 31


Detailed views in DODAF

Operational View : 7 items

OV-1: High Level Operational Concept Graphic

OV-2 : Operational Node Connectivity Description

….

OV6c : Operational Event-Trace Description

OV-7 : Logical Data Model

Service/System View : 11 items

SV-1 : System Interface Description

SV-2 : Systems Connectivity Description

SV-3 : Systems-Systems Matrix

…..

SV-10c : Systems Event-Trace Description

SV-11 : Physical Schema

Technical View : 2 items

TV-1 : Technical Standard Profile

TV-2 : Technical Standard Forecast

DoD Architecture Framework (DoDAF)

26 of 31


Zachman Framework

Overview

John Zachman published the Zachman Framework for Enterprise

Architecture in 1987

Provides a structured way of viewing and defining an enterprise

Presents the audience(Perspective View) as well as

the content or subject focus(5W1H View) with a 6x6 matrix form

Row : 6 Perspective view

Column : 5W1H view

Row 1 : Planner’s View

(Objective/Scope)

Row 2 : Owner’s View

(Enterprise/Business Model)

Row 3 : Designer’s View

(Information Systems Model)

Row 4 : Builder’s View

(Technology Model)

Row 5 : Subcontractor View

(Detailed Specification)

Row 6 : Actual System View

Col 1 : Material description — What

Col 2 : Functional description — How

Col 3 : Spatial description — Where

Col 4 : People description — Who

Col 5 : Timing description — When

Col 6 : Motivation description — Why

27 of 31


Zachman Framework

Detailed Views of Enterprise Architecture with Zachman Framework

Source : Zachman Institute for Framework Advancement, <www.zifa.com>

28 of 31


Federal Enterprise Architecture (FEAF)

Overviews

The US CIO Council published the Federal Enterprise Architecture

Framework(FEAF) in 1989

Provides direction and guidance to federal agencies for structuring an

enterprise architecture

Structure of FEAF

Business

Architecture

Data

Architecture

Applications

Architecture

Technology

Architecture

Target

Architecture

Business

Architecture

Data

Architecture

Applications

Architecture

Technology

Architecture

Current

Architecture

Architecture

Driver

Business

Drivers

Design

Drivers

<Input>

Vision

Strategic

Direction

Principles

<Output>

Investment Review

Segment Coordination

Market Research

Asset Management

Security, Data,

Application, Technology

Transition

29 of 31


Federal Enterprise Architecture (FEAF)

Detailed Views in FEAF

Partitions a given architecture into Business, Data, Applications, and

Technology Architectures

Data, Application, Technology Architectures are represented as a 5x3 matrix

with architecture types and perspectives

Data

Architecture

Applications

Architecture

Technology

Architecture

Planner

Perspective List of Business Objects List of Business Processes List of Business Locations

Owner

Perspective Semantic Model Business Process Model Business Logistics System

Designer

Perspective Logistics Data Model Applications Architecture

System Geographic

Deployment Architecture

Builder

Perspective Physical Data Model Systems Design Technology Architecture

Subcontractor

Perspective Data Directory Programs Network Architecture

Business

Architecture

Data

Architecture

Applications

Architecture

Technology

Architecture

Current

Architecture

30 of 31


Treasury Enterprise Architecture Framework (TEAF)

Overview

The US Department of the Treasury developed TEAF in 2000

Provides

Guidance to Treasury bureaus concerning the development and evolution of information systems

architecture

A unifying concept, common principles, technologies, and standards for information systems

A template for the development of the Enterprise Architecture(EA)

Structure of TEAF

EA Description

EA Direction

• Agency Policies

• Strategic Plans

• Enterprise Architecture

Roadmap

• Enterprise Principles

EA

Accomplishment

• Enterprise Transition

Strategy

• Forecast

Functional

Information

Organizational

Infrastructure Enabler

Who and Why

What, How Much,

and How Frequently

How, Where, and When

Description

View

31 of 31


Treasury Enterprise Architecture Framework (TEAF)

Detailed Views in TEAF

Functional

View

Information

View

Organizational

View

Infrastructure

View

Planner

Perspective

Mission & Vision

Statements

Information

Dictionary List of Business Locations

Technical Reference

Model

Standards Profile

Owner

Perspective

Activity Model

Info Assurance

Trust Model

Information Exchange

Matrix

(Conceptual)

Node Connectivity

Description

(Conceptual)

Info Assurance

Risk Assessment

System Interface Description

(Level 1)

Designer

Perspective

Business Process/System

Function Matrix

Event Trace Diagrams

State Charts


Matrix

(Logical)

Data CRUD Matrices

Node Connectivity

Description

(Logical)


(Level 2 & 3)

Builder

Perspective

System Functionality

Description


Matrix

(Physical)

Physical Data Model

Node Connectivity

Description

(Physical)


(Level 4)

System Performance

Parameters Matrix

Documents

Lect 2: Systems Thinking and System Architecturesmslab.kaist.ac.kr/Course/EE612/2014/lecture_note/Lect2.pdf · EE612: Lect. 2 – Systems Thinking and Architecture © 2014 Tag Gon