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

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



#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.
Technology-enabled techniques
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
A patient can visit a doctor remotely
Video conferencing.
Avoid hassle for trivial cases.
Better traceability.
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.
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.
Patient is guided for home-based treatment
Predefined coordination and alerting (e.g. for taking pills).
Systematic monitoring.
Better supervising
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.
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.
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.


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



#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
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?

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



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



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:

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



#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:


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.


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



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