Skip to main content

Vendor BPM vs. Suite BPM vs. Standalone BPM

Reader Francesco Annunziata asked the following excellent question...

ERP Vendors are embracing the field of BPM e and SOA. Sooner or later their solutions will catch up with those of current leaders. On the one hand, if they can’t show much deeper integration with their ERP suite than any other BPMS vendor can offer, they will be just another behind-the-curve BPMS struggling for market share (a quote from the Column 2 blog). On the other hand, If they can take advantage of their ERP by showing a superior capability of integrating their applications I think the BPM deals will by default go to them.

Those considerations boil down to my question: Is SOA, among other things, leveling the vendors' playing field in terms of integration and composite applications? In other words, will a potential Client be able to choose a BPM system (and other applications) only considering its capability to meet the company needs, "taking for granted" that the well implemented Service Oriented Architecture will sort the integration problems out?


BPM systems are selling 3 primary areas of functionality:

1. Interfacing. To operate a business process, a BPM tool must interface to all the IT systems that provide the granular steps of the process. In this area BPM tools are similar to ESB's or EAI tools, though they don't focus on bridging or external exposure, rather internal exposure. As such, BPM tools often include deeper integration capibilities than ESB or EAI tools. (For example, you'd never expose access to a shared Excel spreadsheet, but you might use it as a data input source for a BPM process step.)

2. Business Process Modeling - Flow - Design - Control. The core of any BPM tool is the environment to model, design, and create the business process flows. This extends from design-time to runtime allowing active monitoring of processes, and intervention in process problems.

3. Process Models. Many BPM products are arriving with, or offering as add-on's, process models of common business processes in select industries. Business processes for insurance, manufactering, banking, and various other business segments are offered as a base from which to customize the business processes of your company.

On this basis, let's address the questions raised.

- Is SOA leveling the playing field regarding BPM integration?

The simple answer is yes. Early BPM integration capabilities are being used less as SOA exposes more. However, BPM does require that the process steps be exposed at the level of granularity required for the planned process. In many IT enterprises, the level of granularity exposed for application integration may not be the right level for BPM processes.

Even worse, a "well implemented Service Oriented Architecture" is rare. SOA tools and techniques as a "get it integrated fast" are popular and widespread. Architecture, planning, and SOA processes are not. Most IT enterprises have moved to Sevice Oriented Integration, a much smaller percentage are doing Service Oriented Architecture. That said, when additional granularity, transactions or processes need to be exposed, SOA tools or an ESB remain a better choice than native BPM functions.

Integration functions have been a necessary part of BPM tools, but it is not their strength.

- Will an ERP vendor BPM offer more than a non-vendor BPM?

To date the ERP vendors have done a poor job of exposing their internal functionality via any technology. It's unclear whether they are hanging onto the concept that their applications will remain a closed suite while pandering to the SOA concept (exposing limited levels of access) or just having to deal with a 30 year code base that's not architected in a modular model around business processes (and therefore making it difficult to expose functionality in a business meaningful way).

In either case, while we see these vendors coming to market with BPM tools and MDM (Master Data Management) tools, their own products seem to face the same problems as external products in depth and granularity of integration. Being that these tools are often purchased companies, it's no surprise that they have no special integration access.

In other words, the challenge for the ERP vendors is not creating the tools but providing the detailed integration points necessary to allow tools to be successful. It's the same level of integration points that would allow us to utilize their products as transaction engines, picking and choosing the right modules for our business process needs and using them to quickly build composite applications for our customer's unique business needs. (Which after all aren't so unique in the first 75% of the process.)

Our question could perhaps be rephrased as, "Will the ERP vendors create a more detailed integration layer that is proprietary and only accessible by their products." (The Microsoft Windows model.) I don't believe this is where the market is headed.

If the ERP vendor has such a proprietary integration technology or layer, the ERP vendor BPM could utilize it. Being that exposing such a layer as web services would be a competative advantage, it would seem unlikely that the vendors have and are hiding this.

- So what advantage might an ERP vendor BPM have?

Process models. The strength of the ERP vendors is not their technology, it's their understanding of business processes and designing software that manages those processes. They have tailored their products to many market segments and purchased companies with expertise and tools to extend into other segments.

Cisco understands the network, IBM understands the data center, Microsoft understands the desktop, and ERP vendors understand the business processes. Or rather, these are their core compentencies.

If the ERP vendor based BPM products arrive with libraries of process models, models for your industry segment and/or models for the processes that the vendor ERP provides, then that BPM will provide you the ability to instantly customize the ERP platform and extend it into composite business processes. To quote the Column 2 article you reference in your question, " 'process changes in an ERP are difficult and require many hours from developers' – oh, the irony of this coming from an SAP employee!" Providing such an ability is a major feature for an ERP vendor.

- What's more important: integration, modeling, or process models?

About a year ago I had the opportunity to meet with Dr. Kiran Garimella, Vice President of BPM Solutions at Software AG. I attended a meeting where he was presenting Software AG's BPM suite to a major (potential) client. I was on the other side of the table as an evaluator.

He presented a very compelling story, I was impressed. He drew a futuristic BPM vision that I agree will develop. At the end of the meeting, however, I asked some questions...

Question: How many BPM processes is it realistic for this organization to develop in a year?

Answer: 5 to 7.

Question: And how many do they have that could take advantage of a BPM tool?

Answer: An organization this size, around 70.

Question: Why will they only be able to develop 5-7 a year, given how easy it is to develop BPM processes in your tool?

Answer: Because they don't have the processes defined. They're doing business, but don't have their actual business processes mapped. Getting agreement on what exactly they're doing in each business process will be an extended effort.

There are some organizations that have mapped out their business processes. Some level of this is required for ISO 9000 certification ("ISO 9001:2000 and ISO/TS 16949 require organizations to define and document their business processes"). In this case process model libraries may be of less value.

But for most organizations, modeling the processes will be the major issue of BPM success. And this is the one area where ERP vendors have an advantage.

Whether they maximize their advantage is yet to be seen.

Graphic courtesy of Griffiths Waite.

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider