Architecting in a Complex
System Environment
John Hodgson & Phil Piper
ICT Architects
The fundamentals of Complex IT System/s
(Using Government systems examples)




Complex IT systems


What is a complex IT system?
Common Factors and Influences (within a Government environment).

Value and issues in identifying, analysing, designing and specifying IT
systems in a complex environment.
A Systems of Systems view
Common Factors
Architecture Frameworks

Models and Zachman, DODAF, MODAF, AUSDAF and TOGAF Gordian
knot.
Business, Systems, Services and Technology

Whiteboards, A3 sheets, Office, Visio, JPGs, System Architect, etc.




Complex System Architect’s basic tool sets
Useful approaches to understanding Complex Systems.
Useful approaches to Architecting Systems in a complex
environment.
Complex I.T. systems
 What is a complex IT system?




More than three subsystems..
Multiple business process engagement
Significant data exchanges
Significant human interactions within the
systems
 How do you recognise this?
 Different governance regimes evident
 High frequency of change
 Multiple data exchange methods
 Complexity behaviours
An Alternate View of Complexity

What is a complex IT system?

A complex system is one that exhibits emergent behaviour.

Emergent Behaviour is behaviour that was not predicted from
the sum of the functions of the parts.

For example, the World Wide Web is a “small-world network”.
Ie, the number of hops between two nodes increases in
proportion to the log of the number of nodes. That was not
“designed-in” or predicted by the designers.

Emergent behaviour is often negative. We call this “bugs”.

So, system collections are complex when they start exhibiting
bugs that are the result of interactions between the systems.
These can be very difficult to diagnose.
Dept of Defence
Dept of Defence
(same information)
Defence – ERP Interfaces
Interfaces – How Many Are There?
2N > N(N-1)
How can that be?
For N systems, the worst case is N(N-1)
What we would like is at most, 2N
We can evolve a complex set of systems
towards 2N by applying enterprise
architecture patterns like SOA.
Systems of Systems
 Complex systems are typically system
of systems
 Multiple layers of systems
 Architects are often tasked with only
a subset of this – Focus
Common Factors
 Teaming is a necessity
 No single source of truth
 Fragmentation of design, projects and
support
 Documentation is always poor
 Abstraction is essential
 Architects become valued as
complexity increases
Complex Systems are influenced by
many factors
e.g. Defence Warehouse
Mobile Environment
Architecture Frameworks
 Framework v’s Architectural process
 TOGAF
 ZACHMAN
 DODAF, MODAF and AUSTDAF
 “Common language” for architects
 Rarely exactly accurate
 Most can be correlate to each other
Zachman (Circa 1990)
TOGAF
(Open Systems Group)
DODAF V2
MODAF
AUSDAF
Basic tool sets for complex system
architect’s
 Whiteboarding
 Print copies, photos, coloured pens
 Integrated project teams, working groups,
team reviews
 A3 sketch pads
 MS Office, Adobe Acrobat
 Visio and JPGs
 System Architect & Enterprise Architect
 Above all, an inquisitive mind and some
affront to ask questions
External Imposed Policies &
controls
Technical and Threat Risk
Assessment
Assessment Processes
Risk Sources
Threat / Technical Risk Assessments (Aust / ISO Standards)
•Detailed Identified Risk Calculations
(Add/Remove Information where required along with Risk Forms. Comments can be made in any field to enhance or better explain the rating.)
Risk Calculation Form
Risk ID: R01
Threat
Loss of services due to loss of communications (Example
Only)
Threat sources
TS16, TS17, TS19, TS20, TS21
Asset(s) Affected
A1, A2, A6 A9, A30
Overview
(insert comments here)
The loss of the (System/Project Name) services due the
infrastructure and networking outside the control of
Defence being damaged or wrongly configured.
Likelihood of Occurrence
(insert historical supporting information here)
Possible
Consequence of Realisation
(insert any supporting consequential comments here)
Severe
Current Resultant Risk Exposure
(insert further specific comments here)
High
Treatment Option
(Accept, Reduce, Avoid, Share)
Reduce
Treatment Recommendation(s) / Plan(s)
TP01, TP02
New Likelihood of Occurrence
(insert supporting future outlook comments here)
Very Rare
New Consequence of Realisation
(insert comments that may support the lowering of consequence,
if justified)
Severe
New Resultant Risk Exposure
(insert any comments here such as countermeasure
accompanied by treatment plan allowing the previous rating to
be lowered)
Medium
Table R01 – Loss of services due to loss of communications
Useful approaches to
understanding Complex Systems


Start at the top - the Enterprise’s Business Objectives




Document visually and ask for comments
Identify the Executive’s direction of change
Document (or find) the objectives
Identify the Enterprise “modus operandi”

How should the business be working?
Develop (or find) an outline Concept of Operations (or Concept of Business)







How is it actually working?

Strategic, Tactical and Immediate objectives



Look for historic and previous efforts
Ask for the war stories, but don’t accept as gospel
Where have the greatest changes occurred so far in the Enterprise? Why?

Small investments - large impacts

Enterprises take time to change

But it doesn’t hurt to bring some skills to bear.

Who reads the Plumbing Specs for a new Building?

Always ask - WHY is it so?”
Lean from those who have gone before
Look for “change levers”
Be patient
Both human and external factors rarely allow for “Engineering Discipline”
Draw and Write for your audience
Prof Julius Somner-Miller (circa 1970s)
Time for Questions
And thanks for listening…