A deck of slides used for a condensed course on public sector architecture taught to LegalTech students at the University of Tartu.

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

15. system thinking basics

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

22. discussion
What is architecture?
21

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