BPM is a workaround then, or is it SOA?

This press release landed in my in-tray this morning.  The basic premise is that enterprises are turning to BPM because the major systems (ERP, CRM etc) have not delivered the required flexibility in business processes.

There is a long held belief in the Build vs Buy debate that you either build and have a system that perfectly (or nearly) matches your business processes, or you buy a packaged application and change your business processes to what should be best practice.

But best practice (at least as determined by the software vendors) has some conceptual problems.  Firstly it assumes that all businesses are the same (they are not!).  Secondly it assumes that business users will accept the new processes (and so will their customers).  Thirdly it broadly ignores the existing IT infrastructure which varies enormously company by company.  Finally, it doesn’t acknowledge the massive amount of necessary change in business processes on an ongoing basis.

I think what we are seeing here is a user rebellion against large “benchmark” systems and the users are trying to address this with their own workarounds, or with BPM or similar.

So am I recommending that enterprises always build? Well, let’s get back to the real world.  The cost of building (believe it or not) can be even higher than the astronomical sums it can take to put a packaged solution in place.  It doesn’t always start out that way but build projects have a tendency of running out of control and end up getting largely de-scoped.  So building may also end up with a solution that is equally inflexible in the long term.

Perhaps there is little difference as there is inevitable inflexibility whichever route is taken, in which case we should focus on how to solve the problem on an ongoing basis.  In any case, most enterprises already have their core systems as hefty items on the balance sheet, not to mention that they are full of business critical data which is risky to move, so there will be little appetite to replace in the short term.

So, since it’s not practical to be constantly changing the core systems, a new layer could be used to manage the business process that is independent of the core infrastructure.  This sounds like BPM although I must admit to confusion over what BPM actually is.  I’ve read many definitions but I guess there are different vendors with different ideas, all with some validity (or they wouldn’t be in business right?)

Without defining anything further, I think there is merit in a new layer which automates rather than manages the business processes.  This must be controlled at the business end to enable the flexibility and agility needed by the business.  It must be changeable without further coding.  It must be flexible enough to adapt to core system changes.  It must be scalable enough to manage bulk processing, yet it must be secure enough to cope with compliance, security and other audit requirements.

There are a range of solutions that meet this need.  At one extreme, I have considered previously tools with local applications.  Although generally based on desktop integration, these tools are surprisingly secure, robust and scalable.  They are quick to deploy and highly cost effective.  At the other extreme this is starting to look like a job for SOA – no?

Leave a Reply