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.

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
100 %
100 %
100 %
100 %
100 %
100 %
100 %
100 %
70 %
90 %
100 %
70 %
50 %

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.

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)


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



Enterprise patterns: Maturity Of Process System (MOPS)

Business situation: You want to reach a particular level of maturity (in accordance with CMMI ) of a process-based business system - what BPM functionality will help you?

Note This is blogpost a short version of  http://improving-bpm-systems.blogspot.ch/2009/12/bpm-for-cmmi.html

We know levels of maturity applied for process-based work:
  1. A performed process is a process that accomplishes the work necessary to produce work products.
  2. A managed process is a performed process that is planned and executed in accordance with some policies. 
  3. A defined process is a managed process that is tailored from the organization’s set of standard processes. 
  4. A quantitatively managed process is a defined process that is controlled using statistical and other quantitative techniques. 
  5. An optimizing process is a quantitatively managed process that is changed and adapted to meet relevant current and projected business objectives.
We know that BPM (as a discipline) has 6 following functions:
  1. Model / Plan / Simulate 
  2. Automate / Instrument 
  3. Execute 
  4. Control 
  5. Measure 
  6. Optimise / Reflect / Refactor 
The table below shows what all functionality of BPM discipline is involved at each level of maturity. But, the nature involvement maybe different: “implicit” (informal or ad-hoc), “explicit” (formal or systematic) and in between (marked as “I/E”).

BPM functions vs levels of process maturity
Performed process
Managed process
Defined process
Quantitatively measured process
Optimising process
(black box)
Explicit (locally and approx.)
Explicit (globally and detailed)
Explicit(globally and detailed)
Explicit (globally and detailed)

So, you can easy evaluate the needed BPM functionality to deliver a particular level of maturity of a process-based business system.



Enterprise patterns: Anisotropically Decentralized Organisation (ADO)

Business situation: Branch Offices (BOs) with different level of skills and staffing have to carry out similar processes; the Central Office has to support them. (A possible BOs - CO scenario is local governments - federal government.)

Consider that any activity can be decomposed in four logical steps (similar to PDCA cycle):
  1. Plan: preparation for the work to be done;
  2. Do: execution of the work; 
  3. Validate: checking of how good and correct the work has been done; 
  4. Reflect (also can be called re-factor): analysis of the newly obtained experience and results to propose/implement some improvements to similar work which will be done in future.

Under decentralisation, each step can be carried out in a few different combinations of the participation local (L, i.e. at a particular branch office) and central (C, i.e. at the headquarters) resources. For example, if a particular branch office has no experience with the procurement of a particular type of service then such procurement should be carried out at the HQ. It is considered that central resources are capable doing any activity (which implies also any step within any activity).

Possible combinations are:
  • [C] fully centrally (i.e. no delegation) 
  • [L] fully locally (i.e. complete delegation) 
  • [LC] with central post-control 
  • [CL] with central pre-advice 
  • [CLC] with central pre- advice and post-control 
Only some of those combinations are really applicable in each of those four steps.
  • Plan – C, L, LC, CL, CLC (some consultations between local and central resources are possible and sometimes are mandatory) 
  • Do – C, L (actual work can be done only by one resource) 
  • Check – C, L, LC 
  • Reflect – C, L, LC 
Those combinations are not independent and they are combined in a few variants which are actually some kind of degrees of decentralisation of a particular activity.

No local capabilities are available for a particular activity
Local staff have some work capabilities a particular activity
Local staff have some management capabilities but those people need some guidance and/or technical assistance for carrying out a particular activity
Local staff have some management and work capabilities but those people need some guidance and/or technical assistance for carrying out a particular activity
Local staff have sufficient management and work capabilities to carry out a particular activity without guidance or technical assistance except for reflection
Local staff have sufficient management and work capabilities to carry out a particular activity without guidance or technical assistance; they are capable for continual improvement / optimising via reflection

Those variants also may be considered as branch office capability maturity levels:
  • 0 none 
  • 1 technical 
  • 2 managerial 
  • 3 defined 
  • 4 managed 
  • 5 optimising 

The trick is how to choose the best variant which should be used for a particular activity in a particular process instance within a particular branch office to be done with particular people (implied branch office staff). It can be done some kind of an “decision” system which
  • “knows” processes, activities and local specifics;
  • traces the actual capabilities and expected performance of people and processes; 
  • estimates different risk factors (political, financial, etc.) and degree of compliances; 
  • helps to choose the best (in particular circumstances) variant and - justifies any other actions. 

Such a decision system should be systematically consulted “between” normal activities. In some sense, it is responsible for overall controlling, measuring of outcomes, overall planning and overall guidance during the cause of execution of project’s normal activities. It should be carried out by central resources because it should have access to the enterprise-wide knowledge. Such a decision mechanism may work together with DAM pattern - http://improving-bpm-systems.blogspot.ch/2012/07/practical-process-pattern-dam.html