How many #entarch projects do you need in your #e-government & #e-governance initiative?

Imagine, that a country wants to implement its e-government and e-governance correctly. One of the critical measures of implementation "correctness" is minimal (ideally, total avoided) duplications in its e-government and e-governance implementations while following the goals and priorities of the country. The ideal situation should be achievable when e-government+e-governance is created practically from the scratch as, for example, in many developing countries.

Typical country has the following levels of government:

1. National (or federal) 
2. Federal ministries and agencies
3. Regional (or cantonal or provincial) authorities with their ministries and agencies
4. Districts (and sometimes sub-districts) authorities
5. Communal authorities

Depending on the country political system, the separation of power between national, regional and communal levels are different. In "parliamentary republic", more power is at regional level. In "constitutional monarchy", the power is at national level. But, from the government-as-a-system point of view, there are several communicating governmental entities which are working together as one whole to provide services to citizens, business and other non-governmental/social organisations.

We know that e-government+e-governance is a complex system:

• Unlimited life-cycle (unpredictable and incremental evolution) 
• Socio-technical system (how you do something is sometimes more important than what you do)
• Collaborative system 
• Industrialised system 
• Ability for rapid innovation is important 
• Variety of services (several hundred governmental services are listed in the Swiss e-government catalogue http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-0070&documentVersion=4.00)
• High level of security for personal data

A system of such complexity must be properly architectured with all power of  #entarch and other technologies.

BPM, SOA and EA for e-government from Alexander Samarin

So how many #entarch projects should be carried out?

One estimation (found in an procurement notice from a UN agency) is "Each entity within the Country will be required to define their enterprise architecture for provisioning of e-Governance Services and improving the efficiency and effectiveness of the public sector." In this Country there are 40 ministers, 18 provinces, about 100 districts (with a few sub-districts each) and unknown number of communes.

Hope that the Country is not going to have 200+ #entarch projects although this will be a diamond mine for consultants. For example, I saw a one-year long with the budget of 500 000+ EUR project just for building an initial enterprise architecture. After 4 years only a fraction of its recommendations were implemented and changes in the business required continuous modification of the architecture as it was not flexible enough.

Keeping in mind the guidance of the minimization of duplications, let us analyse each level.

Communal (and district) level

By definition, all communes and districts provide the same services. Thus the technical, data, application and business architectures should be the same. Although those governmental entities may have different capabilities, the enterprise pattern ADO (see http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html) provides guidance how to handle this situation.

Provincial level

All provinces provide the same services, but with some internal variations as their structures, priorities, even laws may be different. Nevertheless, the technical, data, and application architectures should be the same. At the business level, different provinces carry out the same e-government and e-governance services via slightly different processes which use the same services. The blogpost  (see http://improving-bpm-systems.blogspot.ch/2013/02/enterprise-patterns-peas-example-and.html)  shows how to achieve a common set of services and assemble them into your slightly different processes.

Important, that the modelling of business processes must be standardised so different analysts find similar services in similar capabilities. A modelling procedure which can considered is available at  http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html .

Ministerial level

As different ministries have different core businesses, their architectures will be different in some extent.

• Technical architecture can be almost the same (except if some unique functionality is required).
• Data architecture of each core business actually must be shared among the whole e-government and e-governance thus to be aligned at the national (i.e. centralired) level.
• Application architecture of each ministry consists of 20-40 % of unique applications and the rest are common (within the whole e-government) applications. If possible, all applications (the both unique and common) are architectured in a similar way, e.g. http://improving-bpm-systems.blogspot.ch/2011/07/enterprise-patterns-caps.html
• Business architecture may look very different unless processes patterns are systematically used. Various process patters are available at http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns . Being armed with those patterns in, organisations will be concentrating on the unique business challenges and not wasting time for re-inventing the wheels. 

National level

This level is, practically, a decision-making mechanism which works together with the ministerial level. The vaste majority of work is to prepare, validate and approve documents in accordance with several decision-taking patterns (AS to write a blogpost "decision-as-a-process").

What is common?

Technical and data architectures are practically common. Application architecture is shared at about 80-90 %. Business architecture is shared at about 70 %.

	Technical architecture	Data architecture	Application architecture	Business acrhitecture	Number of unique #entarch projects
Communal	100 %	100 %	100 %	100 %	0
Provincial	100 %	100 %	100 %	80%	0
Ministerial	90%	100 %	60-80%	70 %	0
National	90 %	100 %	70 %	50 %	1

It seem that instead of #entarch project for each governmental entity, it is necessary to consider the the e-government and e-governance as a system and to concentrate on the common components. So, one #entarch project and several solution-architecture projects (to develop common components) should be enough.

Some of common components are mentioned below.

Reference model for e-government and e-governance (more details are in http://improving-bpm-systems.blogspot.ch/2013/10/entarch-e-government-and-e-governance.html)

In accordance with this architecture, the partners of a government (citizens, businesses, organisation, and other governments) will communicate with the government through a social collaborative network. The latter is based on modern Enterprise Content Management (ECM) tools and provides various functions for various partners. For example, each citizen can announce to the government changes in his/her situation (e.g. change of address) or can request from the government some documents (e.g. certificates). The social collaborative network allow implementation not only of citizen-to-government services, but also of communities-to-government services thus enabling e-governance.

Any work within the government is a process. The processes fulfil their goals by coordinating various services. The latter are provided by the government, and private and other partners. The use of processes allows higher transparency (who is doing what, how, why and with what results), better visibility (following up of citizen’s requests), more flexibility (assembly of processes from services), faster implementation (assembly from existing and new services) and easier integration between various governmental agencies (via secure processes).

Common data dictionary and virtual MDM

All data element must be centrally managed (firstly, standardized).  In Switzerland, it is done at the federal level - http://www.ech.ch.

Common agile application architecture

This architecture should be based on BPM and SOA. From the business point of view on BPM and SOA, an executable process coordinates some services as shown in figure below.

But from the IT point of view, there may be many different services around each process, because a process requires various artefacts: events, roles, rules, documents, data, audit trails, and performance indicators. To help structure different services and other artefacts around processes, a multi-layer implementation model (see figure below) is proposed for BPM/SOA solutions. In this model, each layer is a level of abstraction of the business and addresses some particular concerns.

Common implementation platform

As it is mandatory to avoid the duplication of work among different organisations and among various projects within each organisation, the use of the platform pattern is of critical importance (see enterprise pattern PEAS at http://improving-bpm-systems.blogspot.com/search/label/PEAS ).

Ideally, all common capabilities should constitute a national implementation platform, which is available for all organisations. Instead of re-implementing the same common capabilities, different organisations will implement only their specific services on top of this platform (see figure below). E-province can be the first step in the realisation of the national implementation platform. This enterprise pattern combines the advantages of the platform with opportunities for quick delivery:

• to standardise and simplify core functionality as a coherent foundation and 
• to speed up the implementation of new innovative solutions on top of the foundation.

The platform is a coherent set of governance rules, architectural principals, best practices, integration patterns, shared ICT tools and solutions. Key characteristics of the platform are:

• incremental creation and gradual deployment; 
• high maturity level of corporate basics, e.g. with records management, risk management, electronic management of documents, and management by processes; 
• high maturity of IT operations, management and governance; 
• everything is transparent and traceable (thus trustworthy): 
  • design of e-government as a system, 
  • execution of e-government and e-governance services, 
  • management of data and document repositories,
  • some data are open,
  • evolution of e-government and e-governance
• risk-awareness (including proactive risk evaluation) is built-in by design; 
• paperless exchanges between government, citizens, business, and other partners from the civil society; 
• opportunities for public-private partnership. 

Typical generic capabilities of the platform are:

• Identification
• Authorisation
• ESB
• BPM
• Document management
• Record management
• Decision management
• Complex Events Processing
• Data warehouse, reports, analytics
• Traceability
• Security by process
• Digital and mobile work

As the platform becomes mature and gradually enriched, the agile implementation of e-government and e-governance services will be enabled. The benefits gained from the platform will depend on the readiness of each organisation: each is permitted to progress at a suitable pace. A “ladder” or “maturity model” (see figure below) is a metaphor for suggesting how a set of organisations with different abilities might achieve common goals and plan their progress. The “ladder” has a few levels of capability from “not able” to “fully capable”.

Common inter-governmental-entities communication (data and document exchange) backbone

From everyone to everyone connectivity, the governmental agencies should use a single and secure "postal" backbone service. (see an example from Switzerland - http://www.bfs.admin.ch/bfs/portal/fr/index/news/00/00/02.html)

Example of common components working together

Slides with * contain animations - better to download this presentation.

E-passport example from Alexander Samarin

Idealistic plan for implementation of e-government and e-governance

1. Establish a strong #entarch function 
2. Agree on the governance for common components 
3. Start to implement them and unique components in accordance with the national strategy (see http://improving-bpm-systems.blogspot.ch/2013/04/enterprise-patterns-strategy-to.html)

Conclusion

Conceptual integrity is mandatory to reach some coherence in decisions about:

• Optimisations for users (external and internal)
• Compliance with laws
• Avoiding duplication of work among ministers, provinces, municipalities
• Simplification of evolution of applications
• Realisation of the strategy
• Natural evolution of e-gov
• Standardization of business processes fragments and unification of software
• Introduction of new tools and technologies

For a green-field e-gov one 1 #entarch project is necessary (in which we have to establish the conceptual integrity).

An example of conceptual integrity is http://improving-bpm-systems.blogspot.ch/2013/04/enterprise-patterns-strategy.html

Thanks,
AS