Four possible types of interactions between the government and citizens, local businesses and other organisations (briefly, partners) as shown in figure below.
- 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.
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.
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.
The partner's viewFor the partner, this extranet may have the following visual design.
- 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 viewE-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).
- 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)
- 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.