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.

Avoid Narrow Bridging Tools

Bridging tools allow a communications protocol or methodology change.

Generally bridging tools are unique one-off solutions and need to be avoided in a SOA integration environment. There will be some instances where only a bridging tool will do, those are when basically the only way to connect or bridge is via that tool.

The general rule is reduce bridging tools to the minimum set needed, and use the more generic SOA bus tools to replace them with a single tool or a suite.

Why? Bridging tools usually require their own environment (their own server or region) and have specialized configuration parameters and settings. Supporting them is supporting another complete application and technology. But because they are narrow use, the knowledge to support them is usually concentrated within a small group (often just 1 or 2 people).

Often a variety of bridging tools are being used in an enterprise as they were brought in over time to make connections that only they could make...at that time. Some years later the enterprise may find itself with a collection of many such tools that could easily be replaced with a newer more global tool or even a direct switch to HTTP Web Services.

Don't perpetuate the use of the narrow tools, and take advantage of projects that touch the space to migrate the older connections from them. These narrow technologies often are a major source of integration unreliability, and maintenance costs!

Just because it's from IBM or Oracle doesn't mean it's not a narrow bridging tool. Older helpful integration products have been supplanted by easy web service interfaces. Bridging tools extended with or as transformation engines are still narrow, expensive, specialized, and have been supplanted by ESB capabilities.

What's Your ESB Got?

The ESB (Enterprise Service Bus), instant awesome integration power in a single tool. Magic SOA at the press of a single button. (Ok, maybe not but that's what the vendors say.)

An Enterprise Service Bus is an advanced middleware tool that serves multiple purposes to enable a managed SOA integration environment. If you're doing SOA, plan on getting one. And if you're doing SOA and you don't have one, you're not doing SOA - you're just using SOAP and XML for quick and easy point to point integrations.

So what does an ESB do for you?

• Communications and Protocol Transformation – The tool connects to systems providing a service or function one way, and allows systems requesting a service or function to communication another way. For example, the providing system may expose the function by MQ (IBM’s messaging protocol), while the requesting system may request via a SOAP (TCP/IP & HTTP). The ESB acts as the intermediary.

• Data Format Transformation – The providing system exposes the data in one format, the requesting system needs it in another format. Example, the providing system exposes it’s custom format record as a fixed length format. The requesting system needs to receive it in an XML format. The ESB performs the transformation (and provides a development environment for creating it, usually with a visual tool, quickly and easily.)

• Orchestration or Integration Workflow – This is the real power of an ESB. Combining multiple granular services into an integration workflow allows sophisticated multi-system processes to be quickly assembled in the ESB context. Such workflow may include sophisticated logic including things such as content based routing, the activation of appropriate transformations, protocols, processing, etc, and combine it all into a single sophisticated integration process.

• Messaging and Process Management – Not included in all ESB’s (or sometimes as additional components within the vendor suite), a messaging paradigm becomes of increasing importance as business processes spread across systems, with a corresponding decrease in reliability (simply because more systems are involved). Messaging and process management provide the integration space with the tools to compensate for and manage the cross-system processes.

With an ESB, the application developers no longer concern themselves with each individual system connection, dealing with different protocols and different data formats. The systems architect gains the ability to design ‘virtual’ operations that are composed of orchestrated web services bridging multiple systems. And all the individual steps required for doing so become reusable integration components (at least in the context of the ESB environment).

ESB - a must have for current generation multi-system and multi-business-process integration.

Vendor Multi-Product Confusion

For some years I've been dealing with IBM SOA oriented products. About 3 years ago I had a chance to be in an IBM center and discuss their EBS product strategy with some top IBM SOA experts. As IBM had (and now has even more) products in the space, I was trying to make sense of where to position which product that was being pitched to our large enterprise IT. At the end of the conversation I was not successful.

Recently I was speaking to a top MDM expert about Oracle's product strategy in the MDM space. I was commenting on Oracle's "product", for which I had recently received a vendor pitch. He responded that Oracle has 5 products competing in the MDM space (and primary MDM tools).

Today I'm trying to produce an architecture model for a medium sized IT shop that purchased IBM DataPower to include within their existing SOA model (and fit with existing tools). In my search I came across this slide from IBM...



I see... one product provides fast connectivity, another connectivity, and another universal connectivity. Well, that clears it right up (sarcasm).

A number of the large vendors have gotten into the model of developing and/or buying up a number of products in a given technology space, and then figuring out what to do with them later. In the meantime they peddle the whole group, but can't provide a coherent strategy.

Good for me, more consulting and architecting to be done. But bad for the IT enterprises that have to figure out what's a fit versus the vendor salespeople ready to sell anything.