Again in #BPM BLOGS WORTH READING 2013

My blog is again in "BPM BLOGS WORTH READING 2013"
http://ultrabpm.wordpress.com/2013/12/02/bpm-blogs-worth-reading-2013

Thanks,
AS

Practical process patterns: LifeCycle As A Process (LCAAP)

Practical process pattern LifeCycle As A Process (LCAAP) is a way to handle some Business Objects lifecycle with a BPM suite. It is considered that those BOs are passive, e.g. documents as licenses.

A lifecycle of an BO is a few phases and branches between those phases (see the diagram below).

Each phase is implemented in the same way (see the diagram below).

In addition, the lifecycle of all BOs is controlled by a DISPATCHER process (see the diagram below) which catches some external events, checks them and converts them into events to change the phase of an BO.

Please note, that one instance of DISPATCHER template serves many instances of LIFE-CYCLE template.

This pattern can be used as a basis for Product-As-A-Process (see http://improving-bpm-systems.blogspot.ch/2013/06/practical-process-patterns-cxaap.html).

Thanks,
AS

#BPM to reduce IT #complexity

Thanks to the works of Roger Sessions (@RSessions) we know that modern IT systems are very complex and, in general, their complexity should be reduced. Of course, we want to decrease the undesired complexity and better manage the required complexity, as IT systems have to solve more and more complex business problems.

The complexity can be estimated as a function of the number of components (parts of the system) and the number of relationships between them. In the worth case scenario, each component to connected to all others and the complexity has the exponential growth – N x (N-1)/2, where N is the number of components. Often, in a real IT system, it is just impossible to evaluate exactly the number of relationships, because some of them are implicit.

Let us show how BPM (which is a trio of discipline, architecture/practice and BPM suite COTS) reduces the IT complexity. From two detailed blogposts “BPM for developers” http://www.slideshare.net/samarin/bpm-for-developers and “BPM for business analysts” http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html we need the following architectural considerations.

1) In BPM, processes are explicit and executable relationships between many other artefacts: events, services, rules, roles, data, documents, audit trails, KPIs, etc.

2) Processes and services are related in recursive way:

• all our processes are services,
• some operations of a service can be implemented as a process, and
• a process includes services in its implementation.

3) BPM architecture comes with a systematic modelling procedure to identify related artefacts and the latter are implemented (or wrapped) as services.

From those architectural considerations, the use of BPM is:

a) reducing the number of components as the modelling procedure helps different people find similar artefacts in similar situations thus increasing the re-usability;

b) making all relationships explicit as all processes are explicit and executable thus helping to control the number of relationships (typical monolith applications are becoming coordinated sets of services - http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html), and

c) reducing the number of relationships as within a process, the number of relationships is proportional to N-1, where N is the number of its components (i.e. artefacts) because all except 1 are connected only to the process (also an artefact).

There are also other benefits to use of BPM:

d) BPM penetrates 2,5 levels of the enterprise architecture (business, application, data, technology) and becomes a business-system-forming factor. This considerable simplifies the implementation of agile and flexible business systems (see http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS).

e) BPM can address some concerns of the information security – see http://improving-bpm-systems.blogspot.ch/2013/10/bpm-enables-cibersecurity-because.html

Thanks,
AS

About #social, #BPM and #ECM, again

This blogpost is inspired by the blogpost http://peterwhibley.wordpress.com/2013/11/01/social-bpm-is-dead-long-live-social-case-management/?goback=%2Egde_70120_member_5802043386345046020#%21 which is talking about Social and Enterprise Social Network (ESN).

START QUOTE
At a basic level all of these features are focused on enhancing knowledge worker productivity by delivering enhanced collaboration and support opportunities. Let me know what you think:
END QUOTE

Below is what I think about Social features mentioned in that blogpost.

Mentioned Social feature	Existing techniques
Enhanced collaboration and file sharing	Any modern ECM does this by default
Collaborative creation of content within a case	Does it mean usual co-editing?
Automatic creation of temporary team workspaces or groups focused on a specific process or a specific case to facilitate the collaboration and sharing of ideas among co-workers	Any modern ECM does this by default
Runtime guidance from subject matter experts	Decision-as-a-process (see URL below) and Community-based coordination in BPM (see URL below)
Rapid access to shared content and content ranked on utilization by co-workers and teammates	Any modern ECM does this by default
Crowdsourcing or distributed problem solving	Decision-as-a-process (see URL below)
Social Stream and BPM work queue integration i.e. the Social work queue which many BPM platforms already offer today	Already in some BPMS
Shared team folders and shared case management folders	Any modern ECM does this by default
Collaborative process design and continuous process improvement.	Two different concepts. Collaborative design is a feature of BPMS. Continuous process improvement is a governance issue. Both are addressed differently.
Leveraging social awareness to deliver automatic process routing based on availability	Community-based coordination in BPM

Decision-as-a-process - http://improving-bpm-systems.blogspot.ch/2013/10/practical-process-patterns-decision-as.html

Community-based coordination - http://improving-bpm-systems.blogspot.ch/2012/07/coordination-techniques-in-bpm-social.html

So, this confirms that I said in BPM.COM (see http://www.bpm.com/home/forums/has-social-failed) “I think that Social in the way of absorption by established business disciplines.”

Thanks,
AS

From a business analyst to a business architect

I was asked for advice on how to grow from a business analyst to a business architect. Below is my list of things to learn.

understand architecture (see - http://improving-bpm-systems.blogspot.ch/2013/06/entarch-basics-in-for-dummies-style.html)

understand #bizarch (see - http://improving-bpm-systems.blogspot.ch/2011/02/explaining-ea-business-architecture.html)

know #bizarch artefacts

• mission, vision, strategy (see - http://improving-bpm-systems.blogspot.ch/2013/04/enterprise-patterns-strategy-to.html ),
• goals, objectives, (see - http://improving-bpm-systems.blogspot.ch/2013/03/result-based-logical-framework.html ), 
• organisation design (see - http://improving-bpm-systems.blogspot.ch/2011/10/enterprise-pattern-structuring-it.html and http://improving-bpm-systems.blogspot.ch/2012/01/enterprise-pattern-sito-extended.html )
• portfolio/projects (see - http://improving-bpm-systems.blogspot.ch/search/label/PMO )
• capabilities (see - http://improving-bpm-systems.blogspot.ch/2013/03/bizarch-artefacts-definition-again.html )

understand processes as the most popular #bizarch artefacts

know process patterns (see http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns)

know how culture may effect organisation

know "business analysis" from http://www.iiba.com  and get ceritication

know "business architecture" from http://www.businessarchitectureguild.org/ and get certification

know the relationships between all #bizarch artefacts (very important)

know enterprise patterns

be able to design processes (as a path to business process architect)

understand basics of application architecture

specialize in e-gov or healthcare or other domains

Thanks,
AS

#entarch to help #healthcare

The huge cost of failed healthcare projects confirm that the problem is systemic. To solve it let us expand the scope to the whole healthcare eco-system. Without doubts, each healthcare organisation within the eco-system has its unique business processes, but those processes are “constructed” from typical business working practices. The latter can be common for any sector as well as specific for the healthcare sector. Thanks to BPM, these working practices can be formalised as actionable (e.g. in BPMN) process fragments.

So, instead of spending money to implement unique business system for each healthcare organisation, let us consider a common platform, which allows to easy implementing unique business processes from a coherent set of world-class working practices and deploy this platform into each healthcare organisation.

Healthcare reference model

To have such common platform, a healthcare reference model must be developed and accepted. For example, it can be based on the synergy between:

• knowledge management, 
• use of processes to better manage the Healthcare, and 
• existing achievements in the standardization of the interaction between medical applications, HL7.

Platform-based implementation architecture

A platform-based implementation architecture (http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html) is based on the following considerations:

• The platform must standardise and simplify core elements of future enterprise-wide system. For any elements outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform.
• An agile approach requires coordination at a system level.
• To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives.
• Existing elements of the platform also need periodic challenge. Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.

Forthcoming innovations faster

The platform will accelerate the implementation of following technology-enabled innovations.

##	Innovation	Technology-enabled techniques	Impact
1	Medical records are safely managed and properly share among the participants of the eco-system	Security is compared with private banks. Well-structured data. World-wide access for patient’s data.	Comprehensiveness of personal data. Anonymous by Owner data for analysis and consultations
2	A patient can visit a doctor remotely	Video conferencing.	Avoid hassle for trivial cases. Better traceability.
3	A patient can provide some simple “measurements” (pressure, temperature, sugar in blood) remotely	Smart devices and connectivity.	Systematic caring, faster alerting to prevent complex situations. Better traceability.
4	Best specialists can provide consultation to an anonymous patient and recommend him/her the best possible treatment	Video conferencing. World-wide access for patient’s data.	Improving the quality of treatment.
5	Patient is guided for home-based treatment	Predefined coordination and alerting (e.g. for taking pills). Systematic monitoring.	Better supervising
6	All participants of the health-care ecosystem are electronically interlinked: doctors, hospitals, labs, pharmacies, insurances, government agencies	Secured exchange of data.	Higher quality of data. Less overhead.
7	Other social (from governmental agencies), scientific, professional (3rd party reviewing), and commercial (express delivery) services can be plugged-in	Standard interfaces for services in standard processes.	Cost management. Opportunities for small and local businesses.
8	The joint work of all participants is coordinated in a transparent and traceable manner.	Guaranteed audit trail. Guaranteed goal.	Early catching of problems. Continual improvement.

Advantages for everyone

The main participants in the whole healthcare eco-system and their concerns are listed below:

• Patients – hassle-free access to the healthcare services, correctness of treatment, maximum as possible treatment at home, cost.
• Doctors—zero routine work, access to the medical knowledge, access to medications, traceability.
• Other service providers – minimum overhead, common (with doctors) decision making.
• Insuring bodies – traceability, cost of overhead, correctness of treatment.
• Insurance companies – correctness of claims, correctness of treatment.
• Governments – overall quality, overall cost.
• Other services – easy to have business the main participants.

Some of those concerns will be address by mentioned above innovations.

Conclusion

#entarch can help #healthcare in the following way:

1. Define the right scope – the whole healthcare eco-system
2. Develop a healthcare reference model (#bizarch)
3. Architect a common implementation platform (#apparch)
4. Provide context for the HL7 data standardization work (#dataarch)
5. Provide context for infrastructure

The wide use of the same platform will allow Geographical expansion of services, the virtual doctor's office and unification of basic healthcare services.

Thanks,
AS

#BPM enables #cybersecurity because the latter is an inside job

Blogpost of Larry Karisny "Is Cybersecurity an Inside Job?" -- http://globalriskcommunity.com/profiles/blog/show?id=5112778%3ABlogPost%3A151183&xgs=1&xg_source=msg_share_post (registration required) concludes that

QUOTE START
Problems occur in business processes when someone or some technology does something wrong whether intentional, mistakenly or as part of a targeted attack. We can only achieve true security when multiple actions and process can be detected simultaneously and in real time. New technologies are offering these capabilities in a time when we are rapidly expanding interconnected humans to intelligent machines that have capabilities that are so large we are having trouble even viewing these processes.

We need to start recognizing that authentication of a person no matter how accurate the techniques used are only the first level of cybersecurity. True security can only be achieved when combining prevention and detection technologies at the real time business or process input action level. Most security breaches occur quickly and are themselves an input process action. Using technology than can focus on these input actions is where we need to focus our efforts.

True cybersecurity will be obtained when we can effectively view, audit, correct and block organizational process actions. If you could have a technology that does this, then why not?
QUOTE FINISH

Maybe, instead of reactively "view, audit, correct and block processes" at run-time, proactively build-in the security into business processes at design-time?

A few examples of how BPM addresses security concerns are below.

The blogpost http://improving-bpm-systems.blogspot.ch/2011/10/ea-view-on-enterprise-risk-management.html shows the big picture in which each process is enriched with the security/risk monitoring and evaluation.

The blogpost http://improving-bpm-systems.blogspot.ch/2012/09/practical-process-anti-pattern-doum.html recommends that any resource must be available only if an actor is carrying out a particular activity in a particular process instance.

And the slides 25-27 from http://improving-bpm-systems.blogspot.ch/2013/04/addressing-security-concerns-through-bpm.html show that some security can be guaranteed at the design time. It is possible to design cybersecurity not only within a particular process template, but also within a system of process templates.

Thus, explicit and executable business processes will help to improve the security (sure the architecture defines how).

Thanks,
AS

My proposal for paper-saving contest #papersucks is in the top 4 - please vote to support it

Bryant Duhon  from the AIIM has informed me that my proposal to reduce the use of paper in the business is in the top 4.

The idea is very simple: "The management (from top level down) stop accepting (reading, commenting, signing, etc.) documents on paper (and other physical media). " and its potential implementation is in http://improving-bpm-systems.blogspot.ch/2013/02/towards-paperless-or-digital-or-less.html

Please vote for it at https://www.surveymonkey.com/s/PSK8N9R

Thanks,

AS

#egov 2.0 «à la russe» from the enterprise architect point of view (in Russian language)

This blogpost is available only in Russian language - http://egov-tm.blogspot.ch/2013/10/egov-20-la-russe.html

Thanks,
AS

Practical process patterns: Decision As A Process (DAAP)

Any procedure to take a decision among several people must be discussed, agreed and formally expressed in advance.  This blogpost is aimed to demonstrate the use of BPM and BPMN for expressing decisions as actionable patterns.

Parts of decision process:

• owner - entity which defined the decision process)
• organiser(s) - entities who execute the process
• audience for action (may depend on the subject) - people who express their opinion(s)
• audience for observing - people who are controlling that decision is taken in a fair manner
• rule for casting  - once or multiple (i.e. last)
• ballot power - equal (one person = one vote), more for the chairperson (1,5 vote) or depending on share 
• legal power of comments
• subject: data and documents - questions and potential answers for choice and/or comments
• duration (time-boundedness)
• security  - who can consult what and when, e.g. can one see choices of others
• rule to count that a decision was taken, e.g. > 50%, majority, >75% yes & < 10% no, etc.
• statistics - demographic of choices, who vote against whom, etc.

Some known decision patterns

1.  discussion forum (to informally reach an informal decision)
2.  e-consultation (to send us your comments before a particular date)
3.  e-approval (do you agree with that? )
4.  e-vote (official request to ballot with/without comments)
5.  e-poll (unofficial or limited request to ballot without comments)
6.  e-panel (discussion by an expert group)
7.  e-coediting (reaching agreement by editing the text and ballot on each paragraph)
8.  fully automated decision (audience for action is empty) a.k.a. business rules

Some business practices are combinations of decision patterns:

•  discussion forum + e-consultation + e-vote
•  e-consultation + e-vote
•  multi-level approval (practical process pattern DAM - http://improving-bpm-systems.blogspot.ch/2012/07/practical-process-pattern-dam.html)

Example of e-vote in BPMN  is at http://improving-bpm-systems.blogspot.ch/2013/07/practical-process-patterns-avs.html

Thanks,

AS

#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

Practical process patterns: Core Organisational Process (COP)

Formal consultations within an organisation is a very popular organisational process. And it looks very simple - just send a memo. This simplicity even confuses some technicians: in one organisation the IT Director has claimed that e-mail is enough to automate this process.

But, there are some complications.  Firstly, there are different consultations:

• Downstream – from a manager to subordinates (to prepare a reply to an incoming issue)
• Upstream – from a staff member to his/her manager (to obtain an official permission to do something)
• Peer – from a somebody to his/her peers (to inform your partners)

Secondly, it is a recursive process: the President sends a memo to Directors and each of them re-sends it to Divisional Managers who ask some of their specialists to prepare a reply.

Thirdly, some combinations of different consultations are possible. A staff member sends a memo to his/her manager with copies to colleagues concerned (upstream ) and the manager asks somebody to validate this memo (downstream).

Let us try to express all this complexity is the following diagram. There are four roles: Boss (who receives the issue), Reviewers (who are assigned to prepare a reply), CCs (who are just informed about the issues and final reply) and Workers (who, sometimes, must do something before sending the final reply).

Of course, there are a few tricks:

• Boss selects Reviewers, CCs and Workers dynamically.
• One of Reviewers may be a lead of a temporary group of Reviewers.
• There may be a decision process (should be another blogpost) among Reviewers.
• Coordination between Boss and Reviewers may be more complex than depicted in the diagram (e.g. Boss receives all replies by him/her-self).
• Reply (as a business object) life-cycle is not shown.

Thanks,
AS

Conference "BPM in Practice" Vinlius, Lithuania

A quick feedback from the conference "BPM in practice" in Vilnius, Lithuania. http://www.bpmpractice.lt/en/

I found very interesting the two following slides from the first keynote talk.

A nice linkage between the value and four types of improvements which are achievable because of the architecture works.

The transition from "structure maturity" (can be imposed) to "culture maturity" (can't be imposed)  is mandatory to consider if you target the highest levels of organisational maturity.

And my presentation is below (please note that some slides have animation).

Business Architecture Patterns (BPM in Practice conference) from Alexander Samarin

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