The Role of the Architect in a Turbulent World

Transcription

1 Abstract by Gerrit Muller University of South-Eastern Norway-NISE The role of the in today s is discussed. There is a need for systems that improve security, safety, and that provide threat analysis and prevention, and intelligence. These systems are build in an era full of technological opportunities; from biometrics to intelligent vision/analysis et cetera. However we are faced with many challenges: how to cope with huge amounts of information, how to cope with or how to prevent false positives and false negatives. At the same time system builders have to deal with complicating factors: human factor, many open systems in stead of a few closed systems, and the dynamics of the environment (politics, terrorists, nature,...). What is the role of the, how to cope with the challenges and complications, what methods and tools are available? Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: preliminary draft pirates narcotics smugglers illegal immigrants terrorists cyber crime large scale fraud security and safety technological problems and needs options fast evolving human context heterogeneous (natural) disasters stakeholders users complex systems of systems buyers security and suppliers... safety legislation

2 The Architect in a Turbulent World narcotics smugglers security and safety problems and needs human context pirates illegal immigrants terrorists cyber crime technological options complex systems of systems security and safety large scale fraud fast evolving heterogeneous (natural) disasters stakeholders users buyers suppliers... legislation 2 Gerrit Muller RATWoverview

3 Structure of this Presentation exploring turbulence 1 3 problem technology know how fit technological options to problem context from problem to solution product creation process 2 4 role and profile of the in a 3 Gerrit Muller RATWcontent

4 Exploring Turbulence exploring turbulence 1 3 problem technology know how fit technological options to problem context from problem to solution product creation process 2 4 role and profile of the in a 4 Gerrit Muller RATWcontentTurbulence

5 Sources of Turbulence: Mega Events politics/religion nature 9/11 Madrid London cartoon crisis animal liberation SARS H5N1 bird flu Al Quaida Mexican immigrants Tsunami Xmas 2004 earthquake Pakistan 2005 latin American narcotics maffia crime Enron Parmalat Malacca Strait pirates Carribean narco smugglers Nick Leeson Barings Bank Nigerian e-fishing ice rink collapse roof collapses Moscow Seoul department store collapse Rita storm New Orleans flooding Airbus crash Habsheim technology 5 Gerrit Muller RATWmegaEvents

6 Most Stakeholders Strive for Certainty dealing with uncertainty inventors entrepeneurs pull towards certainty managers quality purchasers assurance employees general public government 6 Gerrit Muller RATWstakeholdersCertainty

7 Contradiction: Humans as Champions of Adaptability Homo Sapiens thousands of years of adaptation sea, desert, polar, mountain, dehydration, flood, fire, famine, war, plague, diseases technological systems hundreds of years of dedication 7 Gerrit Muller RATWhumanVsMachine

8 From Problem to Solution; Product Creation Process exploring turbulence 1 3 problem technology know how fit technological options to problem context 2 from problem to solution product creation process 4 role and profile of the in a 8 Gerrit Muller RATWcontentPCP

9 Product Creation: Phasing of Process Steps policy requirements design integrate test policy requirements and specification design integrate test -1 strategy 0. feasibility 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring 6. product operational lifecycle 9 Gerrit Muller RATWsystemActivities

10 The CAFCR model drives, justifies, needs enables, supports What does Customer need in Product and Why? Customer What Customer How Product What Product How Customer objectives Application Functional Conceptual Realization 10 Gerrit Muller CAFCRannotated

11 Security as example through all views Customer objectives sensitive information trusted not trusted Application selection classification people information authentication badges passwords locks / walls guards administrators social contacts missing open passwords functionality blackmail wrong burglary quantification fraud unworkable procedures Functional Conceptual Realization functions for administration authentication intrusion detection logging quantification cryptography firewall security zones authentication registry logging holes between concepts specific algorithms interfaces libraries servers storage protocols desired characteristics, specifications & mechanisms threats bugs buffer overflow non encrypted storage poor exception handling 11 Gerrit Muller QNsecurityExample

12 Connecting Problem Space and Solution Space Customer objectives sensitive information trusted not trusted Application selection classification people information authentication badges passwords context understanding insight locks / walls guards administrators social contacts missing open passwords functionality blackmail wrong burglary quantification fraud unworkable procedures Functional Conceptual Realisation functions for administration right authentication decisions quantification right questions cryptography firewall security zones authentication registry logging holes between concepts specific algorithms interfaces libraries servers storage protocols process and design competence bugs buffer overflow non encrypted storage poor exception handling 12 Gerrit Muller QNsecurityExampleAnnotated

13 Example Questions Customer objectives Application Functional Conceptual Realisation Will biometrics improve authentication? Is encryption guaranteeing information security? What are the implementation related security hazards? What are the process assumptions? Does the technological solution fit in the human mindset? 13 Gerrit Muller RATWsecurityQuestions

14 Fit Technological Options to Problem Context exploring turbulence 1 3 problem technology know how fit technological options to problem context from problem to solution product creation process 2 4 role and profile of the in a 14 Gerrit Muller RATWcontentDepth

15 What is Architecture? Understanding Why Describing What Guiding How Do the right things Do the things right 15 Gerrit Muller LWAwhatIsArchitecture

16 Guiding How by providing rules for: 1. Functional Decomposition acquisition compress encoding display decompress decoding storage Pipeline 3. Allocation 2. Construction Decomposition view play browse audio video TXT tuner drivers scheduler OS Performance MPEG etc. DS P networking CPU Resource usage RAM 4. Infrastructure framebuffer filesystem etc Exception handling Device abstraction 5. Choice of integrating concepts 16 Gerrit Muller LWAureHow

17 The Art of Architecting Anno 1990 Stakeholders Expectations Facts Architecture(s) problems, legacy analyze assess balance trade-off decide Architecting vision overview insight understanding Architecture uncertainties unknowns Facts, Expectations and Intuition may be false Integration requires a critical mindset that is alert for unknowns Architect(s) Intuition, assumptions, beliefs, bias 17 Gerrit Muller LWAing

18 The Art of Architecting Anno 2006 change turbulence Stakeholders Expectations Facts Architecture(s) Note: Facts, Expectations and Intuition might be false or out of date or fluctuating analyze assess balance trade-off decide Architecting vision overview insight understanding Architect(s) Intuition Architecture does it fit and satisfy today's and tomorrow's situation? 18 Gerrit Muller RATWing

19 Architecting is much more than Decomposition Decomposition is "easy" Integration is difficult 19 Gerrit Muller LWAdecompositionAndIntegration

20 Architecting: Preparing for Integration Decomposition is "easy" Decomposition becomes minor part future extension Integration is much more difficult future extension 20 Gerrit Muller RATWdecompositionAndIntegration

21 Technical Decisions Require Detailed Know How system requirements design decisions parts system 10 7 connections monodisciplinary multidisciplinary 10 8 number of details lines of code and growing every year Gerrit Muller RATWpyramid

22 Role and Profile of the Architect in a Turbulent World exploring turbulence 1 3 problem technology know how fit technological options to problem context from problem to solution product creation process 2 4 role and profile of the in a 22 Gerrit Muller RATWcontentArchitect

23 Organizational Problem: Disconnect What does Customer need in Product and Why? Customer objectives Application Functional Conceptual Realisation gap system requirements design decisions How can the product be realized What are the critical decisions parts connections lines of code and growing every year Gerrit Muller RATWdisconnect

24 Architect: Connecting Problem and Technical Solution What does Customer need in Product and Why? How can the product be realized What are the critical decisions Customer objectives Application Functional Conceptual Realisation number of details system requirements design decisions parts connections lines of code and growing every year Gerrit Muller RATWbreadthAndDepth

25 Major Bottleneck: Mental Dynamic Range number of details stretch engineer stretch senior engineer system stretch Gerrit Muller RATWmentalDynamicRange

26 Opposing, but Complementary Skills and Cultures based on: "Some Future Trends and Implications for Systems and Software Engineering Processes" by Barry Boehm, Systems Engineering, Spring 2006 agility people thriving on chaos?? plan-oriented people thriving on order system s: create some order in chaos but fear dogmatic use of procedures and policies system engineers: create reliable, reproducable, maintainable, manageable systems introducing procedures and policies 26 Gerrit Muller RATWchaosVsOrder

27 System Roles: Company Culture Dependent system high level of uncertainty system designer system engineer system manager system tester need for certainty -1 strategy 0. feasibility 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring 6. product operational lifecycle 27 Gerrit Muller RATWsystemRoles

28 Recommendation 1: Team Work 1 team mutual respect complementary few many agility people thriving on chaos plan-oriented people thriving on order 28 Gerrit Muller RATWteamwork

29 Recommendation 2: Symbiose via Workshops workshop(s) management stakeholders agility people plan-oriented people early in the project shared problem understanding shared solution exploration 29 Gerrit Muller RATWworkshop