#IoT as a system of digital contracts (thanks to #blockchain, #BPM, #ECM and #cryptography)

Ability to work together is one of the essential enablers for the civilisation. At present, countries, companies and individuals can work together. Considering the current huge interest to the IoT, this blogpost outlines how to enable the things also working together with other things and people.

From the three following definitions of IoT, the last one is the better fit with this blogpost goal.

1. Wikipedia states that “the internet of things (IoT) is the network of physical devices, vehicles, buildings and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data”
2. The IoT European Research Cluster (IERC) definition states that IoT is “A dynamic global network infrastructure with self-configuring capabilities based on standard and interoperable communication protocols where physical and virtual “things” have identities, physical attributes, and virtual personalities and use intelligent interfaces, and are seamlessly integrated into the information network.”.
3. The Alliance for IOT Innovation (AIOTI) report http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11810 says “The IoT represents a concept and a paradigm that considers pervasive presence in the environment of a variety of things/objects that through wireless and wired connections and unique addressing schemes are able to interact with each other and cooperate with other things/objects to create new applications/services and reach common goals.”

A typical pattern for working together is the following – establish a contract, carry it out and close it. Considering that the things understand very well digital information, a contract must be digital to be used by the things.

As explained in “Digital contract as a process enables business in the digital world (thanks to #blockchain, #BPM, #ECM and #cryptography)” http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html, a digital contract is an explicit and machine-executable process between several business-entities, primarily, things and people.

For example, a new future household fridge will have as minimum four types of contract simultaneously: 1) with people who are living a particular household, 2) with a producer and service company for this fridge, 3) with some online shops to order various food, and 4) with all other things within a particular household to achieve together some goals of energy consumptions.

In general, the things are contracted to cooperate with other things and people differently:

• orchestration of several “slaves” by one “master” (also known as strong coordination)
• choreography of two or more business-entities (also known as contractual coordination)
• goal-achieving by a group of participants, like a football team (also known as weak coordination)

Of course, the same thing holds different roles in different digital contracts.

Fortunately, digital contracts as explicit and machine-executable processes are powered by BPM which already knows how to handle all these complexities.

But, can BPM-centric digital contracts provide necessary processing for high data volumes are being generated? Yes, with the help from microservices. Let us consider that all automation activities in a process are implemented as microservices (which are potentially externalised from a business process engine).

Firstly, each process (actually a digital contract) may be executed in a partially independent environment – only a common part would be a blockchain with all the records (or audit trails).

Secondly, each running process can anticipate what microservices will be required and can prepare secured and individual instances of microservices (with one-time passwords).

Imagine a football match. The venue starts an individual “customer” process for each person on the stadium. Knowing the customer, such a process prepares microservices which are the most probably used by this person.

Thanks,
AS

Digital-contract-as-a-process enables business in the digital world (thanks to #blockchain, #BPM, #ECM and #cryptography)

In this blogpost I aim to outline how a combination of modern technologies (including the blockchain technology, BPM and cryptography) can enable good practice for carrying out business in the digital world. Such a combination enables 1) the establishment, 2) the execution and 3) the imposition of digital contracts digitally, quickly, surely and (potentially) legally. Thus a digital contract enables business can be carried out fully digitally, with less risk and fewer resources.

Related blogposts:

• “Electronic Health Records ( #EHR ) implementation with #blockchain, #BPM, #ECM and #platform” http://improving-bpm-systems.blogspot.ch/2016/07/electronic-health-records-ehr.html
• “Disassembling #blockchain concept” http://improving-bpm-systems.blogspot.ch/2016/06/disassembling-blockchain-concept.html
• “Will the right use of #blockchain make the records management obsolete?” http://improving-bpm-systems.blogspot.ch/2016/04/will-right-use-of-blockchain-make.html
• “#entarch view on #blockchain” http://improving-bpm-systems.blogspot.ch/2016/01/entarch-view-on-blockchain.html

1 Starting from good business practice

One of the major prerequisites for doing business is a guarantee that all the risks relating to working with somebody else (potentially a stranger) are properly addressed (mitigated, hedged, etc.). A recurrent pattern found in good business practice comprises the following actions:

1. document, as a legally binding contract (which is voluntarily approved by all the business parties), all the related business relationships, responsibilities, conditions, activities, performance indicators, schedules, conflict resolution procedures, etc.;
2. impose the execution of this contract on all the business parties;
3. impose agreed liabilities on some business parties.

Let us try to combine several modern technologies to implement this good business practice such that it

• is fully digital (without need for the mandatory involvement of middlemen such as lawyers or escrows),
• is legal (admissible in courts) – of course, after necessary governmental decisions,
• is universally accepted (unrelated to location and nationality), and
• has negligible cost and overhead.

One of these technologies is the blockchain technology which enables the creation of immutable, tamper-proof and transparent records https://www.linkedin.com/pulse/summer-reading-viewing-update-blockchain-arno-laeven ). Despite the existing hype around it ( see https://theconversation.com/blockchain-really-only-does-one-thing-well-62668 and https://medium.com/@pavelkravchenko/decline-of-blockchain-hype-and-rise-of-a-common-sense-8de5789a794d#.olmj0go1e ), the blockchain technology is mandatory for doing business in the digital world but alone it is not enough.

Potentially, digital contracts will further develop and properly implement promises of “smart contracts” blockchain-based applications which are rather overhyped ( see http://www.coindesk.com/smart-contract-myths-blockchain/ ).

2 Digital contract as an explicit process

The key of doing business properly is a contract which is an agreement with specific terms between two or more business parties in which there is a commitment to do something in return for a valuable benefit known as consideration.

A good contract must have several factual elements. They are listed below together with some modern technologies and methodologies which enable those elements in the digital world. In general, any promise, commitment, document, written or oral (e.g. by Skype) communication between business parties (which are involved in a contract) is secured by the blockchain technology. The last is acting as immutable, tamper-proof and transparent storage of records.

• a commitment to perform – is enabled by business processes (and BPM) as a formalised description of some activities to be carried out;
• a valuable consideration (which can be a commitment or payment in some form) – is enabled by business processes (and BPM) as a formalised description of some activities (i.e. payment) to be carried out;
• a time or event when activities must be initiated (to meet given commitments) – additional detailed characteristics about scheduling and coordinating activities to be carried out; scheduling and coordination can be formally expressed by various coordination techniques (see http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html );
• terms and conditions for performance, including fulfilling commitments – can be formally expressed with various decisional business rules (also known as decision management) and behavioural business rules.
• demonstrated performance – can be collected and treated by fact-based performance indicators, business performance reporting and fact-based predictive analytic;
• an offer – is actually part of the contract how it is proposed by one business party, e.g. service provider; thus an offer can be formally expressed with all the mentioned about technologies and methodologies;
• an acceptance of that offer which results in a meeting of the minds – various cryptographic technologies and document management help to enforce integrity of documents, identity and authorization of business parties and confidentiality of all documents and communications.

Thus a contract can be formally expressed as an explicit business process which comprises:

• pertinent business assets (goods to be delivered, payments, etc.);
• agreed business activities to be carried out by the business parties and necessary inputs, outputs, guidance and resources for those business activities;
• planned coordination between activities – which business party is doing what, when and for how long;
• some business events – things that happen or take place which are considered important for this contract; they can serve as stimuli for starting of some activities or changing the way of contract fulfilment;
• business rules used – various formally-defined logic;
• audit trails – collection of records in accordance with good business practices;
• agreed performance indicators – how well all the business parties are fulfilling their commitments. 

The table below shows primary (P) and secondary (S) relationships between contract concepts (rows) and process concepts (columns).

It seems that a contract can be expressed as an explicit business process with a level of formalism which is understandable by all the business parties (thanks to popular visual notations for coordination and business decisions).

3 Digital contract as a computer-executable process

By definition, a contract is a description of expected behaviour of all the business parties. With a classic contract, each business party is accountable for its behaviour and no one has a full and objective overview. In some cases, to mitigate this risk or to speed-up the execution of a particular contract, a lawyer or a notary may be assigned to conduct the execution of activities of a particular contract.

Having digital contract defined formally as an explicit process, there is no need for extra human to conduct the execution of a contract. Such a “conductor” can be a robot (i.e. a computer, actually some software tools, known as BPM-suites) – let us call it “digital” lawyer (or arbitr).

Actually, not a robot or computer, but some software tools, known as BPM-suites.

Thus, all the business parties may agree that a particular “digital” lawyer can be the conductor for a particular contract. Another option is that each business entity assign their own “digital” lawyer and those “digital” lawyers have to reach agreements about everything that happened with a particular contract.

In addition to “digital” lawyer, a “digital” notary may be required to record everything that happened (i.e. audit trails) in a private storage  ( see privacy concerns at http://www.americanbanker.com/news/bank-technology/banks-privacy-concerns-shaping-blockchain-vendors-strategies-1090411-1.html ) and deposit related digital signatures (or hashes) into a public storage implemented with the blockchain technology.

Also, a “digital” lawyer may act as a “digital” escrow if accepted by all the business entities.

It must be clear that any complex contract (therefore any contract as a process) does not cover all the exceptional situations which are usually addressed by a court.

An interesting “by-product” of contract-as-an-explicit-and-computer-executable process is the ability to simulate (or imitate) the execution of a digital contract under the various scenarios (e.g. WHAT-IF scenarios). Thus the business entities can be fully informed about any potentials traps in a contract they are supposed to approve.

From the BPM point of view, digital contracts coordinates two or more cross-business-entities co-processes. Without a digital contract those processes (see the left part of the illustration below) have to coordinate the joint work by themselves. While adding a digital contract (see the right part of the illustration below) makes the coordination explicit and easier to implement (that is important for small contracts).

  

4 Digital contract lifecycle

There are several phases in the contract lifecycle:

• three sequential phases: preparation, execution and closure; 
• one overarching phase: monitoring, and 
• one discretionary phase: exception handling. 

Contract preparation is a typical document-centric process for drafting, validation and approval of a particular contract. Note that a digital contract may be composed (or assembled) from several parts, for example:

• the business entity’s general requirements for contracts;
• contract-specific requirements, e.g. consulting vs goods, local vs international, and
• contract-specific information (including the identity of contractors).

Obviously, some of those parts can be approved once and re-used many times. Additionally, the whole contract and some of its parts may be simulated with some scenarios to estimate associated traps, risks, benefits and losses.

Contract execution is a formal enacting of a particular digital contract-as-a-process by some software. This software acts as a “digital” lawyer and it is responsible for coordinating activities which are assigned to related business entities. For example, a buyer must pay to a vendor an agreed amount of money and then this vendor must deliver some goods to this buyer. Some activities may be assigned to the “digital” lawyer as well.

Also, the “digital” lawyer may act as a “digital” notary to keep the records of everything that happened with a particular contract.

Contract closure is an additional activity to ensure that all the business entities agree with the execution of a particular contract.

Contract monitoring is a permanent activity for controlling that a particular contract is executing correctly.

Contract exception handling is a set of activities to be initiated if something went wrong with a particular contract. Such situations may involve a “digital” judge.

5 An example of doing business fully digitally

In this example, a buyer wants to purchase some digital assets (a personal copy of a digital book or a car renting certificate) from a vendor. Both of them can use only digital money. Because the buyer and the vendor don’t trust each other, they engage an independent “digital” lawyer to conduct this purchase via a digital contract. This “digital” lawyer explicitly acts as an escrow and a notary as well.

The desired sequence (also known as happy path) of activities is the following.

Activities during the contract preparation phase:
1. Vendor and Buyer: Engage a “digital” lawyer via a standard digital contract
2. Vendor: Propose contract
3. Lawyer: Validate contract
4. Buyer: Accept contract
5. Escrow: Seal contract

Activities during the contract execution phase:
6. Buyer: Transfer money to escrow
7. Lawyer: Announce payment to vendor
8. Vendor: Deliver goods
9. Buyer: Announce acceptance of goods
10.Lawyer: Transfer money to vendor

Activities during the contract closure phase:
11.Lawyer: Close the contract

The same sequence with more details.

1. Vendor and Buyer: Engage a “digital” lawyer via a standard digital contract

• They engage a certified “digital” lawyer via a standard digital contract (which is digitally signed by some legal authority).
• The standard digital contract and identities of three business entities forms an engagement contract.
• This engagement contract is digitally signed by three business entities (with their private keys).
• A digital hash of the signed engagement contract is saved as a record (the lawyer acts as a notary). 

2. Vendor: Propose contract

• The contract is digitally signed by the vendor (with his/her private key).
• A digital hash of the signed contract is saved as a record.

3. Lawyer: Validate contract

• The contract is validated by the “digital” lawyer.
• The validation report is digitally signed by the “digital” lawyer (with its private key).
• The contract signed by the “digital” lawyer (with its private key).
• Digital hashes of the signed contract and validation results are saved as records.

4. Buyer: Accept contract

• The validation results are analysed.
• The contract is digitally signed by the buyer (with his/her private key).
• A digital hash of the signed contract is saved as a record.

5. Lawyer: Seal contract

• The contract (which is already signed by buyer and vendor) is signed by the “digital” lawyer.
• A digital hash of the signed contract is saved as a record.

6. Buyer: Transfer digital money to the “digital” lawyer

• The agreed amount of digital money is transferred by the buyer to the “digital” lawyer.
• This transaction is saved as a record.

7. Lawyer: Validate the payment

• The “digital” lawyer (acting as a “digital” escrow) validates that the right amount of money has been transferred. 

8. Vendor: Deliver digital goods

• The vendor change the ownership of the digital assets to be sold in accordance with the contract.
• This transaction is saved as a record.

9. Buyer: Announce acceptance of digital goods

• The buyer confirms the reception of the digital goods.
• This transaction is saved as a record.

10. Lawyer: Transfer digital money to vendor

• The “digital” lawyer (acting as a “digital” escrow) transfers the digital money to the vendor.
• This transaction is saved as a record.

11. Lawyer: Close the contract

• The history of the contract is prepared and shared with the buyer and the vendor.
• This history is saved as a record.

Again, this is only a happy path without any problematic situations. Important that all the procedural formalities can be implemented exactly in accordance with the legislation of a particular country. Because of the detailed audit-trail which is saved as records, any disputes about a particular contract may be resolved by a “digital” judge.

6 Conclusion

Both characteristic, “explicit” and “computer-executable” of digital contracts are equally important. For example, smart-contracts are computer-executable but they not explicit because they are pieces of code which is not understandable by some business parties. Also, some traditional laws contain typical process diagrams (see http://improving-bpm-systems.blogspot.ch/2014/07/practical-process-patterns-laap.html ) to become more explicit, but they are not computer-executable.

Thanks,
AS

Electronic Health Records ( #EHR ) implementation with #blockchain, #BPM, #ECM and #platform

This blogpost is an updated version of the chapter 3 from “Technology enabled healthcare transformation” ( see http://improving-bpm-systems.blogspot.ch/2014/07/technology-enabled-healthcare.html ).

The main concept is that a person (or his/her legal representative) is the only the owner of his/her personal EHR. Other participants in the healthcare may use some of the person’s records only within some explicitly-defined contexts.

The following technologies are employed:

• Platforms (including CURE platform): http://improving-bpm-systems.blogspot.ch/search/label/%23platform
• Blockchain: http://improving-bpm-systems.blogspot.ch/search/label/%23blockchain
• Security: http://improving-bpm-systems.blogspot.ch/2015/01/enrich-rbac-and-abac-with-probac.html
• Enterprise Content Management (ECM) including electronic document management
• Business Process management (BPM)

Special thanks to Charles Webster MD @wareFLO https://twitter.com/wareflo for a review of this article.

1 General definition from www.healthit.gov

www.healthit.gov defines person’s Electronic Health Records (EHR) as, at their simplest, digital (computerized) versions of patient's paper charts. In other words, a person’s EHR is a set of all the health-related records of a particular person which are available in some digital formats. But a person’s EHR, when fully up and running, are so much more than that.

A person’s EHR is real-time, patient-centred records. They make information available instantly, at any time, in any place and from any device. And they bring together in one place everything about a patient's health. A person’s EHR can:

• Contain information about a patient's medical history, diagnoses, medications, immunization dates, allergies, radiology images, and lab and test results.
• Offer access to evidence-based tools that providers can use in making decisions about a patient's care.
• Automate and streamline providers' workflow.
• Increase organization and accuracy of patient information.
• One of the key features of a person’s EHR is that it can be created, managed, and consulted by authorized providers and staff across more than one healthcare organization. A person’s EHR can bring together information from current and past doctors, emergency facilities, school and workplace clinics, pharmacies, laboratories, and medical imaging facilities.

2  EHR as a component of the healthcare platform

The EHR component is a tool which operated many person’s EHR.

Certainly, the EHR component is the core of component of the healthcare Common Unified Business Execution (CUBE) platform and an implementation of the EHR component is a must. Within the healthcare CUBE platform, the EHR component can be architected in accordance with this conceptual view.

3 A bit of cryptography

• Hashing is a cryptographic procedure to map a digital object of arbitrary size to data of fixed size (called “hash”). Features: easy to compute, irreversible (not feasible to generate original digital object from its hash), commitment (any change in the digital object changes its hash) and collision free (not feasible to find two digital objects with the same hash). 
• Public and private keys are a pair of keys of asymmetric cryptographic algorithm. A digital can be encrypted by one of those keys and decrypted by the other one.
• A digital signature is a hash of a digital asset (e.g. a message, document, data) encrypted with the owner’s private key. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, that the sender cannot deny having sent the message (authentication and non-repudiation), and that the message was not altered in transit (integrity).

4 Records keeping

A person’s EHR are kept in a private storage which is accessible only by the owner (i.e. this person). Records are encrypted by person’s public key (thus only the owner can decrypt them with his/her private key). If the private key is compromised then the records must be re-encrypted with another private key.

The digital signature of a record is kept in a public storage which is based on the blockchain; thus, thanks to blockchain, no one (even the owner) can change this digital signature and thus everyone can check that the record has not been changed even by its owner.

Traditionally, personal healthcare records embed the name of a person (denominated record) thus creates a problem between the person’s privacy and the use of his/her EHR for medical research activities. A solution of this problem is to have anonymised version (anonymised record) of traditional personal healthcare records.

From the point of view of the enterprise content management, a denominated record is a composite (or compound) record which comprises anonymised record (some medical information) and some personal information. Some medical organisations already practice anonymisation of some records by replacing a patient’s name by some identifier. For example, a blood sample container has a barcode (or RFID) which is also attached to patient’s information page. Also, an identifier is used to hide a patient’s name in communication with external service providers such medical tests labs.

5 Records exchange

A typical practice of electronic document distribution is to add an annotation (e.g. as a watermark or running header or footer) to whom a particular copy of the electronic document has been sent. Finally, this personalised record is electronically signed by the distributor.

6 Context for records exchange

Ideally, all the records must be originated as anonymised version and be explicitly associated with the name of a patient when necessary (so called late-binding approach).

A person (or his/her legal representative) is the only the owner of his/her personal EHR. Other participants in the healthcare may use some of the person’s records only within some explicitly-defined contexts. Other participants in the healthcare must explicitly request some person’s records (e.g. lab tests, etc.) from the owner (i.e. the patient). Such a request must be executed only in the context of a well-defined process/workflow/case in which the patient and the requestor are involved (see 2.5.3 in the original article).

The exchange uses the concept of “deposit box” which is a short-life-time (temporary) private storage for the each act of exchange. A deposit box is accessible by the record’s owner and, then, the record’s recipient. Imagine that some paper documents were copied and put in an envelope. Some deposit boxes may be protected by a one-time password. Such a deposit box can be part of a particular process case.

7 Use case 1 – from a patient to a medical office (i.e. a doctor)

Below is an example of how the exchange between a patient and a medical office should be carried out (keep in mind 2.5.6 in the original article). The situation: the patient made an appointment to visit a doctor. The catalogue of the patient’s records (title, date and some other metadata only) is made available for the doctor. The doctor has indicated which patient’s records are necessary for this visit. The patient has to send some of his/her records before the visit. After the visit, the doctor sends to the patient some new records. See a process fragment below.

Records exchange is carried out in the following way (see the red markers in the illustration below):

1) As part of the “visit doctor” process, the patient got a task to send a list of his/her records to the doctor.

2) Anonymised versions (ideally) of requested records are annotated (by indicated to whom this copy is to be sent) and they are additionally protected by:

• a. the doctor’s public key for this patient;
• b. maybe, the process case private key which has a short life-time and, 
• c. maybe, an one-time password.

3) The protected records are uploaded to a deposit box.

4) Hashes of all those records are sent in a public storage.

5) A link to this deposit box is communicated to the doctor (actually, to his/her) medical office.

6) The records from the deposit box are fetched, decrypted and validated (via hashes which are stored in the public storage) by a medial office employee to store them into a private storage of this medical office.

7) The deposit box is “destroyed”.

8 Use case 2 – from a medical office (i.e. a doctor) to a patient

The flow of data is indicated by blue markers in the illustration below.

9 Private storage, public storage and deposit box implementation

A private storage is a cloud-based protected and encrypted storage. For example, https://www.securesafe.com/en/

A public storage is a public blockchain. It is used to validate the integrity of records because a hash for each record is stored in the public storage. Metadata are very important.

A deposit box is a protected short-life storage which can change the owner only one time – think about an envelope. Each particular process case may have several deposit boxes. Each of them may be passed from one process participant to another.

Secure exchange may be built on the Open Whisper technologies - https://whispersystems.org/ 

10 From your current EHR to the common ideal EHR

It will be in one of next blogposts.


Thanks,
AS

Webinar “Ask the Architect on Enterprise Architecture & High-Impact Strategies” #entarch #bizarch #apparch #BPM #SOA

I will be giving a webinar “Ask the Architect on Enterprise Architecture & High-Impact Strategies” – see http://live.icmgworld.com/index.php/all-events.html?parent=1352 for the schedule and http://live.icmgworld.com/index.php/more-services/webinars/webinar-ask-the-architect-on-enterprise-architecture-high-impact-strategies-detail.html for the product description. 

Various questions related to EntArch, BPM, SOA, BizArch, AppArch, ECM, etc. will be discussed.

People from my professional network (LinkedIn, Twitter, SlideShare and Google+) may use the following gift certificate.

Thanks,
AS

Presentation at a #BPM mini-conference in Bergen, Norway

My presentation at BPM mini-conference in Bergen, Norway on 2014-05-06.

How EA, BPM, SOA and ECM work together from Alexander Samarin

As I didn't have a ready-to-show presentation "How can a company benefit from implementing BPM", I promised to provide a blogpost with this title.

It was first time I gave a presentation in a brewery.

Thanks,
AS

#entarch, #bizarch, #BPM, #SOA, #ECM and patterns are working together, example 1

Recently, I was involved in a few discussions about what should be a target enterprise architecture for a decentralised enterprise. For example,

1. “Bank decentralisation” - bank wants to build the international presence and thinks about decentralisation, 
2. “Rationalisation of acquired businesses” – company, which bought several hundred businesses wold-wide, would like to align them, 
3. “Legacy ECM modernisation” - already distributed company wants to modernise applications (mainly based on ECM) at its local branches. 

The main concern of the target enterprise architecture is the enterprise application architecture. How to build an inexpensive (no duplications) and flexible (easy to innovate) business-execution environment?

As the first case “Bank decentralisation” has more input, it will be used further as the base. Only additional considerations will be mentioned separately for two other cases.

The situation

Now Bank establishes branches at international locations and there is a need to customize products and services, as well as processes (Currency Management, Risk and Compliance, etc.), as per a given location, i.e. Local Office (LO).

At present, there is a BPM practice at the Bank, i.e. at the Global Office (GO). Processes for Front Office, Back Office and Middle Office are identified for four levels. Also known list of technologies, applications and databases which are supporting business functions. No Enterprise Architecture in place. Plan is to set up an EA practice with a complete Enterprise Architecture in place.

Questions

1. Set of processes for the GO may be customised to the needs of a LO. How? Shall the structure of processes be the same? Shall separate BPM practices be established at each location? If “yes” then how to exercise the centralised control?

2. How to manage data for Global Operations and how services will relate to information required from various Local Operations and how processes will support that (say a Centralized Reporting System)?

3. What would be Enterprise Architecture for the Bank (what capabilities, processes at a global level, how capabilities interoperate, what will governance mechanism, what will be centralized functions etc.). How various change activities will be managed?

4. Centralized BPM practice or separate BPM practice for individual locations?

Answers

Sure, it is mandatory to have a solid EA practice to carry out the change like decentralisation. Also it is mandatory to achieve the synergy between BPM and EA.

Platform

When an enterprise is going to operate from various locations (with potentially different capabilities) then a corporate platform for the business execution should be created and deployed at each location to avoid unjustified duplications among various locations.

The enterprise pattern PEAS outlines the design of such a platform ( http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS  ).

BPM (as a trio of discipline, practice/architecture and tools), should be the primary component of the platform to allow easily combining of common services/processes/patterns with location-unique services/processes. In some sense, BPM with executable processes is a tool for assembling business solutions from services.

De facto, this is a step towards SOA which is an architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services. SOA re-shapes the enterprise application architecture from the provisioning of monolithic applications to the assembling solutions from a validated set of in-house, commercial, open-source and rented services. (Service is an explicitly-defined and operationally-independent unit of functionality).

The proper use of BPM/SOA affects all levels of enterprise architecture:

• business – identification of processes and services from the business context;
• application – implementation and assembling of processes and services;
• data – transportation of data between services, and
• technology – running and monitoring processes and services not applications which may increase the number of units of deployment by factor 50.

At the business level, the following should be considered:

• Enterprise pattern “Anisotropically Distributed Organisation” (ADO) - http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html - handle variations between GO and LOs;
• Modelling procedure - http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html - to have a common way for finding processes and services ;
• Business Decision Management (or business rules at the business level) as different LOs may have different decisions, and
• Other process patterns ( http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns ), 

At the application level the following should be considered:

• The pattern “Cloud-Aware Processes and Services” (CAPS) - http://improving-bpm-systems.blogspot.ch/2011/07/enterprise-patterns-caps.html - to have a common structure for process-centric applications ;
• Cloud-related patterns- http://improving-bpm-systems.blogspot.ch/search/label/cloud - to have common rules for putting services into clouds , and
• Other enterprise patterns - http://improving-bpm-systems.blogspot.ch/search/label/enterprise%20patterns

Two examples can be useful as well:

1. e-government - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-e-government-and-e-governance.html , and
2. healthcare - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-to-help-heathcare.html .

Information collection

To collect all necessary data, processes should be enriched to proactively push business and execution data to required local and central repositories. Very similar to the http://improving-bpm-systems.blogspot.ch/2011/10/ea-view-on-enterprise-risk-management.html .

IMPACT on EA; governance and capabilities

Knowledge of “list of technologies, applications and database” is necessary but not sufficient for executable processes. Usually, more granular artefacts must be known: services, data structures (XSD), documents, KPIs, roles, rules, audit trails. EA will certainly is the right tool to find them and BPM is the right tool to link them together as executable processes. Again, the challenge is not only to add EA practice, but also to achieve the synergy between EA practice and BPM practice.

The GO provides a standard set processes, services and other artefacts; any LO may have (limits are explicitly defined) its own local set of customised processes / services and other artefacts (as a local copy of standard one). All processes, services and other artefacts are are under strict governance (versioning, life-cycle, etc.). Several version of the same artefacts may co-exist. If a LO uses a standard version of process/service then it can be executed centrally or locally or cloudly. See enterprise pattern #Cloud-Ready Estimation and Evaluation Procedure (CREEP) - http://improving-bpm-systems.blogspot.ch/2011/12/enterprise-pattern-cloud-ready.html to formalise the choice of the cloud.

It is important to establish good terminology (including relationships between capabilities and processes - http://improving-bpm-systems.blogspot.ch/2013/03/bizarch-artefacts-definition-again.html ) and make explicit the relationships between business and technical capabilities - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html ).

Platform Centre of Experience (COE) organisation

It is necessary to talk about platform COE not just BPM COE. The target topology is a combination of the central/global COE (reflection, global optimisation, standards) and local/regional COEs (client care, flexibility, assembling of solutions).

The central COE distributes new services, new version of old services, new processes and new version of old processes. Local COEs estimate the impact and update their customised processes if necessary.

Case “Rationalisation of acquired businesses”

Pattern “Eclipse” shows how the transition from applications to processes & services - http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html ,

Case “Legacy ECM modernisation”

The important requirement for the modernisation of legacy ECM is that current encoded-in-code business processes become explicit and executable (by BPMs) business processes. This will a) enable the future optimisation without big changes and b) avoid the repetition of the existing approach with new technology. So, such a modernisation is a transition from ECM to ECM+BPM.

Thanks,
AS