Hi everyone! After a couple of month of peace and quiet I am back to shake, rattle and roll the IT industry. Hm, I wish. Actually, the oxen of the IT industry cart seemed to be so horribly stuck in the mud that my fiercest yelling and meanest jabs didn’t do anything to move them. It was that realization that has also caused my pausing. Some of it was frustration, some of it was taking a physical pause to reload the batteries. I also wish I could replace the worn out NiCads of my body against some high tech NiMH, NiZn or possibly even Supercaps. Sigh. But here I am after some reconditioning exercises and full of fighting power.
The first thing I noticed once I got back into the loop, was a kind of changed tone on the subject of BPM. Suddenly a number of BPM vendors seem to have caught on to my long-standing request that rigid processes are not the all-encompassing salvation. Many consultants and university professors still dream on in their grand theories of total process control. Not so much the market anymore. Many IT people realize now that encoding processes is not only hard to do and expensive, but it does not really improve the way the business works. They have finally started to look over the rim of the BPM plate. They realize now the problems with BPM maintenance, scalability, enterprise wide use and system migration. There are no longer any businesses where processes can be built from scratch, but there is always some environment that exists that has to be considered and integrated one way or the other.
The disappointment that seems to finally cause a rethinking comes from the fact that these projects claim to use one or more ‘Open Standards.’ As it seems, the wished for agility of the combined functionality of custom BPM and SOA standards is nowhere near a reality. We do SOA interfaces in many projects and also I fail to see the promised Plug&Play flexibility. The effort is the same as for any other well-documented interface. Over and over again. Preloading the process landscape with LEAN or SixSigma approaches to achieve a higher reuse and quality has not sped up things but just introduced a lot of bureaucracy. Before any standard seems to bring relevant benefits … the world has changed.
Not only how we implement processes creates problems but also the lack of future opportunities. There are a lot of closed doors in terms of cost and effort. Real-time process analysis and monitoring cannot simply be added to an existing BPM product. Most already made a bad choice there. Monitoring and tuning backend SOA interfaces is more relevant to BPM performance than the process-server. SOA scalability sucks (see my previous post). Business Rules engines that some try to integrate via SOA will be even worse for high-volume applications. Standalone CRM is not a backend or front end or another form of BPM, it is no more than a failure. A silly idea that backfired. And finally, Business Intelligence has to be an integral part of BPM and neither report on process execution nor trigger processes when KPIs kick out. SOA doesn’t help you with creating new consolidated process-enabled business user interfaces but you need some other product or Java coding to do get any benefit out of widespread SOA use. So far on the state of SOA technology – but NOT so good.
What is still missing in BPM the most is the human aspect. Not ‘Human Process Management’ that no one needs, but how could process management actually help a human to utilize their skills to the max without restraints but under full audit? How can a fully automatic monitoring/update loop for processes be realized so that it empowers the business user and process owner to do what they need?
The problem is made worse by jaded business users who now want to see their applications before they are willing to go along with anything. Therefore the most successful BPM solutions are the ones that already have a large library of drop-in processes and a cutesy, flashy user interface. I am not saying that is wrong but in many ways it defeats the purpose of providing a flexible process platform. Now they sell a hard-coded BPM application.
So yes, the BPM market is finally moving in the right direction. I am also moving. I have decided to focus more on dynamic user interfaces, making the definition of processes even easier in our Papyrus Platform, and YES, I won’t waste any more time bemoaning the drawbacks of ‘standards’ – XML based or not. If people don’t want to look at reality with open eyes then so be it. Given that decision, ISIS Papyrus is joining the standards organizations OASIS and OpenGroup to try its best to move the standardization processes forward and in the right direction. Sigh, more bureaucracy coming our way …
But I promise you one thing: We won’t be held back by waiting for standards in SOA, BPM or otherwise. You simply will have two choices: a) innovate by using the latest in ISIS Papyrus solutions, or b) wait for several more years to see if the standards will enable you to do what you need.
So, that is another weight off my shoulders. I actually feel FREE!