Estonia is one of few countries having fully embraced e-government. This slide deck, intended to be presented as a lecture at Tallinn Technical University, gives guidelines to building e-services in Estonian context and provides foundations to e-government in general
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.
∙ 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
∙ Skype, banks, public sector + some
consulting in the past
∙ 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
foundations of e-government
The following points must not be violated when building an
∙ Simply because they form the foundation of the entire country
∙ But also because doing so will make building the service very
trust between parties
An externally guaranteed trust framework between citizens,
businesses and the government is a prerequisite of e-government
∙ 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
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 sufﬁcient
∙ Digital signature requires a PKI-based solution
∙ Ubiquity stems from people using various e-services on a daily
basis and realising their beneﬁt. It is needed so that
∙ electronic service can become dominant
∙ the users are acquainted with the risks involved
∙ the users actually ﬁnd it convenient to use it
The players must have the ability and capability to change their
operating model with reasonable effort
∙ By deﬁnition: 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 sufﬁcient deterrent
∙ This is mental to a large extent: what do people have to loose?
∙ A certain level of chaos is needed for progress
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
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
∙ inﬂicting change
∙ Whenever possible, assemble larger systems from clearly
encapsulated smaller ones
Collaboration between engineers and decision-makers is crucial
∙ No sane ofﬁcial goes ”let’s integrate all information systems using
∙ Engineers like to build, ofﬁcials 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
Can Estonian levels of trust be built elsewhere?
architecture of estonia
Agency Agency AgencyAgency
Information System Registry
∙ Implemented using PKI, CA service provided externally
∙ The certiﬁcates 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
∙ Central service portal eesti.ee with 800+ services accessible
∙ Main challenge: maintaining service ownership
∙ No central UI/UX guidelines although a recommended web site
∙ Hundreds of individual contact points
∙ Mobile is very small
∙ 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
∙ 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
How to make the agencies cooperate with each other?
The main point of democracy is preventing concentration of power
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
In private sector, budget surplus means proﬁt.
In public sector, budget surplus means taxes collected in vain
CERT-EE Part of
RISO Part of
architecture of estonia
Agency Agency AgencyAgency
Information System Registry
∙ The carrot part of moving a donkey
∙ Used to support policies and architectural decisions including
∙ Drives desirable behaviours like service management
∙ Covers SF and parts of central budget
∙ Gives input to architecture development by initiating projects and
∙ Can be used to drive reduction of technical debt
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
RIHA is a central repository of information on information systems of
∙ 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
not pictured: eu
EU is becoming increasingly active in the electronic services ﬁeld
∙ Large number of policies being developed require input and
∙ 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
How can anything get done in this context?
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
∙ 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 sufﬁciently so
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.
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
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
Can there be privacy on the internet?
All services exist in an ecosystem of people and organisations
pursuing ever greater value gained per unit of effort spent
Where does your data come from and where does it go?
∙ What is the source of your data? Answer to this question answers
∙ 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?
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?
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 ﬂexibility is severely limited
∙ Money is seldom a leverage
∙ Some of the stakeholders can have massive inﬂuence on you
mapping the ecosystem
Mapping your ecosystem in ﬁve 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
∙ 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.
Where does an ecosystem end?
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
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, notiﬁcation 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
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 sufﬁcient reason
∙ A legal requirement is a much better one but not always sufﬁcient (!)
∙ 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 ﬁve years
∙ We do not have the data
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
Minimal latency of any government agency is 9 months:
nothing happens unless it is on the Work Plan
and there is budget for it
How to make another agency see the big picture?
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
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-deﬁned 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 signiﬁcant IP is going to be created
∙ The people executing the procurement and designing the service
must cooperate tightly
Make sure you understand the ﬁnancing 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
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?
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 speciﬁcation enough, usually additional input
from the beneﬁciary 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
What are the key success factors of successful public sector
Get the source of this theme and the demo presentation from
The theme itself is licensed under a Creative Commons
Attribution-ShareAlike 4.0 International License.
The contents of the slides is lidecensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International