The document discusses system architecture in the context of public service. It defines system architecture as the combination of form and function, with an architect determining how profitable a system is. A state is viewed as a system that provides public services using taxes. Key challenges in architecting a state include defining boundaries and the functional structure. The public sector has peculiarities like defining profit differently and having rigid legislation forming "silos". Estonia chose a service-oriented architecture for its dispersed decision-making and convergence of IT and business. Architects must ensure interfaces fit across layers of an organization and within the entire state system. The scope of an architect's work includes balancing the ability to change some elements versus living with others.

1. www.ria.ee
System architecture in
public service context
Architecting a country
Andres Kütt
andres.kutt@ria.ee

2. www.ria.ee
Agenda
• What is system architecture?
• What is a country?
• Managing system architecture at public sector
• Service oriented public sector architecture

3. www.ria.ee
!
!
On system architecture
!
!
!

4. www.ria.ee
Classically defined as an
arrangement of things
“The structure, arrangements or configuration of
system elements and their internal
relationships necessary to satisfy constraints
and requirements.” (Frey)
There are other definitions of architecture but this one is both common and typical in a way it emphasizes the focus on physical
structure of things. This sort of view is certainly useful for example when we want to quantify or understand the complexity (in
terms of the number of elements, element types and their relationships) of something but leaves a lot to be desired when talking
about designing systems.

5. www.ria.ee
Can also be defined as a
combination of form and function
“The embodiment of concept, and the allocation
of physical/informational function to elements
of form, and definition of interfaces among the
elements and with the surrounding
context” (Crawley)
In a nutshell, architecture consists function related by concept to form. This idea is much better and clearer explained in ESD.34
System Architecture class notes by Ed Crawley (available at MIT OCW http://ocw.mit.edu/courses/engineering-systems-division/
esd-34-system-architecture-january-iap-2007/lecture-notes/lec1.pdf)

6. www.ria.ee
Properties of that definition
• Embodies both form (cost) and function (value)
• Allowes for abstract concepts to be reflected via
system concept
• Depends on what we take as the value process
• Is not limited to information systems
This definition leads to a lot of interesting venues of thought.
Firstly, it embodies both form and function as equal elements. Since form is where the cost of a system comes from and function
drives the value (and thus revenue), this definition puts an architect in a key position in terms of the business model of an
organization. An architect determines, how profitable a product or a service is. Therefore, an architect must be able to both
understand and convey business-related ideas as well as technical ones.
!
Secondly, there is a fairly abstract idea of a “concept” embedded in the definition allowing to express much more complex
notions than a definition purely rooted in the mechanics of things fitting together. A function of a piston is to transfer energy
released by the chemical reaction. But it can also be uased to perform a function of a table leg or a winners trophy. The function
of energy transfer can also be provided by a triangular rotor. Only within the concept of an otto (as opposed to wankel) engine
do the particular form and function come together.
!
Thirdly, the definition allows the architecture to depend on what the ultimate goal (or the value driving process) of the system is.
The functional, conceptual and physical makeup of a racecar is rather different from a family carrier. This difference would be
difficult to convey in other settings and gives the architecture a clear focus.
!
Finally, this definition is by no means limited to information systems. It can be applied to the areas of civic, electric and chemical
engineering but also more complex things like universities.

7. www.ria.ee
!
!
What is a state?
!
!
!

8. www.ria.ee
A state is a system
This is an engineers view
!
A state is a system that serves its citizens by
providing public services using taxes
All models are wrong but some models are useful. This applies to mental models as well as scetched ones. So, from the
engineers point of view, a state can be seen as a system the design of which fundamentally follows the same principles as the
design of a pencil or a space station. As we shall see, this raises some interesting questions about states.

9. www.ria.ee
Important questions to ponder:
• What are the boundaries of the state?
• What is the detailed functional structure of a
state?
• What are the elements of form of a state?
• How do you even architect a state?
These questions can not necessarily be answered in a satisfactory manner and certainly the answers differ between states.
However, the process of thinking about them is likely to yield important insights into the fundamental structures of something
that is taken for granted in the western world.
!
Perhaps the most important one is the question of boundaries as answers to the others depend on it significantly. In the spirit of
System Dynamics (in singular, not prular), the MIT school of architecture argues that any system boundaries are fundamentally
artificial. Consider the complex helmets of fighter pilots relaying a constant stream of audiovisual information. These helmets
depend on the physiology of the pilots head and the behavior of its senses to perform their primary function of making sure
critical decisions get made in a timely manner. Thus, the pilot is clearly part of the aircraft system. The latest meal of the pilot
might is likely to have his or her body chemistry enough to alter reaction times and sensory ability. Therefore, the meal seems to
be part of the system as well. Along the same line of thinking we arrive at the conclusion that everything is interconnected. But,
alas, we cannot comprehend the entire observable universe, therefore some decision needs to be made about what the scope of
our study is. So where does a state begin and where does it end?

10. www.ria.ee
!
!
System architecture in
public sector
!
!
!

11. www.ria.ee
Peculiarities of public sector
• Profit and loss are defined differently
• Silos are enforced by rigid legislation
• Very thin top-level infrastructure

12. www.ria.ee
All money must be spent
In a business, money left in the budget is profit
!
In a state money left in the budget means the
public has received less service than it has
already paid for
For a business any money not spent is usually considered positive as, assuming the revenue targets have been reached, it adds
to the bottom line. For a state, however, the sole reason it collects money from the citizens is so that the public can get some
service for it. Therefore, any money unspent in the budget means that taxes have been collected unnecessarily.
!
This difference between public and private sector has profound implications on the way architecture should be approached in
respective fields. For example, since there is little focus on operational cost of systems (remember, there is nothing to be gained
by driving opexp down), relatively little focus usually goes towards optimizing the system performance. Which often leads to
underperformance and low response times.
!
This difference combined with the fact that there is no direct benefit to be gained from the citizens also leads to very different
power dynamics between operational and development branches of the IT, different emphasis points during the tender process,
etc. In short, this difference alone means that while the methods of obtaining a solution can be transferred from private to public
sector, most solutions can not.

13. www.ria.ee
Silos are made of concrete
Every agency, ministry and, in fact, official has
their function prescribed to them as part of a
legal, often legislative, process
!
Breaking down silos means changing legislation
In private sector, breaking down silos is one of the more crucial tasks of an enterprise architect as vertically integrated business
stacks drive down efficiency and hinder integration. There are several ways of achieving this but in the end it comes down to a
manager at some level making decisions.
!
In public sector, this is much different. Every unit of organization, sometimes down to the individual level, has a very clear
mandate stemming from the fact that they are given public money to provide a very specific service. That mandate is usually
written down in a way that is rather hard to change, in some cases to the constitution of the country. In such a situation it is
extremely hard to persuade somebody to reach a hand and do more (or less) than is specified for the particular silo. It is not that
people do not want to cooperate, often they are legally not allowed to.

14. www.ria.ee
There is little corporate
governance
In corporations, the reporting lines might converge to
allow rather elaborate corporate governance
mechanisms
!
In a democratic state, such mechanisms are much
more harder to build
In case of advanced democracy, the governance system is set up to minimize the chances of a single individual gainid
disproportionate amounts of influence. Therefore, by definition, there is no signle person or organizational unit where to escalate
issues or that could act as an arbiter in case of disputes.
!
In Estonia, the architectural oversight is executed by the State Information System Agency belonging to the area of Ministry of
Economy and Communication.

15. www.ria.ee
Inflicting change is very
different
Methods used in private sector seldom work
!
Much depends on ones ability to find and execute
levers that do
Because public sector is rather peculiar (and these are just general ones, countries can differ remarkably) when compared to
private sector, the ways of inflicting change differ significantly.
!
For example, as opposed to private sector, one can actually make laws and basically have somebody go to jail if they do not
follow the architecture guidelines. But this only happens when the legislative body OKs the legislation and getting a law through
the machinery takes usually a long time. Also, actually acting upon it is difficult as architectural concepts can be vague and hard
to define.
!

16. www.ria.ee
!
!
Service oriented public
sector architecture
!
!
!

17. www.ria.ee
Choosing a software
architecture for Estonia
What follows are some of the reasons we chose
the model we chose
!
Really an emergent concept rather
than a formal decision

18. www.ria.ee
Substantiated push towards
service orientation
Basically, Janek is running around telling people to
start thinking in terms of services
!
It really is a difficult mindshift
Choices on the technical level can not oppose such trends and should preferably take advantage of them.

19. www.ria.ee
Disperesed decision processes
The way decision-making processes are set up in
Estonia is very distributed
!
Applies to legislative process as well as cultural
inclinations towards consensus-building
Therefore, a centralized architecture is pretty much out of question and parties should be given the ability to make their own
decisions to a rather large extent.

20. www.ria.ee
Strong IT-business convergence
IT is not something that sits separately in a cellar
somewhere but is truly embedded into the
business operations
!
Usually a tighter cooperation than client-server
Therefore technical decisions are driven by the business partners and will thus be hard to centralize and coordinate. I.e. if there is
anybody able to influence the inner workings of an information system, it is the business partners

21. www.ria.ee
Service oriented architecture
fits the bill
The system consists of black boxes that provide
services in a standardized manner
!
What goes on within the box matters very little
Service oriented architecture, or SOA, seems to be a good fit under these conditions. In this context SOA just means “an
architecture that consists of black boxes offering a standardized interface for others boxes to use” and so there is no need to dig
into the pile of controversy that surrounds the general SOA meme.

22. www.ria.ee
Architectural model of a corporation
Organization
Business architecture
Organizational architecture
Functional architecture
Technical architecture
Infrastructure architecture
In our further discussion, this model of enterprise architecture is used. Several other architecture frameworks including TOGAF
contain similar ideas. The layers can be described as follows
• Business architecture defines the business model and strategy of the organization
• Organizational architecture covers organizational structure and business processes but also organizational culture that is used
to execute on the business architecture
• Functional architecture descibes the functional elements supporting these business processes. Data flows between the units,
semantics and data architecture are also covered
• Technical architecture covers the technical components implementing the functionality and the exact means data is exchanged
• Infrastructure architecture describes the underlying technical infrastructure (like data centers, networks etc.) of the enterprise
!
This model can be applied on both country and individual organization level. In the former case, the layers are made up of the
individual layer fragments for each organization

23. www.ria.ee
SOA model of a corporation
Organization
Organization
Business architecture
Business architecture
Organizational architecture
Organizational architecture
Functional architecture
Functional architecture
Technical architecture
Technical architecture
Infrastructure architecture
Infrastructure architecture
Organization
Organization
Business architecture
Business architecture
Organizational architecture
Organizational architecture
Functional architecture
Functional architecture
Technical architecture
Technical architecture
Infrastructure architecture
Infrastructure architecture
Combinging the SOA architecture and the layered model we get a group of individually layered boxes communicating with each
other.

24. www.ria.ee
Clearly defined interfaces
on all layers
Every organization needs to provide clean
interfaces to other parts of the state on all
levels of the architecture
In this particular model every individual organization provides interfaces to other elements of the state (elements of form,
according to the architecture model described earlier).
!
It is important to understand that it is really not possible to interface only on one of the layers. When two organizations talk to
each other, they almost inevitably interact on all layers. Lets discuss a simple case of opening one registry for queries. It is
implemented like so:
• There must be some joint infrastructure so the request can be executed. It might be pure open internet but not necessarily so
• There must be some technical capabilities in terms of some components exchanging information with each other
• There must be a joint understanding (and ways of reporting changes) of the semantics of the data exchanged and its functional
nature (how fresh it is, for example)
• There must be a process interaction, at the very least monitoring processes of the two organization must echange information
on the availability of the client and the server
• Finally, there must be some business alignment so one organization is actually willing to expose an interface and provide
!
access to potentially sensitive data

25. www.ria.ee
The layers must fit
The structure of the layers needs to fit within
organizations as well as in the entire state
The layers must be structured in a way that does not create conflicts, otherwise effects quite similar to tectonic tension arise. For
example, if there is a joint element of infrastructure (a data center) without proper integration on the upper layers, two
organizations will be responsible for the same physical cooling space and inevitably issues of cost splitting, security domains etc.
arise. Also, when there is a single functional unit that is supported by two distinct technical implementations, sooner or later
issues of data consistency and maintenance costs arise.

26. www.ria.ee
Scope of work for an architect
How far up the stack can I inflict change?
!
What do I need to change and what
do I need to live with?
In the layered model (and especially in the state-level view) a question of scope arises. Yes, the layers must fit but what if they do
not? What if a change on lower layers is needed that needs to inflict a change on the upper ones? This creates an
insurmountable hurdle for the architect responsible for the lower layers (the architects on the top usually have the power
advantage and can inflict change downwards) as he or she must either find a way to make changes in the upper layers or live
with their imperfections.

27. www.ria.ee
An architects prayer
“Please give me strength to change the things I
can change and leave the things I can not
change alone.
Also give me wizdom to distinguish between the
two”

28. www.ria.ee
!
!
Thank you!
!
!
!
andres.kutt@ria.ee