E-government architecture

E-government architecture

Bozhidar Bozhanov

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

E-government

We have e-government when the state does

not waste citizens’ time.

Complex problem?

• 20% technical

• 20% legal

• 60% organizational

Primary registers

• Register = database

• Primary - source of truth

• Population register, document register,

commercial register, NGO register, vehicle

register, property register, land register.

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

“Once only”

• 2 laws forbid the administration to collect

data from citizens that the state already

has

• Automatic collection from primary registers

instead

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

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

Microservices?

• Similar

• … but they aren’t “micro”

• .... and they aren’t within a single

organization

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

Meanwhile in Estonia...

• X-Road functions since 2001

• Connected registers: 200+

• Institutions: 900+

• Transactions: 600 million / year

• Saved man-hours annually: 47 million

Technological drawbacks are not the reason for

the failures.

Fundamental question

Documents, data, or services?

• “Electronic document”

• Wrapper of data?

• Internal administrative service for serving

documents/data

• Main difference:• Document exchange vs. data exchange

Architectural question

ESB or P2P?

Източник: МТИТС

ESOED

• ESB/Message Queue

• Works entirely with electronic documents

• Checks and routes documents

• Complex integration• Lack of accessible libraries

• Council for registration

• VPN?

Източник: МТИТС

ESOED - how?

• Entering all schemas into a register

(manually)

• SOAP requests with destinationURI

• Async response

• Encryption, signing

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

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

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*

X-Road

• p2p

• Security server (proxy) + adapter server -

integration components

• Security server instead of a centralized

ESB

X-Road

X-Road - how?

• Communication: only with a security server

• Security servers take of logging and

authentication

• Security servers are proxies

• Local cache

• Load balancing

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

UK: Registers

• One software for all registers

• Multi-tenant deployment

• RESTful integration

Security server?

• Additional servers complicate the

infrastructure

• Instead of servers - standard components

• Price?

• Instead of certified security servers -

transaction coordinator?• Single point of failure?

Data, in addition to services

• Granularity: data

• Standard protocol for automatic handling of

the schemas of data

• Request: type/version/identifier

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

Privacy

• Access control

• Event log

• Access for citizens• + notifications for reading their data

• Legal consequences for improper reading

of data

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

KISS

• With a minimal set of components

• With minimal human interaction

• Complexity kills

Complex problem?

• No

• Architecture can be simple

• Organizational and human factor -

complicated

Thank you!