E-government architecture
Download as PPTX, PDF4 likes11,483 views
This document discusses architectures for e-government systems that effectively connect primary registers containing citizen data. It analyzes past failed attempts in Bulgaria called ESOED and RegiX, which used enterprise service bus (ESB) approaches. The document argues decentralized peer-to-peer (P2P) architectures like Estonia's X-Road protocol are better. X-Road uses security servers instead of a centralized ESB, supports subscription-based data exchange, and has enabled over 200 registers and 900 institutions to securely exchange 600 million transactions annually. The document concludes e-government systems should use standard protocols and components to access register data as a service, with an emphasis on simple, decentralized designs.
E-government architecture
- 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. E-government We have e-government when the state does not waste citizens’ time.
- 4. Complex problem? • 20% technical • 20% legal • 60% organizational
- 5. Primary registers • Register = database • Primary - source of truth • Population register, document register, commercial register, NGO register, vehicle register, property register, land register.
- 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. “Once only” • 2 laws forbid the administration to collect data from citizens that the state already has • Automatic collection from primary registers instead
- 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. 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. Microservices? • Similar • … but they aren’t “micro” • .... and they aren’t within a single organization
- 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. Meanwhile in Estonia... • X-Road functions since 2001 • Connected registers: 200+ • Institutions: 900+ • Transactions: 600 million / year • Saved man-hours annually: 47 million
- 13. Technological drawbacks are not the reason for the failures.
- 14. Fundamental question Documents, data, or services?
- 15. • “Electronic document” • Wrapper of data? • Internal administrative service for serving documents/data • Main difference: • Document exchange vs. data exchange
- 16. Architectural question ESB or P2P?
- 17. Източник: МТИТС
- 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. Източник: МТИТС
- 20. ESOED - how? • Entering all schemas into a register (manually) • SOAP requests with destinationURI • Async response • Encryption, signing
- 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. 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. 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. X-Road • p2p • Security server (proxy) + adapter server - integration components • Security server instead of a centralized ESB
- 25. X-Road
- 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. 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. UK: Registers • One software for all registers • Multi-tenant deployment • RESTful integration
- 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?
- 31. Data, in addition to services • Granularity: data • Standard protocol for automatic handling of the schemas of data • Request: type/version/identifier
- 33. 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
- 34. Privacy • Access control • Event log • Access for citizens • + notifications for reading their data • Legal consequences for improper reading of data
- 35. 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
- 36. KISS • With a minimal set of components • With minimal human interaction • Complexity kills
- 37. Complex problem? • No • Architecture can be simple • Organizational and human factor - complicated
- 38. Thank you!