System architecture in public service context

www.ria.ee

Architecting a country

System architecture in public service context

Andres Kütt [email protected]

www.ria.eewww.ria.eewww.ria.eewww.ria.ee

Agenda

• What is system architecture? • What is a country? • Managing system architecture at public sector • Service oriented public sector architecture


!!

On system architecture !!!


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.


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)


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.


!!

What is a state? !!!


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.


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?


!!

System architecture in public sector

!!!


Peculiarities of public sector

• Profit and loss are defined differently • Silos are enforced by rigid legislation • Very thin top-level infrastructure


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.


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.


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.


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


!!

Service oriented public sector architecture

!!!


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


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.


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.


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


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.


Architectural model of a corporation

Business architecture

Organizational architecture

Functional architecture

Technical architecture

Infrastructure architecture

Organization

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


SOA model of a corporation

OrganizationBusiness architecture




















Combinging the SOA architecture and the layered model we get a group of individually layered boxes communicating with each other.


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 !


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.


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.


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”

www.ria.ee

!!

Thank you! !!!

[email protected]

Technology

System architecture in public service context