BPM, E2.0 @Oracle

My first blog post in Oracle. So, I’ll start with a tribute to a mentor and a friend.

When I first joined Plumtree 5+ years ago, there was so much to learn: Portal, search, collaboration, publisher, content, architecting the whole set etc. I was thrust deep into an implementation primarily because the deployment was on UNIX and I knew UNIX (at least I knew enough to fumble my way around).

As you can guess, I ran into installation problems (hey that was the old 4.5WS on UNIX after all) and given the baffling nature of these problems, quite a few people stepped up to help me. But one guy stood out by the sheer quality and detailed suggestions to resolve the problems. And his solutions worked. Oh, he was also helping others who had hairy issues too. His name is Gerald Kanapathy.

A couple of months later, we had our first kick-off in Vegas and the PS team had its own breakout sessions. When Gerald was introduced as the speaker, someone behind me muttered with a mixture of both awe and reverence: “Yeah, that’s the Plumtree God”. Since then, Gerald’s reputation was cemented in my mind. In our 2004 kick-off, he was nominated (and won) for Best Employee Award or something similar and one the nominators wrote: “He’s the guy we folks in engineering go to when we are stuck.”

For those of you ALUI (now WebCenter Interaction) afficionados, Gerald used to run a blog on dev2dev@bea where he shared a lot of his invaluable knowledge and experience on technology, the WebCenter Interaction product and Web 2.0 with us lesser mortals. He has graciously shared the posts with me and now I can in turn share it with you. In the coming weeks, I’ll be republishing them here.

I hope they will be useful to you as they have been to me.

Cheers,
Ali

I’ll start fairly easy with an introduction of BPM. I won’t be going into products, standards etc., well not yet anyway. So, let me start by defining BPM:

BPM is a strategy for managing and improving the performance of the business through the continuous optimization of business processes in a closed-loop cycle of modeling, execution and measurement.

You’ll note that there’s no reference to technology, vendor, tools, methodology or any such things. In other words, to quote Paul Strassman (albeit in a different context), “it’s economics [..] technology has to be taken for granted”. You could arguably do BPM without any technology but if you do make a successful use of BPM technology, then the return on your investment is potentially much higher.

Let’s look at the context for the use of BPM technology in the enterprise. A business process is a complete, coordinated sequence of serial and parallel activities needed to deliver value to a customer. Some of the characteristics of business processes are:
• Enormous and complex data and business flows
• Dynamism due to rapidly changing market conditions
• Partial automation
• Dependence on human involvement and judgment
• Display of life cycle characteristics

As processes are the basis of planning, marketing, customer transactions, billing and reporting, they become the unit of improvement, competition, intellectual property and differentiation.

However, the enterprise is not organized around processes. Instead, they are organized around individual business units such as finance, legal, HR, manufacturing, sales and such. In large enterprises, this can be even replicated geographically. Each unit is generally enabled by best-of-breed applications such as CRM, billing sytems, databases and custom applications etc. This is not necessarily a bad thing. It is in fact a natural evolution of the specialization of jobs in the enterprise.

Bruce Silver remarked that processes that run within these single business units or on single systems (I’ll collectively call them silos) are already automated and arguably efficient enough. But the price of that automation has been the creation of new silos or “white spaces” between business units or systems. End-to-end business processes will span those silos, thus causing a loss of both context and potentially accurate and up-to-date data between these silos. This loss can have a direct influence on both worker productivity and the decisions they take.

Typically, what knowledge workers tend to do is use several productivity tools e.g. IM, email, documents or they just swivel around or pick up the telephone to talk to a co-worker. This shows that they can survive those the problems created by the white spaces. While they survive, they don’t necessarily thrive. This is where BPM technology shines. As Bruce Silver further remarked, BPM started as a management discipline 20 years ago as a way to think about the business in terms of key cross-functional processes i.e. how to plan it, understand it and measure it. Dr. Geary Rummler, one of the early pioneers, emphasized “managing the white space in the organization”, i.e. the handoffs between the silos where information tends to get lost.

As the market has only recently gained considerable momentum (in 2006 there were approximately 150 vendors!), it is only natural that there are many opinions about what exactly can be considered BPM. While some believe it that it should remain a management discipline and only provide the ability to analyze the business processes, the real returns comes from the ability to model, simulate, execute and optimize the business processes using a Business Process Management Suite. A BPMS does not simply analyze the processes of an organization but it also actively manages the processes that span it.

Process Management Challenges in the enterprise
The rise of siloed enterprise applications has created several challenges:
• Inefficiency: process exceptions are handled manually with the result that on average, processes take too long to complete
• Rigidity: it is hard to integrate enterprise applications and much more harder to change
• Lack of compliance and control: the same processes are executed differently in different business units
• Poor visibility: management cannot measure the performance of business processes
• Inertia: requirements and rules keep changing while IT resources are already stretched to or above their maximum

The stakeholders don’t care about the silos. For example, our customers or business partners do not think of our silos; they think about the high quality products and services they can get from us. In other words, they want a good customer experience.

Benefits of BPM to the enterprise

A BPMS does not replace your enterprise applications; rather it coordinates the actions of people and systems to make the processes more efficient, more flexible and more compliant.

A BPMS makes processes more efficient because it can automate manual tasks, handle the white spaces and manage the exceptions as well. It makes processes more agile because the processes are not controlled by a complex application whose code is difficult to modify. Rather, processes are defined graphically and these can be easily and quickly changed when desired. This lowers the cost of developing and maintaining business solutions. One of our BPM customers once reported that on average, they had to deploy a new application every 9 days. Development, testing, change and maintenance became a serious issue. They reported substantial improvement by using Oracle BPM. It makes processes more compliant because the logic is based on well-defined and well-understood rules which reflect the policies and the best practices of the organization. Users have no choice but to execute the processes and follow the rules as they have been defined. These can also be used to show to compliance auditors that the rules have been followed.

Finally, a BPMS makes processes visible by ensuring that process performance along with key performance indicators can be provided to management.

These can rapidly translate into tangible returns on the investment in BPM. In my next post, I’ll talk about what constitutes a BPM Suite.

Cheers,
Ali

In my previous post, I quoted Paul Strassman and his argument about the use of technology to deliver economic results. In order to deliver these results, BPM cannot just be about improving individual processes but more importantly about improving the management of processes. With his customary incisiveness, Bruce Silver comments that “the M (for management) implies continuity, the ability to constantly re-align processes to every changing market needs and company goals”. The management of processes involves answering some of these questions:

• How do you discover the processes?
• How do you ensure they are aligned with organizational goals and objectives?
• How are processes designed and alternatives evaluated?
• What approach is used to collect process performance data?
• How is the process performance data used to improve existing processes?
• How are individual processes composed together to form new services?

Obviously, the above is not an exhaustive list but they give us a general idea about some of the key aspects of process management. This leads us to examine what should constitute a BPM Suite and its architectural building blocks. Bruce Silver wrote an article (I say article, it’s really more of a guide) a couple of years ago about this so I’ll summarize the points he made here.

Very broadly speaking, a BPM Suite consists of the following components:

• Process Modeling
• Process Automation
• Process Architecture and Standards
• Business Rules
• Application Integration
• Performance Management
• Process Lifecycle

Let’s look at each in turn.

Process Modeling

Some BPM practitioners like to distinguish between process modeling and process design. Process modeling means creating an abstract description of a process used for documentation and analysis whereas process design means creating an executable process management application developed by IT. Whilst this accurately describes the lifecycle of traditional software development, advances in BPMS technology reduces the gap.

In a landmark book published in 2003, Smith and Fingar introduced the notion of an executable process model. Essentially, an executable process model is one that is built graphically without programming but can also be deployed to a process engine to automate, integrate as well as monitor a process from the beginning to the end. It is therefore more helpful to think of 2 types of modeling and their respective and associated tools i.e. analytical modeling and executable modeling.

Analytical modelling is abstract and not bound to any proprietary implementations. However, they provide a number of functions both to traditional BPM and modern BPMS:

• Capture of existing process flow in a structured diagrammatic notation
• Diagramming new or modified processes using the same notation that can associate resources, processing time, cost etc with each process activity
• Simulation of process performance based on various scenarios of process instance volume, resource allocation and other process parameters
• Analysis and reporting of service level, throughput, cost for various scenarios
• Documentation off the process in exportable format.

Analytical modelling is now an integral part of modern BPMS and most modelling tools now use the BPMN standard for this purpose.

Executable process modelling refers to the design of an executable application through the graphical composition of process activities. Executable models also use a structured graphical notation but their implementation details depend upon the particular BPMS itself. As such, the look and feel of executable process diagrams can vary considerably between BPMS and usually dependent on the implementation itself. Most tools use a serialization format, usually XML-based, to store the process definitions such as:

• XPDL from the Workflow Management Coalition
• BPEL from OASIS

Process Automation

The engine is the runtime component which allows processes to run. When processes are run, the engine creates process instances. A process instance is a single enactment of a process and the engine allows you to create as many process instances of all deployed processes. Process instances can be triggered manually by a process participant or automatically by an outside event. The engine then coordinates all the different activities, some of which can be human activities while others can be automated. Generally, process participants will be able to interact with the process instances by means of a web-based portal-like application. The web application displays the list of outstanding process items on which users have to act in the form of a worklist while the automated tasks may be executed natively in the engine or remotely by calling a remote application or Web Service. Process participants may also launch new process instances from this application.

Process Architecture and Standards

In another very insightful article, Bruce Silver identified 2 types of BPMS architectures:
• Workflow
• Service-Oriented

The workflow-based BPMS architecture is characterized by:

• Usage of the WfMC reference model, XPDL as its basis
• Activities are assigned to roles or queues
• Strong support for human interaction but generally weaker in integration
• Tools oriented towards business analysts

whereas the service-oriented BPMS architecture is characterized by:

• Usage of web service orchestration, in particular BPEL, as its basis
• Activites are assigned to services end-points
• Generally strong in integration but weaker for human interaction
• Tools oriented towards the developer

Most vendors generally agree on the common set of functionalities that should constitute a BPM Engine but they rarely do on the standards to use, or more relevantly, which architecture to use, or to be more accurate, which architecture to use to tackle which problem. A quick trawl on the various blogs will reveal the extent of the debate making it even more confusing for customers. But more on that in later posts.

Continuing from my previous post, I'll describe the rest of the components of a BPM Suite, namely:

• Business Rules
• Application Integration
• Performance Management

Business rules

Business rules must be distinguished from routing rules. Routing rules are characterized by:

• Simple conditions at a point in a flow
• Usually defined in the modeling environment
• Changes to rules required versioning, possibly requiring an update of the process in the engine

On the other hand, business rules are characterized by:

• Complex conditions that can be invoked by a wide variety of triggers
• Usually defined in business rules engine (BRE) by business users
• Changes in rules do not require the republishing of the process

Application Integration

In its 2007 report on BPMS, BPTrends.com identified 3 types of integration approaches:

• Brittle Spaghetti
• Adapters
• Introspection

In the Brittle Spaghetti approach, the developer has the responsibility of writing suitable integration code. This is facilitated by sophisticated APIs that allow developers to pass the right information as parameters to third party application. The problem with this approach is that integration code tends to be scattered around through the processes. As the systems changes, the code to do this integration becomes a management nightmare.

With the Adapters approach, vendors provide a standard interface with which the processes communicate with the backend systems. However, they may have some limitations, particularly when your backend system goes through an upgrade.

With the Introspection approach, the integration is generally built around a set of generic technology adapters. The tool introspect the 3rd party applications to create a set of reusable components which can then be used in the process models. A developer uses the introspecting capabilities of the tool to explore the methods and attributes of a remote backend system either via API or Web Services. When you consider that integration costs represent 50% of a process enabled project (cited by the BPTrends report), the advantage with this approach is fairly obvious. If your backend changes, you can just re-introspect the component and make the necessary (and hopefully smaller) changes rather than wait for an updated adaptor or recode. Incidentally, Oracle BPM uses the introspection approach.

Performance Management

Performance management allows you to monitor the processes and how they are performing against your KPIs. Generally, this takes the form of pretty graphs and dashboards displaying performance measures in real-time, near real-time or showing historical trends. These performance data can then be used by line-of-business owners to seek further improvement on their process.

I hope you have enjoyed reading this. In my next post, I'll describe the different features and functionality of Oracle BPM and how they relate to the different components described here.

Cheers,
Ali