2014-01-23

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

At the application level the following should be considered:
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





Posted by Alex at 22:42
Labels: , , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)