BPM Inferences for ‘06
Tuesday, January 31st 2006 | Ismael Ghalimi
This is my first monthly BPM column for Business Process Trends. In order to set the stage for a new year of BPM, here is a set of inferences for ‘06 based on my personal experiences, insights and desires. Some are fairly straightforward, others highly speculative, but most should matter to all BPM practitioners. Interestingly enough, the first inference—BPM will go mainstream—got a step closer to being fulfilled this morning: IBM just announced the release of the new System i5, also known as iSeries, also known as AS/400. As part of this announcement they are featuring a front & center quote from yours truly. Intalio|BPMS becomes the first BPM solution to be available for System i5, and if that does not make BPM mainstream, I do not know what will.
BPM will go mainstream. Integrated BPM solutions will be made available for free and will include everything you need to design, deploy, execute, monitor and optimize business processes. They will be supported by commercial vendors, dramatically raise the bar for competitors and radically lower barriers to adoption for all users.
Consolidation will intensify. Very few pure play BPM vendors will remain standing. Those that do will go vertical by selling specific business applications and getting their core BPM capabilities from Open Source projects or established vendors such as BEA, IBM and Oracle.
All major System Integrators will have BPM practices. The most innovative will be found in India and will blend BPM with BPO (Business Process Outsourcing). Most will standardize on standard methodologies such as BPMN. A few will adopt specific products at a corporate level.
The Apache Software Foundation will acquire a BPEL server, or two. Both the Geronimo project and the Web Services project will add a BPEL server to their respective stacks. One will become the most widely used BPEL implementation in the industry, much as Apache’s HTTP server is the most widely used web server on the Internet today. Competition from JBoss will fail to materialize for lack of focus on a user base that cannot write Java code.
BPMN will be extended to support Human Interactions Management. The BPM community will realize that having two separate notations, one for web service orchestration and the other for human workflow, defeats the whole purpose of BPM. One unified notation will emerge. This notation will be called BPMN and will incorporate most of the concepts found in HIM.
BPEL 2.0 will become the de-facto standard for BPM. All BPEL vs. BPML discussions will be put to rest. Support for distributed transactions will be made available, finally. A formal BPEL4People specification will be released and many proprietary extensions will emerge. Standardization efforts will keep most of us busy for very many years to come.
A first set of standards for BAM will emerge. IBM will lead work, with the participation of some Business Intelligence vendors. First implementations will be available before the end of the year.
All ESB offerings will support BPEL. Most will embed a lightweight, non-persistent implementation, coupled with a rule engine such as Corticon or Drools and will be used for advanced message routing and complex event processing. Some will embed a more advanced BPEL engine that supports persistence and distributed transactions.
BPM as a Service will not materialize. Lack of customer demand, inappropriate user interfaces and security concerns will prevent the Software-as-a-Service model to become successful with BPM. Only workflow automation services sold to specific vertical industries such as banking and insurance might have some limited traction. The situation will change only when Office 2.0 models establish themselves in the corporate IT world, toward the end of the decade.
The first BPM appliance will be released. It will accelerate adoption by simplifying purchasing and installation. It will be available in two forms, as a desktop appliance for development and as a data-center rack for production.
The first grid-enabled BPEL engine will be released. It will be deployed on thousand of servers for CPU-intensive tasks. Similar engines will be ported to Network Attached Processing solutions such as the Azul Compute Appliance.
This is it for now. Let’s reconnect on December 31, 2006 to check which of these inferences actually materialized. Until then, happy BPM to all!
Entry filed under: BPM 2.0, Consolidation, Offshoring, Open Source, SOA, SaaS, Standardization
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On Inferences (Ismael’s Inferences, not RETEs…)…
[To gain context, read Ismael Ghalimi’s BPM Inferences for 2006. This is my reply.] Ismael, Nice post… too bad you’re completely misreading the market! :-) The value-add standard of BPM isn’t BPEL, it’s BPMN and, ultimately, executable BPMN…
Phil Gilbert is the CTO of a company that competes with Intalio, and is not doing BPEL, so its not surprising he is a little touchy about this matter. I think Ghalimi has set out a pretty good set of predictions for 2006. I don’t think Ghalimi was misreading the market, or over-stating the significance of BPEL. and of course, a BPMS does execute BPMN diagrams. But there is so much more to say. For example, I think Phil is refering to the use of BPMN as a diagraming notation for a proprietary workflow-based approach. Any vendor can do that. Just add a few BPMN-like boxes to an existing tool/product, and hey presto, its executable BPMN. But this misses the whole point of BPM 2.0, that processes must reuse all the functionality out there in the IT environment. Building new processes, composite applications, end to end integrations, sophisticated processes like Procure-to-Pay, that takes complex process and complex reuse (as process) of existing systems, like ERP, Procurement apps etc. The point of BPEL, with BPMN as a notation, it that is can describe any process out there. A BPMS can expose all those processes, via inspection and projection, andthey can be re-purposed to create new processes. Its reuse on steriods, something the object movement did not achieve other than for fine-grained OO-programming models. So Phil, BPEL is important in the context of BPM 2.0 and the BPMS. In fact, its vitally important. It is the execution model of persistent, concurrent, distributed, transactional processes. Sure, BPMN can be used as a syntactic sugar over existing systems, and many vendors will do this, but so much more is possible.
Mmm… Good post :) Will watch your blog
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment