This document provides an overview of building e-government services in Estonia. It discusses the foundations of Estonia's e-government, including establishing trust between parties, requiring ubiquitous electronic identification, and allowing flexibility for change. It also describes Estonia's e-government architecture, including its use of electronic identity, delivery channels, integration platform, and infrastructure. Additionally, it addresses organizational infrastructure and governance for e-services, as well as information security concerns. Finally, it discusses understanding the ecosystem of stakeholders involved and how to join that ecosystem when developing new services.

1. building gov-e-services in estonia
IDU0450
Andres Kütt
February 25, 2015
Chief Architect, Information System Authority

2. introduction

3. structure of today
∙ Six ≈ 30 minutes sections, punctuated by your chance to talk
∙ This thing depends on your contribution!
∙ Respect the time of others
I might have information.
But I do not have the answers, only more questions.
2

4. andres kütt
∙ Building software for money since 1993
∙ Been an architect for the past ≈ 10 years
∙ ≈MSc (UT, Statistika), MBA (EBS), MSc (MIT)
∙ Currently architect of Estonian
information system
∙ Skype, banks, public sector + some
consulting in the past
3

5. today
∙ Introduction
∙ Foundations of e-government
∙ Estonian e-government architecture
∙ Organisational infrastructure for e-services
∙ Information security concerns
∙ Understanding the ecosystem
∙ Joining the ecosystem
∙ Development and procurement
4

6. foundations of e-government

7. foundations of e-government
The following points must not be violated when building an
e-government service
∙ Simply because they form the foundation of the entire country
∙ But also because doing so will make building the service very
complex
6

8. trust between parties
An externally guaranteed trust framework between citizens,
businesses and the government is a prerequisite of e-government
services.
∙ Information systems involved are too complex to comprehend,
thus the need for explicit trust
∙ There has to be an external (e.g. cryptographic) guarantee to the
trust keeping it from gradual deterioration
∙ Only wealthy countries can afford not to have that trust: IRS lost
$5.2 billion to identity theft in 2013. Translated via GDP this would
mean e6 million annual loss in Estonia.
∙ Among other things this assumes no party (e.g. media) is actively
trying to disrupt that trust
7

9. ubiquitous electronic identification
On the internet, nobody knows you are a dog
∙ The assurance level of services provided is dependent on the
assurance level of the electronic ID
∙ The British way can only go so far
∙ For simple cases e-mail is sufficient
∙ Digital signature requires a PKI-based solution
∙ Ubiquity stems from people using various e-services on a daily
basis and realising their benefit. It is needed so that
∙ electronic service can become dominant
∙ the users are acquainted with the risks involved
∙ the users actually find it convenient to use it
8

10. ”breathing room”
The players must have the ability and capability to change their
operating model with reasonable effort
∙ By definition: if everything is in place, any change would go
against the well-established rules
∙ Stability means things happening tomorrow the way they happen today
∙ Innovation means the exact opposite
∙ Many of the decisions underpinning our e-government would be
impossible to execute in a well-controlled environment
∙ Risk management processes alone would be a sufficient deterrent
∙ This is mental to a large extent: what do people have to loose?
∙ A certain level of chaos is needed for progress
9

11. critical levels of critical competences
Without the following competences, it is not feasible to build an
e-government as they are neigh to impossible to outsource
∙ Ability to procure development
∙ Basically, one must be able to act as a responsible customer
∙ Vendor management is big part of it
∙ Ability to provide input and validate the output
∙ Ability to procure operations
∙ Operating the service means controlling the data, this is important!
∙ Weak operations lead to low service levels and loss of trust
∙ Information/cyber security
∙ Who will work out your electronic identity scheme?
∙ Whose cryptography do you trust (and can you make your own)?
∙ How do you protect your service?
To sustain the e-government, the ability to absorb IP is needed
10

12. relatively small scope
Too big things get too complex too rapidly
∙ Complexity increases exponentially as elements are added
∙ When we double the size, complexity gets squared (roughly)
∙ The ability to develop e-services is depends on system complexity
∙ Larger countries have more people, agencies, processes etc., thus
the following gets much more complex
∙ integrating the systems
∙ getting approvals
∙ inflicting change
∙ Whenever possible, assemble larger systems from clearly
encapsulated smaller ones
11

13. collaboration
Collaboration between engineers and decision-makers is crucial
∙ No sane official goes ”let’s integrate all information systems using
XML-based messaging”
∙ Engineers like to build, officials like to sustain
∙ Building things requires at least
∙ thorough understanding of the business
∙ legal support and understanding of the legal system
∙ ability to work with the democratic process
∙ Therefore, collaboration between parties is an absolute must
12

14. discussion point
Can Estonian levels of trust be built elsewhere?
13

15. estonian e-government architecture

16. architecture of estonia
Agency Agency AgencyAgency
Electronic identity
Citizens/Officials/Enterprises
Delivery channels
Integration
Infrastructure
Financeandportfoliomanagement
Informationsecurity
Information System Registry
15

17. electronic identity
∙ Implemented using PKI, CA service provided externally
∙ The certificates live on a chip (smart card or SIM)
∙ Digital signature legally equivalent to the physical one
∙ Millions of signature and authentication events annually
∙ Depends on the personal id-code of the citizen
16

18. channels
∙ Central service portal eesti.ee with 800+ services accessible
∙ Main challenge: maintaining service ownership
∙ No central UI/UX guidelines although a recommended web site
template exists
∙ Hundreds of individual contact points
∙ Mobile is very small
17

19. integration
∙ Distributed service bus called x-road
∙ All communication happens peer to peer
∙ x-road provides standardised
∙ channel crypto
∙ access control
∙ service discovery
∙ audit logging
∙ identity management
∙ protocol support
∙ Massive deployment, 1000+ usable services
∙ Constantly developed, version 6 getting ready to roll
∙ De facto enables once-only and privacy
18

20. infrastructure
∙ Being expanded rapidly, currently only network
∙ Government cloud is a combination of
∙ private cloud
∙ public cloud
∙ data embassies
∙ Security and service availability major drivers: we no longer can
run this country without e-services
∙ Scalability and cost are also becoming an issue
19

21. discussion point
How to make the agencies cooperate with each other?
20

22. organisational infrastructure for e-services

23. The main point of democracy is preventing concentration of power
22

24. problems in architecting a country
How to govern software architecture in a democratic country?
∙ Democracy rules out authoritative approach
∙ The solution depends heavily on context
∙ National culture
∙ Structure of a country: municipalities, type of federation etc.
∙ Nature of the architecture layers
Anybody seeking to build e-services (or do architecture) in public
sector must be able to rely on their soft power
23

25. In private sector, budget surplus means profit.
In public sector, budget surplus means taxes collected in vain
24

26. architecture governance
EIFITL Founded
Andmevara
Member of
Ministry of
Interior
Owns
Cybernetica
Member of
SMIT
Governed
by
Ministry of
Finance
RMIT
Governed
by
Ministry of
Justice
RIK
Governed
by
KEMIT
Ministry of
Environment
Governed
by
RIA
Supplies
software to
ASO
Ministry of
Education
HITSA
Founded
EEnet
Is part
of
Part of
Cooperates
CERT-EE Part of
GOV-CERT
Part of
MoEA
Governed by
RIKS
Founded
Informatics
Counsel
Gathers
RISO Part of
ITAO
Part of
25

27. architecture of estonia
Agency Agency AgencyAgency
Electronic identity
Citizens/Officials/Enterprises
Delivery channels
Integration
Infrastructure
Financeandportfoliomanagement
Informationsecurity
Information System Registry
26

28. funding
∙ The carrot part of moving a donkey
∙ Used to support policies and architectural decisions including
information security
∙ Drives desirable behaviours like service management
∙ Covers SF and parts of central budget
∙ Gives input to architecture development by initiating projects and
funding change
∙ Can be used to drive reduction of technical debt
27

29. information security
Security is an emergent property of a system
∙ Cybersec deals with architectural mistakes of the past, security
cannot be bolted on
∙ Three main areas:
∙ Protection of information systems crucial for the country
∙ Protection of private data. Data is the new oil!
∙ Defense/security aspect of things
∙ Based on ISKE, a measure-based approach adapted from Germany
28

30. riha
RIHA is a central repository of information on information systems of
Estonian government
∙ Some policies rely on a central repository of metadata:
∙ Once Only Principle™
∙ Enforcement of x-road for information exchange
∙ But also funding decisions, open data initiatives etc.
∙ Currently relies on manual data entry but being moved to an open
data based approach
29

31. not pictured: eu
EU is becoming increasingly active in the electronic services field
∙ Large number of policies being developed require input and
produce pressure
∙ Our position is a massive challenge
∙ small size means many policies are too large
∙ advanced services mean increased chances of SEPA-like situations
∙ our mindset towards privacy, trust, service development etc. is very
different from most of Europe
∙ lack of people means driving topics is a disproportionate burden
30

32. discussion point
How can anything get done in this context?
31

33. information security concerns

34. what is information security?
Both safety and security are emergent properties of a system
∙ A system (not just software!) behaves safely or securely after it is
built. Therefore:
∙ System safety/security must be by design, it cannot be added later
∙ Safety and security cannot be fully predicted
∙ Safety and security are two aspects of the same thing
∙ Rapidly increasing system complexity a real factor here
All software is insecure until proven to be sufficiently so
33

35. safety by design: an example
Korea is about to replace all of their ID-codes
∙ Their system was designed to assume the id-code is secret
∙ Additional measures were designed to be weak for improved usability
∙ Short near-plain-text passwords stored on device (me rolls eyes)
∙ Over the years, ≈80% of the population had their ID-codes stolen
through various breaches
It is not about Korean infosec being bad, it is about their system
being designed to assume it to be impossibly good.
34

36. security of the cloud
Think very carefully about storing sensitive information in the cloud
∙ The cloud provider can and will use your data whichever way they
please. Read the EULAs
∙ Even if they don’t, you can’t tell should there be a breach
∙ Even if there is no breach, you are not alone in there
∙ Usefulness of encrypted data must degrade faster than security of
the encryption method used
You have no control whatsoever over who does what with your data
once it is stored in the cloud
35

37. on cyberwar
Very nasty business, getting nastier all the time
∙ Completely changes the way people can express their patriotism
∙ For years, there has been a black market of exploits, botnets,
electronic bounty and various related software
∙ Now governments are mixing in and the business is booming
∙ New threats require very different response methods
Technology is driving a rapid change in the nature of war
36

38. discussion point
Can there be privacy on the internet?
37

39. understanding the ecosystem

40. All services exist in an ecosystem of people and organisations
pursuing ever greater value gained per unit of effort spent
39

41. data flows
Where does your data come from and where does it go?
∙ What is the source of your data? Answer to this question answers
these others:
∙ Who do you depend on for your service?
∙ Who owns the data you use?
∙ Whom do you need to please for your service to prosper?
∙ How sensitive is the data?
∙ What is the destination of your data? Answer to this question
answers these others:
∙ Who depends on your service, i.e. who will be sad if your service dies?
∙ Who has the potential to leak your data?
∙ Who is willing to support your service?
40

42. system flows
Where does your system come from, where does it live and where
does it go in the end?
∙ What is the source of your system?
∙ Whose capabilities do you need to reckon with in system design?
∙ Who do you need to explain your design to?
∙ Where will the IP be created?
∙ Where does your system live?
∙ Who will need to live with whatever you design?
∙ Who will control your system?
∙ Who is responsible for operational security?
∙ Where does your system go?
∙ What are the archival requirements?
∙ What is the expected age of your system?
∙ Who will be responsible for migrating data out of your system?
41

43. multitude of stakeholders
The stakeholder situation is complex in public sector
∙ The number of stakeholders is larger, as there is more regulation
∙ Stakeholders are separated by higher organisational boundaries
∙ Stakeholder flexibility is severely limited
∙ Money is seldom a leverage
∙ Some of the stakeholders can have massive influence on you
personally
42

44. mapping the ecosystem
Mapping your ecosystem in five easy steps:
1. Draw a bubble for each stakeholder ignoring their classes
2. Starting from the one most interesting to use, ask for each pair of
stakeholders:
∙ What does stakeholder A get from stakeholder B?
∙ What does stakeholder B get from stakeholder A?
3. If A gets anything from B, we draw a line from B to A and annotate
4. Validate the picture by asking about each stakeholder: where do
they get whatever it is they are giving away?
5. Analyse the picture to detect feedback loops, ”gategeepers” etc.
43

45. discussion point
Where does an ecosystem end?
44

46. joining an ecosystem

47. understand the ecosystem
1. Map your ecosystem as described previously
2. Identify resources your service needs
∙ Identify existing services using RIHA
∙ Using RIHA, identify data elements not yet exposed as services
∙ Using system analysis, identify data elements you need, cannot collect
and that do not exist in any dataset
∙ Talk to people in the know
3. Negotiate with stakeholders
4. Change your service design and repeat
46

48. negotiating access
Access to existing services is technically trivial but might involve a
lot non-technical activities
∙ Make sure you have a legal basis for getting the data
∙ Understand the SLA1
of the service and compare it to yours
∙ If necessary, establish an explicit SLA stating contact persons, contact
procedure, notification rules etc.
∙ Understand the related infrastructure: test environments, test
users, monitoring hooks etc.
∙ Understand the data quality
∙ Get in touch with the service operator and request access to
service producing evidence you may actually have it
1Service Level Agreement
47

49. negotiating development
If a service is not there (or is not satisfactory) but the data is, the
other party must do work
∙ Prepare for a delay of at least 6 to 18 months
∙ In government, people need a good reason to do things
∙ Common good is usually not a sufficient reason
∙ A legal requirement is a much better one but not always sufficient (!)
∙ Personal contacts on a high level are most reliable
∙ You must have a very clear understanding of your needs
∙ Prepare to be countered:
∙ What is it exactly that you need?
∙ I cannot do this because it is illegalimmoraldubiousinconvenient
∙ It is prohibitively expensive
∙ It is going to take five years
∙ We do not have the data
48

50. negotiating business process
If the data is not there, a business process is needed to collect it
∙ Only do this if really desperate
∙ All data collection in Estonia must have a legal basis
∙ Some political mandate
∙ A law requiring collection of the data
∙ Agency statute permitting the collection
∙ Dataset statute describing the data collected
∙ RIHA documentation with technical detail
∙ The other agency must do a lot:
∙ Changes in their software
∙ X-road interface to make the new data available
∙ Business processes handling data collection data via all channels
∙ Handling of older registry entries without the data
49

51. Minimal latency of any government agency is 9 months:
nothing happens unless it is on the Work Plan
and there is budget for it
50

52. discussion point
How to make another agency see the big picture?
51

53. development and procurement

54. the operators
Never ignore people who need to live with whatever you build
∙ It is just a decent thing to do
∙ They are also in position to completely ruin your day
∙ It is a really bad sign when you do not know who these people are
∙ Make sure you understand the non-functional requirements
∙ NFR is a contract between developers, testers, security and operations
on what constitutes an ”OK” system
∙ Therefore it needs to be constructed in collaboration
∙ Never change the NFR for your project without consulting everybody
53

55. the procurement process
Procurement process is always heavily prescribed
∙ There are usually several process options to choose from
∙ Pick carefully the one most suitable to your situation based on
∙ How well-defined are your requirements
∙ How narrow is the bracket of technical competences necessary
∙ What is the operating model of the service going to be
∙ What amount of how significant IP is going to be created
∙ The people executing the procurement and designing the service
must cooperate tightly
54

56. financing
Make sure you understand the financing model very well
∙ Money usually comes with a catch. Find it.
∙ People giving you money will look closely at how you spend it
∙ Be ready to pay back every dime should you fail to walk the line
55

57. change perspective
Look at things from the tenderers perspective
∙ What information would you need to put in a reasonable offer?
∙ What might your interests be?
∙ What would cause them to join/leave the tender process?
56

58. play your part
It takes a surprising amount of effort to spend money
∙ The more money is to be spent, the more detailed the tender
paperwork needs to be
∙ All deliveries must be accepted
∙ Very seldom is the specification enough, usually additional input
from the beneficiary is necessary
∙ Operations support can be considerable for training, deployment
testing, environment setup etc.
∙ Training, data migration, marketing etc. also need resources
∙ Much of this applies to other stakeholders as well, engage the
ecosystem early
57

59. discussion point
What are the key success factors of successful public sector
procurement?
58

60. license

61. 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
60

62. contents
The contents of the slides is lidecensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International
cbna
61

63. Questions?
62