Proposal for an E-Government Architecture

January 5, 2015

Having worked for a project that was part of the Bulgarian e-government in the past, I have a good overview of what and how can and should be implemented in order for the administration of a country to function without paper.

That said, I fully acknowledge the fact that the challenges for digitlizing the administration, and in that sense the “government” or in fact the whole country, are only 10% technological and 90% social, legal and administrative. And although I have some knowledge of the legal framework(s) and of administrative processes, I’m not an expert, so I won’t comment on that.

But I am a software engineering expert, so here is my proposal for solving the 10% of the problem. It is a 10-page architectural overview, with some implementation details included, specifying broadly the way systems in the government should be implemented and connected to each other.

The purpose of all that is to make communication between different branches of the administration automatic, so that nobody actually has to send regular mails, containing formal requests, which are due in 2 weeks, in order to provide a simple certificate to a citizen. In a simple example, if you are being hired, the company has to inform the income agency, which in turn must verify whether you have not been convicted, whether you are physically fit for the job and whether you don’t have outstanding liabilities (e.g. as a business owner of a bankrupted enterprise). In order to do that, it needs to get this information. In the worst case, it would require it from you – you go to the court and get a certificate that haven’t been convicted recently; you go to the medical center and get a certificate that there are no known serious diseases in your medical history, and go to the trade registry to get certified that you don’t have a bankrupted company. In a slightly better scenario the income administration would request all these on your behalf, by sending postal requests, waiting for 2 weeks and compiling all that when the response comes. In the perfect scenario, the software of the income administration will send automatic requests, given your personal identifier, and it will get automatic responses from the software of the court, a health registry and the trade registry.

The whole idea of the proposal is to rely on a distributed architecture, where each information system invokes directly the services it needs. It has taken into account that setup of the Estonian e-government as well, as a state-of-the-art. There are a few key points in my proposal:

  • most services are actually simply providing data as response to a lookup for a (primary key, data type). E.g. “I want to know whether citizen with ID=X has been convicted”, response is true/false, or “I want to know the current address of a company with company identifier=X”, response is address. This type of services can be used via a standard protocol, so that the consumer doesn’t actually care about where exactly the data is located. For full-featured services (that may involve manual steps in the providing administration), a full-featured WSDL (or REST) based web services are used, defined by the providing administration
  • there is a central infrastructure, but it does not act as an ESB. It just knows where a given data type is located, what services each administration exposes and which administrations can participate, defining access control lists. Additionally, it logs transactional data.
  • each request for citizens’ or businesses’ information is logged, and the respective entity is notified. That way no government official can secretly spy on citizens by requesting their data from other administrations. In other words, the point is that it is easy for the government to get every information about you that you have already provided to it (practicality), but you always know when that happens, so that inappropriate checks on you are detected as early as possible. Also, only approved consumers can see a given data type (e.g. not everyone in the government can see your medical record). And yes, the government already has all the data about you, so let’s make it practical, without sacrificing our privacy.
  • everything is encrypted and digitally signed, and the government has its own certification authority
  • administrations don’t need to support complicated deployments or implement their systems from scratch. All that is needed is an adapter layer, that can accept requests on a set of standard endpoints and make requests to such endpoints.
  • a base SDK in popular languages is to be provided together with the implementation of the central infrastructure, so that all aspects of the communication are already implemented, and administration information systems should only initialize the SDK client and use it in a developer-friendly way. Each administration, providing custom full-featured services is expected to extend the base SDK and publish that for others to use.
  • administrations that do not yet have the proper information systems can use an administrative portal to get access to the data they are allowed to, in order to accomplish their tasks (e.g. manually get the data through the same channel that their information system would use)

Feel free to provide feedback about the architecture proposal, I will be glad to accommodate use-cases that I haven’t considered.

Share Button

One Response to “Proposal for an E-Government Architecture”

  1. WOW just what I was looking for. Came here by searching for football division standings 2013

Leave a Reply