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.

E-government architecture

Software architecture for connecting registers for the purpose of implementing e-government.

  • Login to see the comments

E-government architecture

  1. 1. E-government architecture Bozhidar Bozhanov
  2. 2. Vanity slide • Still a developer • http://blog.bozho.net • http://techblog.bozho.net • http://twitter.com/bozhobg • E-government adviser to the deputy prime minister of Bulgaria
  3. 3. E-government We have e-government when the state does not waste citizens’ time.
  4. 4. Complex problem? • 20% technical • 20% legal • 60% organizational
  5. 5. Primary registers • Register = database • Primary - source of truth • Population register, document register, commercial register, NGO register, vehicle register, property register, land register.
  6. 6. Connecting the registers • The task • Legal - already done in the e-governance act • Technical - 2 solutions that haven’t worked • Organizational - the reason why the 2 solutions haven’t worked
  7. 7. “Once only” • 2 laws forbid the administration to collect data from citizens that the state already has • Automatic collection from primary registers instead
  8. 8. How? • Decentralized architecture • or distributed? • Addressing legal issues • “This does not concern us” • “We have a special law” • We need specific agreements • Organizational issues: carrot and stick
  9. 9. Requirements • Many participating organizations • including private sector • Personal data protection • 100% access accountability • Secure authentication of information systems • PKI, HSM • Sync, async and subscribe requests • Change management
  10. 10. Microservices? • Similar • … but they aren’t “micro” • .... and they aren’t within a single organization
  11. 11. History • “Administrative IS will talk to each other, finally” (TechNews, June 2006) • 1st attempt: ESOED • unsuccessful • 2nd attempt: RegiX • unused as of yet • “Interoperability framework” • a.k.a WSDL
  12. 12. Meanwhile in Estonia... • X-Road functions since 2001 • Connected registers: 200+ • Institutions: 900+ • Transactions: 600 million / year • Saved man-hours annually: 47 million
  13. 13. Technological drawbacks are not the reason for the failures.
  14. 14. Fundamental question Documents, data, or services?
  15. 15. • “Electronic document” • Wrapper of data? • Internal administrative service for serving documents/data • Main difference: • Document exchange vs. data exchange
  16. 16. Architectural question ESB or P2P?
  17. 17. Източник: МТИТС
  18. 18. ESOED • ESB/Message Queue • Works entirely with electronic documents • Checks and routes documents • Complex integration • Lack of accessible libraries • Council for registration • VPN?
  19. 19. Източник: МТИТС
  20. 20. ESOED - how? • Entering all schemas into a register (manually) • SOAP requests with destinationURI • Async response • Encryption, signing
  21. 21. RegiX • ESB (sort of) • Adapts legacy registers by exposing web services • Central component routes requests • Adding a register requires additions to the central component • Does not support Subscribe
  22. 22. RegiX - how? • SOAP request to the central component • with service identifier • with data about the requester • Central component forwards to the adapter. • Checks access • Logs the event (without the data) • The adapter gets the data from the database and responds
  23. 23. NoESB • ESBs are single point of failure • No matter how well “reserved” • Their magical powers are only on paper • Good interfaces and versioning them removes the need for an ESB*
  24. 24. X-Road • p2p • Security server (proxy) + adapter server - integration components • Security server instead of a centralized ESB
  25. 25. X-Road
  26. 26. X-Road - how? • Communication: only with a security server • Security servers take of logging and authentication • Security servers are proxies • Local cache • Load balancing
  27. 27. X-Road protocol • Standard protocol for adapter servers • SOAP • A list of available services and their definitions • Versions? • Every adapter server is entered into a register • Adapters are tightly integrated with the IS • And support subscribe
  28. 28. UK: Registers • One software for all registers • Multi-tenant deployment • RESTful integration
  29. 29. Security server? • Additional servers complicate the infrastructure • Instead of servers - standard components • Price? • Instead of certified security servers - transaction coordinator? • Single point of failure?
  30. 30. Data, in addition to services • Granularity: data • Standard protocol for automatic handling of the schemas of data • Request: type/version/identifier
  31. 31. Distributed architecture? • Storing data in a blockchain • Encrypted • ...with the personal key of each citizen • ...and with the key of the institution (in case the citizen loses theirs) • Estonia: health records
  32. 32. Privacy • Access control • Event log • Access for citizens • + notifications for reading their data • Legal consequences for improper reading of data
  33. 33. So... • Standard protocol • Standard SDKs and components • Implementing the protocol • Central registers with metadata • Access control, data types, list of registers • Access log • Documentation, sandbox
  34. 34. KISS • With a minimal set of components • With minimal human interaction • Complexity kills
  35. 35. Complex problem? • No • Architecture can be simple • Organizational and human factor - complicated
  36. 36. Thank you!

×