1. Architecting in a Complex System Environment John Hodgson & Phil Piper ICT Architects April 2013

2. 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). A Systems of Systems view Common Factors Value and issues in identifying, analysing, designing and specifying IT systems in a complex environment. Architecture Frameworks Models and Zachman, DODAF, MODAF, AUSDAF and TOGAF Gordian knot. Business, Systems, Services and Technology Complex System Architects basic tool sets Whiteboards, A3 sheets, Office, Visio, JPGs, System Architect, etc. Useful approaches to understanding Complex Systems. Useful approaches to Architecting Systems in a complex environment.

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

4. An Alternate View of Complexity What is a complex IT system? A complex system is one that exhibits emergent behaviour. 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 often 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.

5. Dept of Defence

6. Dept of Defence (same information)

7. Defence – ERP Interfaces

8. Interfaces – How Many Are There? 2N is preferred to 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.

10. 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 Solution vs System vs Enterprise Architects

11. 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 must be multi-disciplinary I.T. Architects become valued as complexity increases

12. Complex Systems are influenced by many factors Examples New Defence Warehouses Expanding Mobile Environment New Services structures Aging Application infrastructures Changing Business Models Changing partner requirements Increasing efficiency demands

13. JSF – A study in complexity

14. JSF – Understanding how your element fits in

15. Architecture Frameworks Framework vs Architectural process TOGAF (I.T.methodology) ZACHMAN (ZF) DODAF, MODAF and AUSTDAF (Defence-focus) http://www.iso-architecture.org/ieee- 1471/afs/frameworks-table.html Common languages for architects Rarely exactly accurate Some are primarily processes, rather than a framework Most frameworks have a logical flow (process) to them Most can be correlate to each other

16. Zachman (Circa 1990)

17. TOGAF (Open Systems Group)

18. DODAF V2

19. MODAF

20. AUSDAF

21. Basic tool sets for complex system architects Whiteboarding Print copies, photos, coloured pens Integrated project teams, working groups, team reviews MS SharePoint folders 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

22. External Imposed Policies & Controls

23. Technical and Threat Risk Assessment Assessment ProcessesRisk Sources

24. 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 FormRisk ID: R01 Threat Loss of services due to loss of communications (Example Only) Threat sourcesTS16, TS17, TS19, TS20, TS21 Asset(s) AffectedA1, 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 Threat / Technical Risk Assessments (Aust / ISO Standards)

25. Useful approaches to understanding Complex Systems Start at the top - the Enterprises Business Objectives Document visually and ask for comments Identify the Executives direction of change Document (or find) the objectives Identify the Enterprise modus operandi Develop (or find) an outline Concept of Operations (or Concept of Business) How should the business be working? How is it actually working? Strategic, Tactical and Immediate objectives Lean from those who have gone before Look for historic and previous efforts Ask for the war stories, but dont accept as gospel Where have the greatest changes occurred so far in the Enterprise? Why? Look for change levers Small investments - large impacts Be patient Enterprises take time to change Both human and external factors rarely allow for Engineering Discipline But it doesnt hurt to bring some skills to bear. Draw and Write for your audience Who reads the Plumbing Specs for a new Building? Prof Julius Somner-Miller (circa 1970s TV Science Show) Always ask - WHY is it so?

26. Time for Questions And thanks for listening…