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.

#bizarch artefacts definition; again

This post is written for the LinkedIn discussion "Whats the defference between, a Business Capability, a Business Function, a Business Process and a Service?"
In this post, I collected (and refined) several #bizarch definitions from the posts about #bizarch.

activity, noun
elementary or indivisible unit of work

function, noun
abstract and self-contained grouping of activities that collectively satisfy a specific operational purpose

Remark 1: Functions are unique within the enterprise and should not be repeated.
Remark 2: Some functions can be decomposed into smaller groups of activities, and thus the functional view has a hierarchical structure. (Without taking into account that one function may use other functions to accomplish its purpose.)
Remark 3: The structure of functions is not always the same as that of the organisation chart; in many cases, some organisational units can span several functions. Furthermore, organization charts may change while the function does not.
Remark 4: A business function typically has the suffix ‘management’ in its name (e.g. ‘Customer Relationship Management’), but it can also be a noun (e.g. ‘Marketing); usually, function name specifies something that is performed continuously.
Remark 5: The functional view emphasizes WHAT the whole enterprise does to deliver value to the customer (without the organizational, application, and process constraints). Usually, the hierarchical structure of business functions is very static (with a low rate of change).

service, noun
explicitly-defined, operationally-independent, and consumer-facing repeatable unit of functionality that creates a particular result for the consumer

Remark 1: It is considered that there are internal (even within an enterprise) providers and consumers as well as external consumers.
Remark 2: A service may wrap several functions. (In IT, we call them operations.)
Remark 3: A service is self-contained in some extend.
Remark 4: Complex services are created by means of the coordination of more simple services and/or activities (in the same way that an orchestra is a coordination of individuals and their actions). In this sense, an enterprise is a mega-service composed of a network of nano-services.

process, noun
explicitly-defined coordination of services and/or activities to produce a particular result

Remark 1: Processes are HOW of the business.
Remark 2: Services and processes can be considered to be intimately related since in real terms

• 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. 

capability, noun
the proven possession of characteristics required to perform a certain kind of work (i.e. as a particular service to produce a particular result) with the expected performance

Remark 1: Capability needs to “understand” the mechanics of delivering that service. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service.
Remark 2: Capability is named after the expected result/performance (http://ingenia.wordpress.com/2010/10/19/modelling-behaviour/), e.g. “2CV”.

Why do we need all of them? 
Functions is an internal view of an enterprise (or supply-side). Services is a consumer view of functions (or demand-side). Capabilities is a performance view (or matching demand and supply) including both expected and realised performance.

Each service is associated with an owner who is responsible for delivering the promised results in all instances in which that service has been requested. That owner has

1.  to know/estimate the demand-side needs (the service may have many different consumers who will be using it with different frequencies), and 
2.  to design/organise/create in advance the supply-side capabilities to ensure those needs are satisfied. 

So, how can one ensure that a service has the required characteristics? There are three control options:

1. by contract (“re-active” approach) – acquire a service with the required characteristics, use it, check that its performance is acceptable and replace it if something is wrong with it; 
2. by measurement (“active” approach) – implement a service, use it, measure it, improve or re-build it, etc.; 
3.  by design (“pro-active” approach) – build a service model, run a simulation test, improve the model, build the service, use it, measure it, improve it, etc. 

The first option works with some support services, the second option can work satisfactorily with lead services and the third option should be used for core business services. The core business services can’t be outsourced, can’t be bought and must not be “damaged”.

One of the models of the "mechanics" of provisioning a service is a business process. The explicit coordination brings several advantages.

• It allows planning and simulation of the behaviour of a service to evaluate its performance. If that service uses other services, then the demand-side needs for those services can also be evaluated. 
• It can be made to be executable, thus guiding how work is done. 
• It allows control that the actual behaviour of the service matches its intended behaviour, thus pro-actively detecting potential problematic situations. 
• It allows the measurement within a service of the dynamics of different characteristics, e.g. valuing, costing, risk, etc.

Thus a process is a way to guarantee a capability of a service to perform a function.

And architects are responsible for this how (see http://improving-bpm-systems.blogspot.com/2013/03/architects-are-responsible-for-how-thus.html).

Thanks,
AS

Architects are responsible for HOW thus capability of WHAT

Many recent discussions were talking about WHY, WHAT, and HOW as outputs of architectural work.   I already blogged about dependencies / linking between them (see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture_19.html ).

In this post, I would like to outline who is responsible for WHY, WHAT and HOW. But, at first, let go back to basics and define "architect".  My terminology (www.samarin.biz/terminology), says that, in the broadest sense, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

Let us look at civil architecture. In each construction project there are three distinct roles: a customer (an individual, or an enterprise), a civil architect (a licensed individual who leads a team in the planning and design of buildings, and participates in the oversight of building construction) and a general contractor (a company which constructs buildings).

A customer contacts a civil architect who presents to the customer a solution (in some kind of visual format, e.g. a drawing or a scale model, because the aesthetics are often very important). After some possible reworking followed by acceptance of the final solution, the civil architect is empowered by the customer to guarantee a good means of construction. The civil architect selects a general contractor and the civil architect works with a foreman – an experienced professional who is in charge of organising the overall construction, including the construction crew.

The separation of duties between these roles is very important – a civil architect and a general contractor are different individuals or companies (by obligation, at least in some countries). Such a separation helps to achieve the appropriate control and quality of the results. Also, it is interesting to note that there is no explicit project manager role per se – each role has to carry out some “project management” duties. For example, a foreman is actually a project manager on the side of the general constructor (and has usually arrived in a management position after experience as a construction worker and not as a professional project manager). 

In the case of IT projects these roles could be mapped in the following way: the “customer” is a business unit, the “architect” is a small group of agreed minds (i.e. the architecture team) which translates the customer’s requirements into a viable plan and guides the execution of that plan, and the “general constructor” is an internal IT development and infrastructure unit (with the potential of outsourcing).

WHY is given as the client's intention, and it is usually implicit. A good architect must make this WHY explicit by asking right questions.

WHAT is given as the client's ideas, but neither in details nor final (for example, some client's ideas may be just impossible because of some rules and laws). The architect must explicitly define WHAT will be produced.

One definition of WHAT (for the client) has to demonstrate that HOW that WHAT is able to satisfy  the client's WHY. The architect must proof that WHAT is not just a nomenclature with smaller WHATs but how those smaller WHATs are properly structured (and properly "work" together) to deliver the requested capability (ability to address the client's WHY). Such a definition is HOW-capability.

(Remember that capability is a proven possession of characteristics required to perform a particular service with a particular results and with required performance. The key words are: "proven" and "performance".)

Another definition of WHAT, which must be prepared by the architect, is HOW-feasibility which is dedicated for the builders. It is usually a blueprint. And the blueprint is just a beginning. The actual construction should be monitored, supervised and guided to guarantee that the final product does corresponds the blueprint.

So the architect is responsible for HOW because he/she has to proof & guarantee the future performance of WHAT.

Of course, architecting modern information systems is more complex that city planning. Information systems are evolving, new technologies are disrupting, new business needs are emerging, services are re-used, processes are improved, etc. At the same time,  the potentials of proper architecture are huge (for example, http://improving-bpm-systems.blogspot.com/2012/11/an-example-of-entarch-contributing-to.html).

Thanks,
AS

Result-Based Logical Framework

Idea of results chain... Outputs -> Outcome -> Impact.

Thanks,

AS