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

Slides:



Advertisements
Similar presentations
European e-Competence Framework Company Network Seminar EMCC - Cedefop, 9th November 2006 Jutta Breyer, Germany, Kibnet / AITTS European e-Competence Framework.
Advertisements

NAVIGATING THE SERVICE STRATUM Every organization has a stratus or layers of abstraction. They should work seamlessly and should complement one another.
ARCHITECTURE FRAMEWORKS IN COMPLEX ENVIRONMENTS SIMPLIFYING THE MYSTERY OF I.T. SYSTEMS IN SMALL AND LARGE ENTERPRISES JOHN HODGSON, I.T. ARCHITECT.
Appendix H: Risk training slides (sample). What is Risk? “ Risk is the effect of uncertainty on objectives ” AS/NZS ISO31000:2009.
Applying the Human Views for MODAF to the conception of energy-saving work solutions Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf.
Human Views for MODAF Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf of the Human Factors Integration Defence Technology Centre.
2009 – E. Félix Security DSL Toward model-based security engineering: developing a security analysis DSML Véronique Normand, Edith Félix, Thales Research.
PROJECT RISK MANAGEMENT
Business Architecture
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Information Resources Management January 23, 2001.
© 2012 Autodesk BIM Collaboration Siva Koppula Technical Consultant.
© 2011 IBM Corporation GBS – Business Analytics & Optimisation Experiences from using Blueprint Director in a Data Warehouse project Mattias Jönsson, Enterprise.
Systems Engineering in a System of Systems Context
Business Process Orchestration
PURPOSE OF DFMEA (DESIGN FAILURE MODE EFFECTS ANALYSIS)
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Team Skill 6 - Building The Right System Part 1: Applying Use Cases (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
Evolving Architecture “CASE STUDY: Architecture in Statistics NZ” Presented by: Rosemary McGrath Application Architecture Manager Statistics New Zealand.
CPM -200: Principles of Schedule Management IPM 2002 Fall Conference PMI-College of Performance Management – Professional Education.
Chapter 9 Architecture Alignment. 9 – Architecture Alignment 9.1 Introduction 9.2 The GRAAL Alignment Framework  System Aspects  The Aggregation.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Information Security Governance 25 th June 2007 Gordon Micallef Vice President – ISACA MALTA CHAPTER.
Enterprise Systems & Architectures. Enterprise systems are mainly composed of information systems. Business process management mainly deals with information.
SEC835 Database and Web application security Information Security Architecture.
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Margaret J. Cox King’s College London
1 Systems Analysis and Design in a Changing World, Fourth Edition.
Chapter 8 Architecture Analysis. 8 – Architecture Analysis 8.1 Analysis Techniques 8.2 Quantitative Analysis  Performance Views  Performance.
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
ArchiMate Authors : eSchoolink Group - ITNLU. Contents 1. What’s ArchiMate ? 2. Why ArchiMate ? 3. Main Benefits of ArchiMate 4. Layers of ArchiMate 5.
Information Assurance The Coordinated Approach To Improving Enterprise Data Quality.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Enterprise Reporting Solution
Intelligent Paper Pens and Ink. Background Despite the wide-ranging recognition that paper remains a pervasive resource for human conduct and collaboration,
Chapter 12 Project Risk Management
Architecting in a Complex System Environment John Hodgson & Phil Piper ICT Architects.
CRESCENDO CRESCENDO Philippe HOMSI Paul WEBSTER
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
The Real Deal With SIM/SEM The Promise of Security Information / Event Management Scott Sidel Sr. Security Manager Computer Sciences Corp.
WEP Presentation for non-IT Steps and roles in software development 2. Skills developed in 1 st year 3. What can do a student in 1 st internship.
Overview What do we mean by a Learning Organisation? Why did we develop a People Development Framework? What was the process involved in building the.
1 Microsoft Project Solution Offerings and the next chapter of EPM September 17th, 2003 Brendan Giles, PMP Systemgroup Management Services.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
SoftwareServant Pty Ltd 2009 SoftwareServant ® Using the Specification-Only Method.
John D. McGregor Architecture Evaluation
IB Business & Management
Castlebridge associates | | Castlebridge changing how people think about information How to Implement the.
 Has computer technology knowledge and programming expertise  Understands business problems  Uses logical methods for solving problems  Has fundamental.
Software Architecture Architecture represents different things from use cases –Use cases deal primarily with functional properties –Architecture deals.
Chapter 7 Lecture 1 Design and Implementation. Design and implementation Software design and implementation is the stage in the software engineering process.
Project Management Enabling Quality Marien de Wilde, PMP April 2007.
6/13/2015 Visit the Sponsor tables to enter their end of day raffles. Turn in your completed Event Evaluation form at the end of the day in the Registration.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
The heart of health and safety. Meaning business: The key elements for a compelling business case and annual report Liz Skelton Principal Consultant System.
JMFIP Financial Management Conference
Configuration Management
What is Enterprise Architecture?
Zachman Framework Lecture 2.
EI Architecture Overview/Current Assessment/Technical Architecture
Recent trends in estimation methodologies
COMP3357 Managing Cyber Risk
Yr 10 Candle Holder.
2018 Real Cisco Dumps IT-Dumps
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 27 Security Engineering
Systems Architecture & Design Lecture 3 Architecture Frameworks
Systems Architecture & Design Lecture 1 Introduction
Team Skill 6 - Building The Right System Part 1: Applying Use Cases
Presentation transcript:

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

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.

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

Dept of Defence

Dept of Defence (same information)

Defence – ERP Interfaces

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.

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

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

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

JSF – A study in complexity

JSF – Understanding how your element fits in

Architecture Frameworks Framework vs Architectural process TOGAF (I.T.methodology) ZACHMAN (ZF) DODAF, MODAF and AUSTDAF (Defence-focus) /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

Zachman (Circa 1990)

TOGAF (Open Systems Group)

DODAF V2

MODAF

AUSDAF

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

External Imposed Policies & Controls

Technical and Threat Risk Assessment Assessment ProcessesRisk Sources

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)

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?

Time for Questions And thanks for listening…