BPM-EAI

So what do you mean by BPCC, BPM COE and BPMS COE?

A lot of time these are used interchangeably, however to me these are different concepts and should be managed differently.

Business Process Management Suite (BPMS) COE is all about formation of COE around the BPMS tool set which organization wants to rollout across organization. Typically BPMS COE has two primary drivers

• Maximize adoption of the tool in the organization to improve automation, tracking and quicker delivery of flexible composite application.
• Lower TCO  for adoption of this toolset

On the other hand Business Process Management (BPM) COE is all about the approach and methods one should use manage business processes better. This should not be mistaken as the method for delivering a business solution, instead it is about helping organization to discover its processes, identify the business metrics for the process, implementing the process where the business metrics can be measured and continuously improved. Typically BPM COE will be working with business team to enable them to identify, document, implement (Automate, Standardize) and measure their processes. BPM COE may sometime provide the required assistance in terms of approach to improve these processes; however the decision making authority exist outside the BPM COE. Typically BPM COE has process improvement & standardization driver in addition to the standard driver identified for BPMS COE

• Process Improvement & Standardization driver is to ensure maximum number of end to end processes is documented, measurements are identified and management reporting is provided for the process KPI. This should also be supported by automation initiatives for processes

Hence under BPM COE the focus changes from managing an all purpose tool, to enabling management of processes through process modeling, KPI modeling, Process information and simulation based continuous improvement and lastly KPI reporting to management.

Business Process Competency Center (BPCC) is all about management of Business Processes to deliver maximum business value. In BPCC the focus is on end to end business process to provide service to its clients, in a manner which will ensure complete customer satisfaction, with optimal usage of resources required by the process, at a lowest cost of execution, with minimal operation overhead. The differentiating concepts of BPCC are

• Formation of competency unit for a business process with business users to do
• Certain specialized activity within the process
• Improve adoption of systems across organization to improve operational efficiency of processes
• And lastly to conduct frequent improvement initiatives around processes (Like Lean Sig Sigma) for improving operational efficiency, reduce execution cost, improve customer satisfaction
• Unlike BPM & BPMS COE, BPCC's focus is not on the tool but on the set of tools that is used to implement the end to end process. Hence BPCC sits above all technology including ERP, Legacy etc.. which is part of end to end process realization
• Unlike BPM COE, BPCC needs to track Business Metrics rather than the process metrics. Hence BPCC inherently needs to define methods and approach for translating Business KPI's to Process KPI's before implementing process performance improvement.
• BPCC should manage process standardization and manage governance around processes across the organization

Sometime in various discussions people do ask me if these three different COE indicates any sort of maturity model.

My personal opinion is no. The reason being BPMS & BPM COE is typically driven by IT whereas BPCC is driven by business. In the case of BPMS COE, BPM COE can be potentially seen as its matured offering but I believe making the transition from a BPMS COE to BPM COE will be difficult if the same organization that had been running the BPMS COE is asked to convert it into BPM COE. However if an organization have multiple BPMS COE then it is important and beneficial for them to form BPM COE from these two BPMS COE.

Posted by Manas Kumar Sarkar at 3:02 PM | Permalink | Comments (0) | TrackBacks (0)

There are many stalwarts in the world of SOA and the Blogosphere is filled with blogs and articles defining SOA in very simple terms. However, the following is a humble contribution from a semi-developed technical brain.

Let us consider the example of the simple entertainment system in most of the households across the globe - the Television Set and the channels we see in the same. Taking this as an analogy, we can say that the enterprise called “household” needs a service called “entertainment”.

In the world of Enterprise IT, there is plethora of hardware choices that one can make, like mainframes, blade servers etc. with different capabilities based on the RAM, ROM and other peripherals one chooses, from different manufacturers. Likewise in the world of TVs there are many options ranging from Plasma, LCD, CRT based TV and manufactures ranging from ‘Chinese’ assembled to Sony or Samsung.

In the world of Enterprise IT, there are many out-of-the-box applications one can chose from or can have facility to build one from ground up. In the world of TVs we have the option of choosing the channels à la carte to a predefined set of channels given by the Direct-To-Home provider.

However, as long as the software and hardware meet certain requirements, it doesn’t matter which application is running on which hardware. A CRM application can run on mainframe, while a payroll application can run on Wintel based system - provided they adhere to certain standards mutually agreed upon.

Likewise, the channel the household subscribes is not dependant on the type of Television owned by the household. (Now do not say that Discovery HD cannot be rendered properly on a CRT based TV; but can make an impact on Plasma based TV). My whole point here is: *as long as the channels and the TV are built upon the standards of encoding the content, which are agreed upon, any TV can subscribe to any channel. Now we look at the guiding principles of SOA and how it applies to our TV at home. *

Loosely Coupled: Most of the TV sets in the world are manufactured to work with any format of broadcast and rarely does one see a TV set that is manufactured for only one particular channel. As long as the TV set adheres to the “common standard” the TV can be used to watch your favorite program on your favorite channel.

Standards Based: Most of the TV sets are based on the SCART defined reception mechanisms.

Abstracted: One need not know the internal working of the signal transmission, as long as they enjoy watching the program.

Composable: One can route the audio to surround speakers and project the screen on to a different screen/projector based on the needs. They can compose the way in which the channel needs to be viewed.

Modular: Most the components of the TV and the Satellite transmission are in form of modules, which one can replace on need basis. Like the audio booster, can be replaced without affecting the overall functioning of the TV set. This modularity that we see in the consumer electronics is a deliberate one, done with precision by skilled engineers. The right plug is accepted by the right port, which is the true definition of plug-and-play. We in Information Technology, still lag behind in brining this to the software world. In an ideal world, SOA services should be purely plug-and-play leading to instant enterprise mashups with a very low entry barrier.

Last but not the least, the control of the system is in the hands of business, not in hands of IT and can change dynamically based on the market needs. Remote Control of the TV is in hands of users, so to change a channel, one need not call a technician to do it, but a press of a button changes the channel. And also to change the channel from cartoons to live telecast of super-bowl, additional hardware is not needed, nor any installation of additional software; just a flick of a button.

Unlike SOA, where any application can be a consumer and provider at the same time, TV sets are currently only consumers, may be tomorrow there may be some sets, which also act as providers.

Posted by Anil Prasad Kurnool at 6:11 AM | Permalink | Comments (9) | TrackBacks (0)

In general mediation is a practice used in law to settle conflicts between two parties by a third party called the mediator.

In SOA where service contracts are created between a plethora of producers and consumers, there arises a need for mediation to provide sanity to the objective of of the overall concept of Enterprise Service Bus.

What could be the principles and prospective candidates for Mediation? Let’s look at them…

One of the google searches on service mediation leads to this link in soamag. This page has a good prescription on use cases for service mediation in general. Taking forward from here, any SOA implementation should look at the following principles and cases:

1) Service virtualization is the primary driver for implementing an ESB, and most other use cases are variations of it. Mediation thus is one such case to ensure virtualization.

2) SOA works best when there are clear logical layers separating the different types of services. One rule most of the implementations miss is ensuring only top level business services are exposed on your Enterprise Service Bus (ESB). This means that if a service registry’s taxonomy is in place then in that hierarchy these services would be in top and they should be course-grained business objects. For e.g. for a banker approving a loan the business process “credit approval” is the coarse grained process should be available on ESB. What credit approval does to get the required data such as customer details, account details, etc are fine grained or a mix of coarse grained and fine grained that need not be exposed on ESB. Out of the box mediation in ESB will ensure the interaction between the top level service and other services are configuration based and not required to be coded in either of the services.

3) The previous rule doesn’t translate as “ESB should be one” and all other services should not be hosted on a bus. The layered SOA structure should have the ESB that is truly enterprise wide cutting across business units and thus having only the critical and common (reusable) cross grained business services. Down this layer there could be other service buses performing their own hosting of services and thus even requiring mediation in each of these service buses. As previously posted there is no one size fit all SOA architecture. Each organization, enterprise would need to find out what best suits them and grow upon it.

4) Having this rule in place, any BPM implementation or writing a BPEL becomes easier and directly translates to solving a business problem or redefining a business process. The objective is to cut the deficit between business and IT.

5) Obviously the ESB would now require “mediation” to translate the exposed business services to depend on the underlying technical services which could be composite service of multiple EJBs, a service that is in based on REST or wrapped service on legacy program and so on.

6) The non functional aspect about these service assemblies performing these tasks of mediation would need to be logically categorized in an IT specific way to ensure maintenance is easy; availability of critical components are in a separate infrastructure, performance and single point of failure are avoided etc. are taken into account.

The above points and the referenced pages are just an indicative list to bounce off ideas for an Enterprise Architecture Evangelist or Business sponsor looking for an Service Mediation in a new or existing implementation. There are detailed mechanisms to come to the right fit and pattern including positioning of BPM, EAI and SOA product vendors.

Posted by Narayanan Chathanur at 5:18 PM | Permalink | Comments (0) | TrackBacks (0)

Posted by Ravi Shah at 9:41 PM | Permalink | Comments (0) | TrackBacks (0)

Charles Darwin's "Survival of the Fittest" phrase is old but still powerful and is very much true in today's competitive market place. Every company tries to grab the market share and gain competitive advantage. With the advent of information technologies and frameworks, the gap between competitors has been reducing considerably and every company seeks innovative ways and means to broaden this gap. The Cloud BPM and SOA are some of the hot trends which every company embraces for improving its service capabilities and reach thereby reducing the costs and time to market.

According to Porter, Organization should adopt to one of the three strategies namely Cost Leadership, Differentiation and Market Segmentation to gain competitive advantage. Let's analyze how each of these strategies is achieved. Cloud enables an organization to achieve Cost leadership through its economic efficiency by avoiding capital expenditures on software and services. Business Intelligence achieves differentiation through real-time data mining and predictive analytics by offering intelligent value added services.

In my views,

Adaptive Competitive Advantage (ACA) = Collaboration of (Cloud, BPM, BI)

Adaptive competitive advantage is achieved by being proactive, agile and responsive to market conditions. Collaboration of Cloud, BPM and BI would be enablers for achieving adaptive advantage. Business Intelligence through data-analytics triggers changes in Business Processes and cloud provides a dynamic infrastructure. All these three coupled together offers Customer Innovative solution offerings ahead of competition and Customized deals based on real time analysis of user patterns.

Take the case of Telecom sector, with Mobile Number Portability (MNP) in place the switching costs for customers is zero. To be competitive, every service provider has to bring about innovative and value added offerings at the earliest. Collaboration of Cloud, BPM and BI offers Competitive advantage in this scenario. The service provider can retain some of its key BPM in-house and rest in a third-party hosted cloud platform thereby reducing cost. BI retrieves customer past usage and purchasing history real time and suggests appropriate value added services by triggering the necessary process flows.

In a nutshell, the collaboration of Cloud, BPM and BI offer Cost-efficient and real-time decision making capabilities, Creation of Enterprise Mashups by combining loosely-coupled IT assets, Increases ROI of BI investments and creation of automated intelligent applications, Proactive monitoring of key KPIs' and thereby rectifying problems as they occur.

Posted by Saravanan Balaraj at 9:01 AM | Permalink | Comments (0) | TrackBacks (0)