Skip to Content

Characteristics and Capabilities of Business Process Management Suites

BPMS systems have been on the scene for several years now and have gradually moved from being niche products for specific interaction-intensive business processes to claiming a place as a new and major separate enterprise layer in the Enterprise Architecture. This new layer is most commonly called the “Composition” or “Orchestration” layer.  

The leading pure-play BPMS systems have originated from three different domains:

v  Case Management processes

v  Integration and EAI processes

v  Document Management processes

 In the last few years a fourth category has appeared:

v  ERP-extended business application processes

The associated vendors also come from the same domains. This means that in the area of BPMS vendors from the business application domain (e.g. SAP) are competing against pure play Dynamic Case Management vendors (e.g. Be Informed), EAI-vendors (Software AG, Tibco) and Document Management vendors (Filenet, OpenText).

All these different BPMS platforms reflect their origins and have a number of associated relative strengths and weaknesses.

These are summarized in Table 1 below.

Table 1 BPMS Types and their characteristics

BPMS Type

Case Management

Integration and EAI

Document Management

ERP Extension Business Application

Example Vendor

Be Informed

WebMethods

OpenText

SAP BPM

Typical Use Cases

Managing complex nonlinear dossier-based processes

Enabling straight through processing of high volume transactions across systems

Supporting workflows around electronic document flows

Improving and simplifying existing ERP processes

Core footprint start

Departmental Business Rules heavy processes

Extending Middleware integration by including human decisions and triggers

E-Invoicing and Enterprise Content Management repositories

Combining inefficient transactional steps in ERP into a simpler and faster user experience

Strengths

Can cover nonlinear dynamic case based processes; goal-oriented “TomTom like process steering”;

Business user empowerment

Strong Business Activity Monitoring; strong Integration developer support

Reuse of well-known integration patterns

Close alignment with document workflow requirements prevalent in many companies; good integration with Enterprise Portals

Intimate knowledge of ERP transactional flows and structures; native integration with ERP back ends; relatively inexpensive licensing

Weaknesses

Hard to model linear start-to-finish processes;

no clear BPMN like process model visualization;

loss of transparency when many business rules interact

Many BPMS in this category have proprietary non-BPMN modeling techniques;

BPEL runtime not based on BPMN;

Multiple different technology bases in one platform; “Techie” developer orientation

No strong end to end process orientation; lacking multi-back end integration concept;

Focus on human workflow only

Late arrival on the market with associated lower product maturity and feature set

 

What is apparent from this table is first of all that no BPMS platform can cover all BPM use cases equally well. In fact the origin of each BPMS shows clearly for which use cases each tool is best equipped. The current maturity of the BPMS platforms is not advanced enough to be able to cover all requirements. It is also clear that the choice for a BPMS platform should be closely aligned with the use cases that need to be supported.

Core BPMS capabilities

The core capabilities that a BPMS requires have been described by various analysts and BPM experts. These capabilities were originally rather fluid (as evidenced by the fact that several different categories were used for this type of tooling by analysts such as Gartner and Forrester).

The required capabilities live in different domains in the IT architecture. A good reference model is the CORA model (Common Reference Architecture) developed by Capgemini (see www.coramodel.com)

In general the current consensus of BPMS core capabilities can be summarized as shown in the picture below, where the required capabilities have been mapped on the CORA Model.

Figure 1 Typical BPMS Capabilities

BPM platform capabilities 

The typical BPMS capabilities are shown here in green. The picture shows that a full BPMS should have excellent Process Composition and Orchestration capabilities, should have ways to find and integrate with application services in the back end, and should be capable of presenting the user with relevant content and actionable tasks, and this across channels, and in a secure and transparent way.

Most of the runtime components then also have to be supported by a design-time development environment to be able to use the BPMS in real life projects. Full life cycle management then of course must also be supported.

If you look at the picture above it is easy to see that there is lots of stuff out there that is required in any real life project or application, but is not included in the BPMS platform. It is therefore very important to assess the context of the architecture in which the BPMS will be deployed. The BPMS will always just deliver part of the overall solution required.

To give an example, suppose a Service Management scenario involving maintenance work on equipments at a customer site is being implemented using a BPMS, we would need additional components in the Channel Access, Presentation, Integration, Application and Data layers, plus things like  Identity & Access Management, SSO and life cycle management capabilities not delivered at all by the BPMS platform.

Additionally, there will be a lot of architectural principles, policies and ways of working already in place that will impact the way the BPMS will integrate in any organizations landscape and governance processes.

The other main problem when you look at figure 1 is that what is innocuously enough shown as a box in the Application layer as “ERP” for instance, in reality comprises and hides a lot of complexity with regard to business process:

  • The business process flows as contained within the application and more or less “hardwired” into the application
  • The vertical integration of application platforms such as SAP ERP where the NetWeaver platform covers a lot of the capabilities as shown in the CORA model natively
  • The increasing number of vertical business applications delivered on the SAP platform leveraging various components working together including such capabilities as Portals, On device delivery, Workflows etc.

All these factors will impact the ease and even the possibilities you will have implementing a BPMS platform in any organization.

So the truth of the matter is that when you start evaluating BPMS platforms solely on the bare functionality criteria as mentioned by Gartner and others you will most likely end up with a final choice which is arbitrary at best and simply wrong at worst.

So how should we go about selecting a BPMS platform, or rather, how should we ensure to make the right investment decisions at the right time?

This is the subject of my next two blogs dealing with the real BPMS selection criteria.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Sascha Wenninger

    Hi Hans,

    great read! I am glad I’ve stumbled across this through a Google search as I’m doing a little bit of research into this area at the moment. If you have the time, I would suggest cleaning up the formatting a little bit (the migration to the new SCN platform has introduced some small formatting bugs – the table is cut off on the right, and some bullet points are a bit funny), as well as moving it into the BPM space so that it’s easier to find.

    Nice work!

    Sascha

    (0) 

Leave a Reply