#egov to help #UNDP about better governance and anti-corruption

This post is inspired by the article "The time is right to place governance and anti-corruption at center stage" (http://www.undp.org/content/undp/en/home/ourperspective/ourperspectivearticles/2013/09/30/the-time-is-right-to-place-governance-and-anti-corruption-at-center-stage-rebeca-grynspan.html#!). The article ends with "Talk to us: How can we help governments establish credible mechanisms to fight corruption?". My answer to this question is below.

As an architect of complex information systems (at the scale of canton, confederation, country, and continent), I think that a systemic approach to reduce the corruption is based on a proper architecture for e-governments and e-governance. Such an architecture will make everything transparent and traceable (thus accountable and trustful) by:

• open design of e-government and e-governance as a system (to guarantee that various components are working together)
• execution of e-government and e-governance services as explicit processes (to know who did what)
• third-party reviews of anonymized data, documents and processes (to catch problems proactively) 
• external archiving of governmental audit trails (to implement perfect records management) 
• making public some governmental data (to generate open data)
• systematic evolution of e-government and e-governance (to continuously improve the services)

My experience shows that many e-government and e-governance applications are almost the same in various ministries and countries. The level of variations between countries is estimated at about 20 %. Thus it is possible (thanks to modern information technologies) to develop a common platform for e-governments and e-governance which is implemented once and then employed many times in, for example, developing countries.

In more details this concept is presented in my several public blog posts:

• Pan-African platform for e-governments and e-governance to speed-up Africa’s transformation - http://improving-bpm-systems.blogspot.ch/2013/03/pan-african-platform-for-e-governments.html
• How many #entarch projects do you need in your #e-government & #e-governance initiative? - http://improving-bpm-systems.blogspot.ch/2013/09/how-many-entarch-projects-do-you-need.html
• #e-government and #e-governance reference model - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-e-government-and-e-governance.html
• Enterprise architecture basics in "for dummies" style - http://improving-bpm-systems.blogspot.ch/2013/06/entarch-basics-in-for-dummies-style.html

Thanks,
AS

#e-government and #e-governance reference model #entarch #bizarch #apparch

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:

1. The government sends an announcement, e.g. that a law has been changed.
2. A partner sends a declaration (also some kind of announcement) to the government, e.g. that this citizen has changed his/her address.
3. The government demands a partner to do something, e.g. to pay taxes.
4. 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):

1. Business (processing) envelope
2. Delivery (addressing) envelope
3. 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:

1. Enterprise Content Management (ECM) for the social collaborative extranet
2. Business Process Management (BPM) for coordination and integration backbone
3. 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

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

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.

Variant	Plan	Do	Check	Reflect	Comments
0	C	C	C	C	No local capabilities are available for a particular activity
1	C	L	C	C	Local staff have some work capabilities a particular activity
2	CLC or LC	C	LC	C	Local staff have some management capabilities but those people need some guidance and/or technical assistance for carrying out a particular activity
3	LC	L	LC	C	Local staff have some management and work capabilities but those people need some guidance and/or technical assistance for carrying out a particular activity
4	L	L	L	LC	Local staff have sufficient management and work capabilities to carry out a particular activity without guidance or technical assistance except for reflection
5	L	L	L	L	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

Thanks,
AS

#bizarch artefacts concept map

This blogpost accumulates my contribution (it is work in progress) into LinkedIn discussion " Business capability concepts map" http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=245602764&gid=84758&commentID=144209821&trk=view_disc&ut=0BMR0Vl690JBM1

The reference blogpost is http://improving-bpm-systems.blogspot.com/2013/03/bizarch-artefacts-definition-again.html  I use the following definition of capability from that blogpost.

capability (noun)
the proven possession of characteristics required to perform a particular service (to produce a particular result) with the required performance.

Version 1 - no processes

1. This version is deliberately simplified by removing the process concept 
2. Showing that output from one service may become input for another - what is the best way? 
3. Some services are implemented via coordination of other services - to be added later 
4. Definition of service and its implementation are in the same concept yet - maybe to separate design-time and run-time concept maps later 
5. Role and people (and other related) concepts are not shown yet
6. Service has only one operation

Version 2 - processes are added

Services and process have a recursive relationship:

• all processes are services,
• some operations (or a very detailed function wrapped by a service) of a service can be implemented as a process, and
• a process includes services in its implementation.

Version 3 - roles and some other concepts are added; input/output, outcome, mission are removed

Version 4 - design-time and run-time concepts

A service provides one or many operation(s). 

Thanks,
 AS

Addressing #security concerns through #BPM

A small presentation about potential linkage between security and BPM is available at
http://www.slideshare.net/samarin/addressing-security-concerns-through-bpm

Addressing security concerns through BPM from Alexander Samarin

This linkage is important because BPM should play the main role in the pan-African platform for e-governments and e-governance (see http://improving-bpm-systems.blogspot.com/2013/03/pan-african-platform-for-e-governments.html). Linking them will make the security more explicit.

This is concept note for a discussion.

Thanks,
AS

Pan-African platform for e-governments and e-governance to speed-up Africa’s transformation

Executive summary

It is not a secret that Africa must redouble efforts to build efficient, resilient and capable states. The modern way to improve the activities of public sector organisations is to use the Information and Communication Technologies (ICTs). There are many world-wide examples which allow saying that the sooner Africa will have governments which are fully tech-enabled with a tech-savvy workforce is the better.

The continent can accelerate the transformation of Africa by proactively provisioning of a pan-African platform for e-governments and e-governance for all regional countries. This is a unique opportunity, because of the combination of the following factors:

• overdue need for improving governance, transparency, performance, and traceability of the public sector; 
• high economic effect of implementing once and re-use about 50 times; 
• no need for huge up-front investment as e-government can be deployed incrementally with the pace of each regional country;
• e-government is a green-field project which can be done with high level of quality at the entry point; 
• higher level of e-government and e-governance is associated with the higher level of democracy; 
• real example of regional public goods; 
• world-wide progress of ICT tools;
• advancement of the ICT infrastructure in Africa; 
• entering of major IT vendors to Africa; 
• unlocking potentials for the PPP; 
• ICT has high potentials as a value-adding industry for Africa’s industrialisation; 
• new initiatives such as “4Afrika” from Microsoft, “school in the cloud”, SAP’s program for West Africa, etc.

A continent-wide coordination is necessary to lead, coordinate and monitor the design, development and use of such a platform. This coordination should bring the experience, knowledge and resources which will considerably improve the capacity of the continent and regional countries to successfully execute existing e-government and e-governance projects thus unleash the flow of similar projects.

WHY: e-government and e-governance as the foundation for Africa’s transformation 

The World Economic Forum’s Global Agenda Council on the Future of Government in its report “The Future of Government: Lessons Learned from around the World” (see http://www.weforum.org/reports/future-government) recommends “... flatter, agile, streamlined and tech-enabled (FAST) government”. The recent Word Bank’s recent report (see http://www.etransformAfrika.com) also presented the potentials of ICT to transform business and government in Africa. The UN global surveys (see http://unpan3.un.org/egovkb/global_reports/10report.htm and http://unpan3.un.org/egovkb/global_reports/12report.htm) have proved that the deployment of e-government brings the following advantages:

• public trust that is gained through transparency; 
• better financial regulation and monitoring thus reducing in the possibilities for corruption; 
• increase in the performance of governmental agencies; 
• bridging the digital divide by reaching out to vulnerable populations. 

Also, e-government and e-governance are strongly associated with the country’s level of democracy.

As it is necessary to build e-government and e-governance for more than 50 countries in Africa, it is proposed to build the pan-African platform for e-governments and e-governance and use it in many regional countries.

Considering that e-government and e-governance at the continent are not well-developed yet, a pan-African platform will be a green-field project which can be done correctly from the beginning thus saving money in the long-run.

Such a platform immediately creates numerous opportunities for PPP by facilitating provisioning of public, social, professional, voluntary, private and commercial services.

WHAT: pan-African platform

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:

• 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 trustful):
  • design of e-government as a system 
  • execution e-government and e-governance services
  • management of data & 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;
• on demand involvement of remote experts (external oversight); 
• government operational excellence (comprehensive monitoring and short improvement cycle); 
• building a development supply-chain; 
• made in Africa and run by Africans. 

Being matured and gradually enriched, the platform will enable the agile implementation of e-government and e-governance services in regional countries (see below the “foundation” architectural pattern). Also, the platform will guarantee the seamless integration and interoperability of those services on national, regional and pan-African levels.

This pattern combines the advantages of the foundation and opportunities for quick delivery:

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

HOW: Principles of implementation

1. E-government+e-governance is treated as a complex socio-economic and human-machine system which is developed with the use of the Enterprise Architecture (EA) methodology (following the recommendation of “The future of government” http://www.weforum.org/reports/future-government). Use of this methodology will allow synchronizing a complex system development strategy with opportunities carried by emerging technologies. In other words, EA methodology connects the “dots”.

      

2. The growth of ICT infrastructure in Africa to be coordinated with the growth of the platform as mutually-reinforcing factors. The ICT infrastructure is a necessary (but not sufficient) condition for the development of e-government and e-governance.

3. The modern information technologies, e.g. BPM, SOA, mobile, cloud, unified communication, electronic transactions are to be used.

4. The use of the benefits of the platform depends on the readiness of each regional country: each must identify a suitable pace. A “ladder” or “maturity model” (see below) is a metaphor for suggesting how a set of countries 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.The possibility for each regional country to advance at their own pace will be guaranteed by the proper enterprise architecture.

5. The platform is implemented from commercial and open software as shown below. Free and open source software is used by preference. The global partnership with big IT vendors: Apple, IBM, Microsoft, SAP, Oracle, etc. is to be established. For example, the platform may also incorporate initiatives such as “4Afrika” initiative from Microsoft http://www.microsoft.com/africa/4afrika/ .

6. A strong and robust eco-system for startups, innovation clusters and centres of excellence is to be created.

7. Close collaboration with existing similar and related initiatives is to be established. For example, Switzerland is trying to develop a common approach for all 26 cantons to avoid “piecemeal” http://www.egovernment.ch/en/ .

HOW: Implementation structure 

The ideal implementation structure should be able proactively coordinate the creation, design, implementation, and evolution of the platform. It should be a mixture of competence centre, centre of excellence, centre-of-expertise, solution centre, knowledge centre, and programme management office. For example:

• steering committee 
• advisory board 
• portfolio management office and director 
• several transversal projects 
• architecture committee 
• external resources (eco-system) 
• temporary ad-hoc groups (as necessary) 

The implementation structure will need to deal with a rather complex and dynamic dependencies between initiatives, capabilities, projects, tools, etc. Those dependencies are to be quantified by the EA to allow linking between the business objectives and implementation priorities (see below).

Note that although “dots” and connections between them may be different for each regional country, there is a huge potential for the reusability of tools, methods and services among the continent.

HOW: Initial deliverables 

• inventory of existing and current projects 
• involvement of international knowledge and experience
• initial pan-African architecture (with the help of big IT partners)
• explanation of the platform for all stakeholders 
• “quicksilver” portfolio
• country e-government and e-governance roadmaps
• methodology for evaluation of e-government and e-governance impact in any development project
• identification of first opportunities
• launch and assist first projects 
• monitoring, learning, coordination, refinement of architecture 

The initial pan-African platform architecture will comprise the following deliverables:

• big picture 
• reference model
• standards 
• reference architectures 
• nomenclatures of recommended tools 
• deployment practices
•  integration practices

Conclusion and question

No doubts the platform is necessary and it is necessary right now. The main next question is what organisation(s) can support the implementation of this platform and carry out the required coordination?

Thanks,

AS

A few definitions:
E-government is the use of ICTs to improve the activities of public sector organisations.
E-governance is the use of ICTs to improve the communication between public sector organisations and their stakeholders: citizens, businesses and other social organisations.