System Architecting

1
System Architecting
2
Conventional Engineering Design Paradigm

• Traditional engineering tends to jump to design
  solutions very early in the process of problem
  definition (and solving) and fixes the unintended
  emergence as and when it occurs
• There is a strong pre-disposition to re-use and
  adapt existing design solutions
• This commitment to a specific solution
  architecture occurs early in the requirements
  definition stage and is very difficult to depart
  from
• Innovation is as often driven by technical
  enthusiasm as much as by user need
• The operating paradigm is generally evolutionary
  stepwise advance generation by generation.

In conventional system design The System of
Interest and its configuration are the Centre of
Interest
3
The Focus Is On The System To Be Deployed
Source Martin, J., 2004, The Seven Samurai of
Systems Engineering, INCOSE International
Conference on UWEOnline
Source Martin, J., 2004, The Seven Samurai of
Systems Engineering, INCOSE International
Conference on UWEOnline
4
The Focus Is On The System To Be Deployed
The System of Interest
Source Martin, J., 2004, The Seven Samurai of
Systems Engineering, INCOSE International
Conference on UWEOnline
Source Martin, J., 2004, The Seven Samurai of
Systems Engineering, INCOSE International
Conference on UWEOnline
5
The Focus is Generally on the System of Interest
Containing system
Look at the Interactions
System
System
System of Interest
B
A
System
What are the interactions required with the
System of Interest These are the STAKEHOLDER or
USER REQUIREMENTS
6
However We Need to Understand The Interactions
and Opportunities
Containing system
Do the Stakeholders Know?
Look at the Interactions
System
But Is the Boundary Right?
System
First Treat the System of Interest as a Black Box
System of Interest
A
B
System
White box analysis
7
Explore The Robustness of the Requirements

• Perceptions of need are often framed against a
  conscious or unconscious pre-disposition to a
  particular solution
• Challenge that by proposing alternate solutions
  to explore the stated needs
• If the requirements appear stable perhaps
  challenge that stability with bizarre
  alternatives
• Try and mine the stated requirements as initially
  stated to bring out the underlying needs (or
  aspiration) that the candidate has revealed
• A test for a very robust requirement is that it
  survives intact with a wide variety of candidate
  solutions
• If not why not?

8
The Use of Candidates Solutions Can Facilitate
Understanding
If some candidates do not meet the emerging
stakeholder requirements they have still
served a purpose!!
9
But Be Careful..

• The candidate solutions considered are often only
  increments of the existing solutions
• Extension of an existing design
• A development of what the customer already uses
• The frame of reference often constrains the
  solution space to an low margin incremental
  opportunity
• Consider taking the analysis up a level to
  consider the System of Systems issues
• Question the stakeholders to understand their
  stakeholders needs the childlike Why? has
  its merits!

So Where Is This Particularly Important?
10
Strategic (Enterprise) Architecting - Airbus
11
Integrated Power Systems Rolls Royce

• Conventional Power System
• Engine provides thrust plus mechanical
  pneumatic power.
• Aircraft systems transform mechanical power into
  electrical/hydraulic power.
• System components individually optimised, system
  functionally integrated.

• Integrated Power System
• IPS provides thrust plus mechanical, electrical,
  pneumatic hydraulic power.
• Aircraft systems define demand for power which is
  interpreted by the IPS Resource Manager.
• System components are designed to deliver optimal
  system performance.

Source INCOSE BLG Presentation Sept 2004
Gordon Warnes, Rolls Royce
12
Candidate Architecture

• Getting this right is critical to success
• Modelling can support decision-making
• Expert viewpoints are a critical success factor
• The further the departure from the norm the
  higher the risks but offset by potentially much
  higher returns
• Early Risk Reduction becomes dominant paradigm
  for innovative lines of development

13
To Take the Analysis Further We Need to Open the
Box and Start Testing the Architecture
Now We Need to Open the Box
Containing system
System
System
System of Interest
A
B
System
White box analysis
14
With the Candidate Architectures

• Once the initial stakeholder requirements
  (including in house ones) are exposed the
  candidate systems of interest can then be
  explored from a wide range of viewpoints
• Manufacture Does it use the existing
  infrastructure?
• Use Will the customer need to collaborate?
• Support Who is providing it?
• Maintenance Are we paying?
• Misuse Is it vulnerable?
• Retirement Can we recycle/reuse it?
• Disposal Are there new hazards?
• etc.?????
• The ambition is to achieve an understanding of
  both desirable and undesirable interactions.

These will be dependent on the system
architecture ultimately chosen and in reality are
often determinants of it
15
Remember Rich Pictures Help to Illuminate
Interactions
16
Life-Cycle Views

• What is required of the system of interest over
  time
• What is the proposed system replacing?
• What is its predecessor doing
• What new is needed
• When will it be needed?
• How will it be introduced?
• How will it be supported?
• When will it be replaced?

Again some of these issues will reveal
constraints which will ultimately lead to certain
candidates being unviable
17
The Systems Engineering Life- Cycle Standard
ISO15288
Need to be Considered at the Stakeholder
Requirements and Architecting Stages
18
So Now We Know Whats Wanted What Next?
System Requirements
Containing system
Attributes of A-B interactions
Attributes of interactions with other systems
System
Attributes of B
Attributes of A
System
System of Interest
A
B
System
19
So Now We Know Whats Wanted What Next System
Requirements
We now have more Black Boxes at a Lower Level in
the Hierarchy!!
Containing system
System
System
System of Interest
Black Box 1
Black Box 2
System
WHITE BOX
20
Developing the Systems Resqirement Document (SRD)
Often Forms Part of a Concept Study

• SRD Development is a fluid process
• Often driven by Simulation, Modelling, Scenario
  Investigation, Review of Technology Options
• The objective is to determine the risk, cost,
  return balance to develop a realistic SRD which
  can be costed
• This phase is often undertaken in a separate
  contract often led be a party who is barred from
  bidding for the main contract
• In a non-contractual environment it may be led by
  a team of experts drawn from the lead company and
  its suppliers and run as a discrete activity

21
A Typical Process for System Requirements
Maturation
Note The Feedback Loop
22
Heuristics (Guides) Can Be Used to Assist
Architectural Development - A Challenge!!

• The team that created and built the present
  successful product is often the best for its
  evolution but seldom for creating its replacement
• If you dont understand the present system you
  cant be sure youre re-architecting a better one
• When implementing a change keep some elements
  constant to provide an anchor point

Source Maier, M. and Rechtin, E (2003) The Art
of Systems Architecting, CRC Press
23
Heuristics (Guides) Can Be Used to Assist
Architectural Development - A Challenge!!

• A good design has benefits in more than one area
• System quality is defined in terms of customer
  satisfaction not requirements satisfaction
• If you think your design is perfect it is only
  because you havent shown it to someone else
• Proven and State of the Art are mutually
  exclusive qualities

Source Maier, M. and Rechtin, E (2003) The Art
of Systems Architecting, CRC Press
24
You will find hundreds of these in Maier and
Rechtins book!!
However the production of a viable system still
depends on engineering the detail right..
25
Once The Architecture Is Set (or Postulated) Then
The Conventional SE Tools Come into Play To
Design, Develop and Verify
Source INCOSE BLG Presentation Sept 2004
Gordon Warnes, Rolls Royce