This blogpost about
e-gov reference model is a continuation of the blogpost "How many #entarch projects do you need in your #e-government & #e-governance initiative?" (see
http://improving-bpm-systems.blogspot.ch/2013/09/how-many-entarch-projects-do-you-need.html).
Four possible types of interactions between the government and citizens, local businesses and other organisations (briefly, partners) as shown in figure below.
These types of interactions are:
- The government sends an announcement, e.g. that a law has been changed.
- A partner sends a declaration (also some kind of announcement) to the government, e.g. that this citizen has changed his/her address.
- The government demands a partner to do something, e.g. to pay taxes.
- A partner demands the government to do something, e.g. to provide a fishing certificate.
The last two types of interactions can be long-running interactions - there may be some noticeable time (weeks) between sending a demand (start) and receiving the result (finish). Even, the partner and the government may interact between the start and finish as shown in figure below.
In addition, the partner may have to deal with various ministries within the government. Usually, each ministry works in own way thus complicating life of the partner as show in figure below.
To protect the partner from the internals of the government and to unify his/her interactions with the government, the e-government acts as a shell which coordinates the flow of data (and documents) between the partner and the government. The e-government treats all government work as a processes. These processes fulfil their goals by coordinating various services. For example, a partner's demand can be a result of joint work of three ministries in four steps as shown in figure below. The blue circled numbers show the process (flow of control) steps.
The related flow of data (and documents) is shown by the red circled labels in figure below.
Each step on two previous figures is actually a process fragment which may be rather complex. For example, the details step #2 show (see figure below) that one of its activities is a task for the partner (activitiy 2b).
A possible sequence of the execution of this fragment is shown in figure below by the red circled numbers.
The usage of processes simplifies:
- notifying the partner about the progress in processes related to him or her
- monitoring of SLA
- continual improvement
To streamline the work of partners with the government, e-government provides a social collaborative extranet for all partners. This extranet :
- helps partner to manage all electronic documents (which are exchanged between the partner and the government) in a secure manner,
- helps partner to execute his/her tasks,
- allows a partner to interact with other partners.
This extranet is an interface layer between the partners and e-government (thus with the whole government as well) as shown in figure below.
The partner's view
For the partner, this extranet may have the following visual design.
This extranet considers that:
- Each partner has several roles, e.g. YOURSELF (person and his/her legal representatives), CITIZEN (person officially leaving in this country), ENTERPRISE (manager of a business), SENIOR (persons with age over 60), etc.
- Person may select which roles he/she is carrying out at a particular moment in time.
- Each communication between a partner and the government is a case with associated documents, data, audit trails, records and KPIs.
- A case may be completed or on-going.
The inter-ministerial integration view
E-government, which is acting also an inter-ministerial coordination tool, ultimately resolved the integration problem. Instead of that ministries are connected to each other in ad-hoc way, the e-government offers an integration process which delivers data and documents between all ministries in a systematic way as shown in figure below. It is actually a centralised service for the inter-ministries secure electronic exchange (like sending / receiving registered letters).
Generally, the backbone is decoupled from intra-ministry applications through two adapters: dispatcher (handle messages coming from the backbone) and expediter (handle messages going to the backbone). To be transmitted through the backbone, each message (business data and documents) is protected by three "envelopes" (marked by blue circled number in figure below):
- Business (processing) envelope
- Delivery (addressing) envelope
- Transportation (routing) envelope
Of course, the access to open reference data (e.g. list of addresses in the country, some geodata, etc.) is different.
Application architecture (platform-based)
In general, the e-gov application architecture is as in figure below. There are three main technologies:
- Enterprise Content Management (ECM) for the social collaborative extranet
- Business Process Management (BPM) for coordination and integration backbone
- Service Oriented Architecture (SOA) for coordination and integration backbone
Let us put this application architecture in the context. For the long time, e-gov application architecture was
portal-centric and its applications (blue "emabas") were extensions for some internal applications as show in figure below.
The proposed architecture is actually, the
introductory architecture which introduces necessary flexibility. E-gov applications may span several existing applications as shown in figure below.
As existing applications are evolving, they will be replaced by processes and services as well thus creating
transitional application architecture as shown in figure below.
With converting all previously monolith applications into processes and services, the
target application architecture will be reach as show in figures below. E-gov applications will be just connections to a cloud of services.
And, moving e-gov to the really e-social system, the application architecture will morph into a social cloud interacting with the service cloud as shown in figure below. The latter serves as a platform for social, professional, private, voluntary and other services to be integrated into e-social system.
Important that for existing e-gov systems the evolution from the introductory architecture upwards does require only the systematic use of BPM and SOA. Green-field e-gov initiatives may start from the target architecture.
Thanks,
AS
Posts
