Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building government e-services in Estonia


Published on

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

Published in: Government & Nonprofit
  • Login to see the comments

Building government e-services in Estonia

  1. 1. building gov-e-services in estonia IDU0450 Andres Kütt February 25, 2015 Chief Architect, Information System Authority
  2. 2. introduction
  3. 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. 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. 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. 6. foundations of e-government
  7. 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. 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. 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. 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. 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. 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. 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. 14. discussion point Can Estonian levels of trust be built elsewhere? 13
  15. 15. estonian e-government architecture
  16. 16. architecture of estonia Agency Agency AgencyAgency Electronic identity Citizens/Officials/Enterprises Delivery channels Integration Infrastructure Financeandportfoliomanagement Informationsecurity Information System Registry 15
  17. 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. 18. channels ∙ Central service portal 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. 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. 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. 21. discussion point How to make the agencies cooperate with each other? 20
  22. 22. organisational infrastructure for e-services
  23. 23. The main point of democracy is preventing concentration of power 22
  24. 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. 25. In private sector, budget surplus means profit. In public sector, budget surplus means taxes collected in vain 24
  26. 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. 27. architecture of estonia Agency Agency AgencyAgency Electronic identity Citizens/Officials/Enterprises Delivery channels Integration Infrastructure Financeandportfoliomanagement Informationsecurity Information System Registry 26
  28. 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. 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. 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. 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. 32. discussion point How can anything get done in this context? 31
  33. 33. information security concerns
  34. 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. 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. 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. 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. 38. discussion point Can there be privacy on the internet? 37
  39. 39. understanding the ecosystem
  40. 40. All services exist in an ecosystem of people and organisations pursuing ever greater value gained per unit of effort spent 39
  41. 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. 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. 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. 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. 45. discussion point Where does an ecosystem end? 44
  46. 46. joining an ecosystem
  47. 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. 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. 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. 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. 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. 52. discussion point How to make another agency see the big picture? 51
  53. 53. development and procurement
  54. 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. 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. 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. 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. 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. 59. discussion point What are the key success factors of successful public sector procurement? 58
  60. 60. license
  61. 61. theme 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. cba 60
  62. 62. contents The contents of the slides is lidecensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International cbna 61
  63. 63. Questions? 62