System thinking in public sector architecture
7 likes1,985 views
The document provides an introduction to system architecture, emphasizing the importance of understanding systems' entities and their relationships to address global challenges. It discusses conventional assumptions about organizations, the emergence of complexity, and the need for effective architecture to generate value in public sector systems. The presentation aims to equip participants with a framework for analyzing systems and recognizing the challenges faced in designing architecture that meets stakeholder needs.
System thinking in public sector architecture
- 1. system architecture A (hopefully) gentle introduction Andres Kütt February 25, 2016 Riigi Infosüsteemi Amet
- 2. introduction
- 3. agenda today ∙ Intro. Importance of the topic. Global challenges. Conventional assumptions ∙ System thinking. Concept of value ∙ Form, Function, Concept intro. Examples ∙ Identify the entities of the system and their function ∙ Exercise: Form, function and concept of a country ∙ Relationships among entities. Feedback, emergence ∙ Introduction to complexity ∙ System thinking and architecture in public sector ∙ Role of a software architect 2
- 4. andres kütt ∙ Building software for living since 1993 ∙ In architect-like roles for the past 10 years ∙ ≈MSc (UT, Statistika), MBA (EBS), MSc (MIT) ∙ Currently architect of Estonian Information System ∙ Skype, Hansapank, EMTA etc. in the past ∙ Some teaching experience 3
- 5. structure of today ∙ Two main sections ∙ Fundamentals of system architecture ∙ Theoretical foundations of public sector architecture ∙ Nine 30-minute blocks of study punctuated by two breaks ∙ Each block but one contains ∙ 20 minutes of slides, ∙ 5 minutes of paired discussion ∙ 5 minutes of common discussion ∙ The questions on paired discussion form the basis of grading ∙ The 5th block is different consisting of a team exercise followed by discussion 4
- 6. the contents ∙ The theory is mainly based on Crawley et al. (2015) and various lectures by prof. Crawley ∙ The goal is to talk about architecture in general not software architecture in particular ∙ Have patience: it is really hard to that much into 4.5 hours without your heads exploding. Certain things will not make immediate sense 5
- 7. fundamentals of system architecture
- 8. Architecture is an abstract description of the entities of a system and the relationships between those entities. It can be seen as a set of decisions. Crawley et al. (2015) 7
- 9. properties of architecture ∙ Architecture can either emerge from a development process or be explicit ∙ Everything has an architecture ∙ Explicit architecture provides more (but not ultimate) control ∙ It is about decision quality under the conditions of ambiguity ∙ Small improvements here can lead to a lot of benefit down the line ∙ In software, architecture is an outcome of a continuous process not a one-time activity ∙ Design decisions need to be made constantly as the systems evolve 8
- 10. benefits of good architecture What do we generally want from a system? ∙ Meet shareholder needs ∙ Deliver value ∙ Integrate easily ∙ Evolve flexibly ∙ Operate simply and reliably Explicitly developed architecture allows us to have a measure of control over all this 9
- 11. conventional assumptions about organisations ∙ They are culturally, technically etc. homogenous ∙ “You and your architecutre can get stuffed, I know better what works locally” (a random person from Montevideo) ∙ Organisational and legal borders are clearly defined ∙ Tightly integrated supply chains ∙ Global organisations partnering with each other largely ignoring states ∙ Relative independence from global challenges ∙ Many things need to be resolved within next decades. You are either part of the solution or you are part of the problem ∙ Controlled and contained IT ∙ Specialised hw/software package operated by highly trained employees vs. general purpose soft- and hardware all over the place 10
- 12. the challenge As the assumptions no longer hold, we are faced with: ∙ Higher complexity both within the organisation and globally ∙ Higher levels of upstream uncertainty ∙ No way to separate IT from the rest of the organisation without loss of fidelity We need to figure out a better way to provide the benefits of good architecture 11
- 13. This is not about architecture astronautics What we discuss today is to be applied to make better stuff every single day 12
- 14. discussion What do you want to get out of today? 13
- 16. A system is a set of entities and their relationships, whose functionality is greater than the sum of the individual entities Crawley et al. (2015) 15
- 17. system thinking definition System thinking is not about thinking systematically ∙ It is about thinking about a question, circumstance, or problem explicitly as a system ∙ Observe, how we make no assumptions about the nature of the entities ∙ Emergence of new functions is a key part of the definition. This is what allows systems to generate value ∙ System thinking is a way of thinking ∙ Therefore, it is not a science or a theory ∙ It is a mental model ∙ All models are wrong but some models are useful (Box, 1976) ∙ It should be used alongside with other modes of thinking and logical reasoning 16
- 18. examples of systems ∙ Sand and a funnel combined yield the function of timekeeping ∙ Neither the funnel alone nor sand can do that ∙ But also, a function of triggering a trap can emerge ∙ A particular group of people combined can yield the function of winning football matches ∙ In addition to function, performance emerges ∙ Performance is an attribute of the emergent function ∙ A set of mechanical and chemical components can be combined to result in a car ∙ A group of “-ilities” - reliability, operability, respectability etc. - emerges ∙ Safety is one of these ∙ Note that in this model, usability is an emergent property of the system 17
- 19. emergence of emergencies Not all emergency is desirable ∙ In December of 1984, 40 tons of methyl isocyanate was released to atmosphere at a chemical plant in Bhopal, India ∙ Worst industrial accident in history ∙ 2 000 fatalities, 200 000 injuries, 10 000 permanent disabilities (Leveson, 2011, conservative estimates) ∙ A bona fide systemic failure ∙ Unclear job descriptions ∙ Inadequately planned safety measures ∙ Human error ∙ Business error in decreasing safety to save cost ∙ The same principle applies to information securty ∙ Security is an emergent behavior of a system ∙ Cannot thus be fully predicted, only designed for 18
- 20. emergence and value How exactly do systems generate value? ∙ This is how the work of an architect is justified ∙ A well-architected system might generate more value ∙ Benefit stems from ∙ The system performing the intended function with intended performance ∙ All the ilities being there ∙ Lack of emergencies ∙ Basically, the emergence happening in a desired way ∙ The concept of benefit implies existence of a user, as benefit is always relative ∙ Value is defined as benefit at cost ∙ All artificially constructed systems incur a cost 19
- 21. key questions of systems thinking These questions should be asked when thinking about a system 1. What is the system made of? ∙ Again transcending discipline boundaries 2. What is the particular mental model of the system? ∙ Remember the one about all models being wrong? ∙ Many are applicable, which one is the most useful at the moment? 3. Where are the system boundaries? ∙ Everything is interconnected, where do we draw the line? 4. What is the system context? ∙ What interfaces do we need to keep in mind? 20
- 23. answering question 1: what is the system made of? ∙ This is where you define subject of your architecture ∙ Do we get hardware involved? ∙ How about people? (NB! people are hard) ∙ There is no such thing as a green field, you are always working with an existing system ∙ At the very least the users are there ∙ It is also beneficial to re-visit this question as the system evolves 22
- 24. the steps Steps to answering “what the system is made of?”: 1. Identify form and function 2. Identify entities of the system and their form and function 3. Identify the relationships 4. Predict emergence 23
- 25. step 1. identify form and function ∙ Form is what the system is ∙ form is stable over a period of time ∙ form is the part of the system that is made or assembled ∙ Function is what the system does ∙ function is what causes performance and ilities ∙ this is why the system exists or is employed ∙ emergence occurs in the function domain ∙ function consists of a process and an operand: something (operand) changes state as the system does something (process) 24
- 26. examples of form and function ∙ An amplifier ∙ form is the wires, transistors and resistors ∙ functions is amplification (process) of a signal (operand) ∙ Circulatory system ∙ form is heart, lungs, capillaries ∙ function is transporting (process) oxygen (operand) ∙ Project team ∙ form is the team members ∙ function is delivering (process) result (operand) 25
- 27. form and function. observations ∙ Both can only be expressed via an abstract model ∙ Software, as opposed to physical things, cannot be experienced directly ∙ It is thus vital the abstract model is as useful and unambiguous as possible ∙ The same function can be performed by several sets of form elements and vice versa ∙ Therefore we need a third notion, the concept, creating a one-to-one mapping ∙ These mappings are not equivalent ∙ I am yet to see a useful representation of this relating functional and form models 26
- 28. form and function. more observations ∙ It is much more difficult to do for some systems than for others ∙ Physical things are much easier than abstract concepts like software ∙ Form of an ice sculpture. Is oxygen in the water part of the form? ∙ What is the Internet actually made of? ∙ There is a tendency to get carried away with form ∙ Where does the system end? ∙ Is IETF part of the Internet? What about sysadmins of the core DNS boxes? ∙ In the universe, everything is interconnected 27
- 29. discussion Where does concept of a system come from? 28
- 30. the steps Steps to answering “what the system is made of?”: 1. Identify form and function 2. Identify entities of the system and their form and function 3. Identify the relationships 4. Predict emergence 29
- 31. step 2. identify the entities of the system and their function What is the structure of form and function of our system? 1. Include everything you feel is important 2. Throw out everything that turns out not to be 3. See what can be generalised and clumped together 4. Define boundaries and interfaces 5. Repeat unless the result is both useful and manageable The basic algorithm: Keep adding and removing things until you like the result 30
- 32. on adding and removing things Think holistically ∙ Add people, technology, hardware, software, everything important-looking ∙ Be aware of unknown-unknowns: things you do not know you do not know. ∙ For software folks this is often people ∙ For legal folks, this is often anything related to real life Focus ∙ The 7 ± 2 rule. There is a limit to human cognition (Miller, 1956) ∙ ”Is the entity important in determining the outcome and the emergence that I am interested in?” 31
- 33. two key types of clumping Abstraction Replace instances with class. “Employee” instead of Alice, Bob and Charlie Modularisation What things relate to each other more than to others? ∙ Footnote: there are great tools for doing that algorithmically. See Browning (2001) 32
- 34. guidelines for creating abstractions and modules ∙ Conceal the unimportant and expose the important ∙ On system level, exact class structure might not be relevant but the interface probably is ∙ Make sure appropriate relationships are retained ∙ Team members might cooperate a lot even if teams themselves do not ∙ Create abstractions at the right level of decomposition or aggregation ∙ “Screw” is a pretty useless abstraction ∙ Simplify, until you notice loss of fidelity, and no further ∙ “Software running on hardware being used by a user” is a valid but not useful model 33
- 35. define system boundaries God, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference ∙ Choose system boundary in a way that is useful ∙ By defining system boundaries, you define interfaces: the relationships crossing the system boundary ∙ Cleary differentiate between ∙ Things you can change ∙ Things that make up a system ∙ These two very seldom overlap ∙ Ignore the big picture and get a useless system ∙ Try to change the big picture and get a bloody nose 34
- 36. stop condition All steps alter the results of previous steps, so there’s a cycle. When do you stop? ∙ Do all entities contribute to the function and emergence you are interested in? ∙ Is there an element of form contributing to each function? ∙ Can you explain the system on a single sheet of paper? ∙ Is the result useful? 35
- 37. discussion What if the resulting system is too complex? 36
- 38. exercise: form function and concept of a country ∙ Go through first two steps of system analysis for a country of your choosing ∙ Identify form and function ∙ Identify entities of the system and their form and function ∙ Present the results 37
- 39. the steps Steps to answering “what the system is made of?”: 1. Identify form and function 2. Identify entities of the system and their form and function 3. Identify the relationships 4. Predict emergence 38
- 40. step 3. relationships among entities Functional relationships do something, they are dynamic in nature ∙ operands are exchanged or acted upon ∙ sometimes called interactions ∙ a heart exchanges blood with a lung Formal relationships are relationships that exist, they are static ∙ these relationships exist stably for some period of time ∙ usually a connection or a geometric relationship ∙ a class is within a package ∙ sometimes called structure Typically, (but much less in software), a formal relationship is required for a functional relationship 39
- 41. representing relationships The same system represented in two ways: A standard UML component diagram A DSM (see Browning (2001) for details) 40
- 42. step 4. emergence Emergence is why we study systems in the first place ∙ Firmly in the functional domain, form leads to function that leads to emergence ∙ It is about how the elements are put together ∙ The elements themselves are important but architecture leads to emergence ∙ Cannot be fully predicted or controlled by definition ∙ Information/Cyber security and safety are emergent properties of a system ∙ Understanding how emergence works is thus crucial ∙ Since emergence stems from architecture, so do security and safety 41
- 43. predicting emergence This is the crux of system thinking Precedent We have experience and thus know, what shall happen Experiment We can build an experiment to see, what shall happen Model We can build a model to simulate, what shall happen ∙ Many modern systems are new, too large to do experiments for and too complex to model ∙ These we can reason about using system thinking or other frameworks 42
- 44. discussion Can we talk about emergence in legal systems? 43
- 45. defining complexity There are many definitions, Mitchell (2009) brings examples. Complexity as … ∙ …size. Function of the number of elements and their relationships ∙ …(Shannon) entropy. Information content of the system ∙ …algorithmic information content. Compressability ∙ …logical or thermodynamic depth. The cost of construction ∙ …relationship between input and output. Predictability ∙ …fractal dimension 44
- 46. more about complexity ∙ Complexity is an emergent property of a system and therefore a general concept ∙ The arithmetical definition yields most practical tools ∙ Counting things is easy ∙ Limited in usefulness because of its static nature ∙ Complexity vs. complicatedness ∙ Complicatedness is the extent to which a system appears complex ∙ Static vs. dynamic complexity ∙ Dynamic complexity is the ability of a system to exhibit complex behaviour over time ∙ Static complexity stems from formal relationships, dynamic complexity from functional ones 45
- 47. exponential nature of complexity Complexity # of elements / time Limit of abilities Complexity seems to have a tendency to increase exponentially 46
- 48. implications of this This is why complexity needs to be actively managed. There are three basic strategies Flatten the curve Working on the system should add the least amount of complexity possible. Engineering. Stop moving Stop adding features, growing the org. etc. This is what eventually happens. Management. Raise the capabilities Increase the ability of an organisation to cope. Dynamic capabilities. 47
- 49. discussion How to assess complexity of a set of laws? 48
- 50. foundations of public sector architecture
- 51. know and respect your context ∙ Understand dependencies between layers ∙ Know your limits (i.e. define boundaries carefully) ∙ Learn to accept what you cannot change ∙ Maintain alignment between layers ∙ Build horizontal and vertical relationships ∙ Ponder the source and impact of changes Concept Functions Peopleware Software Infrastructure 50
- 52. on legal issues ∙ In public setting, the top layers a held together by a legal framework, usually subject to democratic process ∙ The bottom layers are held together by open source and the internet ∙ The former is local, the latter is global ∙ This creates a barrier to change OSS&InternetLegalframework Concept Functions Peopleware Software Infrastructure 51
- 53. peculiarities of public sector ∙ There is no profit ∙ Taxes are collected to provide public services ∙ If these are not spent, the customer is not getting their moneys worth ∙ Therefore, there is no intrinsic efficiency pressure ∙ You can’t risk to break the law ∙ In private sector, you can accept any risk ∙ In public sector, one cannot accept the risk of breaking the law ∙ At least this is my understanding as an engineer ∙ E.g. you can’t put encrypted personal data of citizens to a public cloud as breaking the crypto in the future is a real risk that would lead to exposing personal data 52
- 54. discussion How to express legal architecture? 53
- 55. role of a software architect in government setting ∙ Manage, control and own complexity ∙ Prevent lock-in ∙ Build bridges ∙ Predict emergence 54
- 56. manage, control and own complexity ∙ Do not forget complicatedness! ∙ Everybody else is interested in more of it ∙ Bureaucrats do not mind complex processes seeking to control reality ∙ Engineers love to engineer ∙ Project managers have deadlines and budgets ∙ Entropy tends to increase ∙ Complexity has the property of being complex ∙ Once the threshold is breached, backing down might be impossible ∙ But it would be considered the job of an architect ∙ Thus, constant effort is required to keep system complexity manageable ∙ Complexity needs to be represented at decisions ∙ Governments love waterfall but less and less problems are simple enough to be solved using it ∙ Legal, business and organisational design decisions are good examples 55
- 57. prevent lock-in ∙ In private sector, IP governance can prevent lock-in ∙ In public sector, there is no concept of IP and thus lock-in can happen more easily ∙ How lock-in occurs ∙ Vendor develop architecture embedding their concept in the process ∙ Every new vendor has to learn and adapt to the the mental models of the original vendors, which is costly ∙ Architect can actively drive concept development ∙ Now all vendors have the same barrier of entry ∙ And therefore an incentive to dethrone the architect 56
- 58. build bridges From sufficiently high up, most fights look ridiculous ∙ Systems thinking leads to the need to span disciplines ∙ PMs, developers, the customer, end users, accounting etc. all focus on their job ∙ Architect is often the only one seeing the big picture ∙ Establish reasonable communication lines between disconnected teams (Hickey, 2015) ∙ Architect should have very few vested interests thus being the ideal middleman ∙ Very few other roles are in a position to argue for global optimums 57
- 59. predict emergence Architect should have a holistic view and thus the singular ability to predict emergence ∙ Opportunities ∙ What other functions could a system perform? ∙ What new functions can appear with additional effort? ∙ Is the emergent function worth the added complexity? ∙ Close cooperation with the policy folks a must ∙ Threats ∙ What could go wrong? ∙ Much more frequent ∙ It takes a huge amount of skill not to appear as a buzzkill ∙ Close cooperation with cybersec people a must 58
- 60. discussion Given the general nature of architect’s value, do we need architects in other fields? 59
- 61. bibliography
- 62. George E. P. Box. Science and statistics. Journal of the American Statistical Association, 71(356):791–799, 1976. Tyson R Browning. Applying the design structure matrix to system decomposition and integration problems: a review and new directions. Engineering Management, IEEE Transactions on, 48(3): 292–306, 2001. Edward Crawley, Bruce Cameron, and Daniel Selva. Systems Architecture: Strategy and Product Development for Complex Systems. Prentice Hall, 2015. Kevin Hickey. The Role of an Enterprise Architect in a Lean Enterprise http://martinfowler.com/articles/ea-in-lean-enterprise.html, November 2015. Nancy Leveson. Engineering a safer world: Systems thinking applied to safety. MIT Press, 2011. 61
- 63. George A Miller. The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychological review, 63(2):81, 1956. Melanie Mitchell. Complexity: A guided tour. Oxford University Press, 2009. 62
- 64. license
- 65. theme Get the source of this theme and the demo presentation from http://github.com/matze/mtheme The theme itself is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. cba 64
- 66. contents The contents of the slides is lidecensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International cbna 65
- 67. Questions? 66