Skip to main content

BPM Encroachment

Jim Sinur at the Gartner Blog Network notes that Application Package Vendors and BPM Vendors are beginning to encroach on each other's territory. How so?

Package Vendors are beginning to incorporate some level of process control, and exposing the fact that they have tremendous vertical market expertise in the business processes incorporated into the application (exposing as SOA services and exposing as marketing). Who better than a vendor that's been creating CRM software for 20 years to understand the automation of CRM business processes?

BPM vendors are beginning to accumulate some significant libraries of business processes. As such, they're beginning to arrive with "industry kits" that contain common process sets for specific vertical markets - turning the BPM system into a partial package application for that industry. Further enhancing this is BPM's primary focus at allowing easy adjustments to the process - equivalent to complete customization of the 'virtual' application.

Of course, BPM can't operate in a vacum. By itself, it is NOT an application, rather its a manipulator of application processes with the ability to wrap in human processes. (Though BPM vendors are busy adding "model-driven" development capability into the BPM tools.)

The question I ask is will the traditional application vendors decompose their big box departmental and enterprise applications down to a sufficiently granular business-process service level so that BPM and/or application assembly tools can use them as transaction and process engines in the unique combinations of value to each business?

In other words, will we see SAP and other major vendors using SOA primarily as an API for inputs and outpost of their big-box functionality (which is what we see today), or will they offer us granular processes we can compose and orchestrate as needed? Even further, will they offer us a menu of business-processes we can buy as composable pieces?

So far, the big package applications have only been dipping their toes in the SOA waters - thereby limiting their use via services or BPM. Yet if IT is to provide value to a business other than strictly utilitarian - to provide a strategic corporate advantage - they must be able to quickly and easily customize.

To date, package application vendors are assuring this WILL NOT happen outside the bounds of their applications.

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