We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

BPMN will kill BPEL. Will it kill BPM too?

Vote 0 Votes

The OMG met recently to discuss next steps for Business Process Modeling Notation (BPMN) - and taking a look at the official BPMN Web site, the "list of Companies that have an implementation of BPMN" shows 31 current implementations, with 5 more planned. Though only 2 actual users are listed (i.e., it's still early days), vendor support at least is clearly strong - so it seems a good point to take a step back, and ask what the long-term impact of this notation will be.

BPMN has always been intended as a human-readable layer that hides the complexity of designing transactional business processes in an executable XML language. In particular BPMN is intended for use with BPEL (which is from OASIS rather than the OMG), and BPMN comes with built-in BPEL mappings. In a sense, BPMN sets out to be the friendly face of BPEL - the face that the tool user sees, leaving the tool vendor to grapple with the murky complexities of BPEL itself. So by rights, any success that comes to BPMN should bring a corresponding success for BPEL. But will it?

In fact, the opposite is likely to be the case. BPMN, whether by accident or design, is so powerful in its own right that it effectively renders BPEL unnecessary. In a sense, such a level of expressive power in BPMN is unavoidable, since the intention all along has been to enable automated transformation of diagrams into executable BPEL processes. The BPMN specification goes into extensive detail, supported by examples, of how such transformations can be performed (presumably for the use of tool vendors).

Moreover, the OMG are working on a "metamodel" for BPMN. Though this may not include diagram layout, such a metamodel will enable the content of any BPMN diagram to be stored in standard XML form (as XMI, the XML dialect generated from any OMG MOF metamodel). So why use BPEL at all? No-one needs 2 equivalent XML representations of the same process. As BPMN matures, why not generate executable process implementations directly from it in component technologies such as J2EE or .NET?

In fact, BPM vendors are already busy consolidating with platform vendors, many of whom offer sophisticated tooling for component technologies, including the exposure of components as Web services and the use of atomic components to construct higher-level ones. Vendors with combined BPM and component tools will be well-positioned to incorporate BPMN into their offerings as a layer directly above component generation - so the existence of BPEL as a sort of technology middle-man is going to become harder and harder to justify.

The only argument for the continued existence of BPEL is that it should be used as a replacement for component technologies - that a Business Process Management System (BPMS) should not bother translating BPEL code into J2EE or .NET components, but run the BPEL directly as a low-level programming language. In effect, such an approach aims to replace the application servers that are the mainstay of enterprise computing with BPMS products based on BPEL. Is this realistic?

Even if a few such process implementations can be made to work, it is hard to see how a fresh-faced, spotty young whippersnapper such as BPEL can compete with vast, mighty giants such as J2EE and .NET. These are mature programming systems into which untold millions of dollars and thousands of man-years have been invested. J2EE in particular benefits also from a huge and active open source community, which is extending J2EE with additional frameworks that not only add functionality of all kinds but also simplify development and make applications more maintainable. BPEL, on the other hand, is too weak in its current form (version 1.1) to support many real-world corporate business processes. New accompanying standards are being proposed to extend BPEL in version 2.0 (BPELJ, BPEL4People, and BPEL-SPE), but all standards take a while to come to fruition, and in the meantime BPEL has already acquired various proprietary extensions that completely undermine its supposed portability. So it's all getting rather messy, any virtue of simplicity possessed by BPEL over J2EE/.NET is already being eradicated, and many corporate users will not be sorry to see the back of BPEL.

And no doubt this will also please computer science academics, who have never liked having to grapple with such an ill-formed language ... a typical academic assessment of BPEL is this:

the answer to "Do we need a language like BPEL?" is No!

I think BPEL will be phased out over the next few years, since despite the investment into associated standards by OASIS and into supporting technology by tool vendors, BPEL incurs cost without providing benefit.


Anyone considering investment in a BPEL tool should ask their vendor what support the vendor provides for BPMN - and current BPEL users should ask also how their vendor will help them deal with existing processes if the language does die out. In both cases, the key issue is whether or not the vendor has, or plans to provide, a migration path for processes stored natively in BPEL - either to storage natively in BPMN or, if this is not possible, to storage in an alternative process representation such as UML Activity Diagrams.

More generally, what will be the impact on BPM generally if BPEL vanishes? Tune in again to this blog to see the potential effect of BPMN on the original "third wave" vision for BPM ...


Here i am seeing contradictory statemetns.
If we dont need BPEL language..Why we need extra language kind of BPMN MetaModel(XML..)

Interesting slant, but BPEL will not be killed – it is a completely different and non competitive thing. BPEL is a programming language like Java or C++. Microsoft is really battling Sun to displace Java, and Sun was asleep at the wheel the last couple of years. BPEL adds an easy way to make multiple calls simultaneously – something that neither C++ nor Java have. That is why it will remain as a web service choreography language for many years to come.

This blog completely ignores the fact that BPMN does not have precisely defined semantics to the extent that it can be executed. But the point is well made that BPEL will no longer be the whole story. There is room for alternative implementations.

And, of course, you completely ignore XPDL – from the WfMC - there are significantly more implementations of that standard than you may realize and it is closely coupled with BPMN.

Jon Pyke Chair WfMC

John, we need a BPMN metamodel and the corresponding XMI representation for portability - so that you can transfer your BPMN diagrams between tools. If every vendor had their own proprietary storage format for BPMN diagrams, their users would be locked in to a single toolset.

Jon, for a start BPEL is not a Web services choreography langugage - it is a Web services orchestration language. I will be discussing these terms in detail in future blogs, since the distinction is often poorly understood.

With respect to your main points:

Yes, BPEL may be more tailored to Web service invocation than either Java or C++ in their native forms, but to emphasise this is to ignore the many frameworks that have grown up around these languages to facilitate use of Web services. Some of these frameworks offer a range of features additional to service invocation that BPEL will never be able to match.

As you say, this blog entry ignores the imprecise nature of BPMN semantics - I have saved a detailed discussion of this for the next entry!

Finally, I ignore XPDL here since, in my view, it "knows its place" -like its main competitor ebXML-BPSS, XPDL is a workflow tool designed for situations where mobility in the pi-calculus sense is not required. Such technologies occupy a specific niche in the enterprise IT toolbox, and their continued existence depends simply on vendor support.

BPEL, on the other hand, has been made the focus of very sweeping claims! It is proposed as a candidate for a universal layer in enterprise IT, with some people saying it should supersede not only workflow languages such as XPDL and BPSS but also component technologies such as J2EE and .NET. The main reason I am posting this series of blog entries is that this unfounded and unjustifiable hype is getting out of hand! Time for a reality check ...

I don't subscribe to the BPEL hype any more than you do - but it is one part of the overall BPM stack and a valuable one - many believe that BPEL is really a mechanism to go after Java - which was also a claim made of BPML - but the misconception as to XPDL needs to be addressed.

XPDL is not a "language" the Workflow Management Coalition has never been in the market of developing languages - it is an interface between modeling/definition tools and execution engines (or simulation) so its function in life is to provide a common format to effect transfer.

I think the key point here is that the WfMC XPDL standard for process design is really addressing a rather different objective to BPEL.

The WfMC has developed a high level standard for process design, whereas BPEL is a lower level standard for a process execution language.

There are a number of missing functions in BPEL when considering the process design view; a major problem is that BPEL does not have any concept of organisational model and responsibilities (either for work execution or process ownership). This is because it is predicated on a web services execution environment whereas many business processes execute in a mixed environment with both human and automated [whether by web services or other technology] resources required. We know from past attempts within WfMC that it is extremely difficult to share process models without such concepts being addressed.

You need only visit the wfmc.org web site to see just how many vendors have implemented XPDL particularly in the open source arena.

Yes, I agree with all this, Jon. I didn't refer to XPDL as a "language", by the way, only as a workflow technology - though such distinctions are sometimes hard to make! However, XPDL is more like the forthcoming XMI format for BPMN than it is like BPEL, isn't it. And I agree that XPDL offers organizational concepts to the modeller that are entirely lacking in either BPMN or BPEL.

I think XPDL is well-formed, with a sound basis in Petri nets, though it is overly complex for modelling purposes (due to its nature as a generic tool interchange format) and a Petri net basis is restrictive for some situations (where state-transition semantics unnaturally constrain the process).

However, I am not suggesting here that XPDL will soon become obsolete - for the time being at least, XPDL has its own niche to fill. I am only saying that once BPMN acquires its own XML representation, as it will shortly do, BPEL will not have such a purpose in life ...

Do you honestly believe that now the OMG has its hands on BPMN that anything will happen that quickly?

It will be interesting to see how long it takes for the OMG to create a metamodel for BPMN. It is certainly on their current agenda. My point, though, is that it will happen, sooner or later - and when it does, BPEL will be redundant. So anyone who is thinking of using BPEL, or using it already, should be aware of what is coming round the corner.


Can BPMN be used for specifying SOA orchestrations then? (You'll have to excuse me, but I am not at all familiar with it). I'm working on a planner for composing web service orchestrations from OWL-S sem. web descriptions, and BPEL is my target for WSC. Could I replace BPEL with BPMN for this purpose?

Or is this debate more concerned with using BPMN for enterprise integration and the like?

I don't follow your logic here - my understanding is/was that BPMN is basically a drawing standard designed to help users understand the modeling and description of a process - what comes out the other end could be any format (XPDL or BPEL or anything coming in the future (such as death)) - so I don't believe it will ever render BPEL redundant - people intending to use this technology shouldn't be put off by what "may" happen in the future.

Andy - yes you could replace BPEL with BPMN, and I advise you to consider this strategy. However, if you are looking at automating generation of orchestrations there are issues with generating BPMN since it does not yet have a standard XML language - though specific tools may offer import facilities to BPMN that you can leverage for this purpose.

Having said this, keep watching this blog since the next few entries may offer you further (and perhaps more durable) alternative strategies.

Jon - BPMN is more than a drawing standard. Look at the spec and you will see that there is enough in BPMN to match BPEL's functionality. There has to be, in order to enable the designers' stated aim of supporting automatic generation of BPEL from BPMN.

And in the end, it's up to the user how much importance they place on trends. But I think it is important at least to be aware of the strong possibility that BPEL's life may not be a long one, don't you? Would you buy a car whose manufacturer is just about to go out of business?


Keith -
"Jon - BPMN is more than a drawing standard. Look at the spec and you will see that there is enough in BPMN to match BPEL's functionality."

Is this really true, I've been put of looking at BPMN because I always believed it be more of authoring language than an execution language.

"There has to be, in order to enable the designers' stated aim of supporting automatic generation of BPEL from BPMN."

This logic doesn't follow. Just because BPMN can target BPEL, it doesn't necessarily follow that you can author everything you can in BPEL using a BPMN front-end instead. That is to say, the "expressivity" (expressivity in a practical sense) of BPEL may subsume that of BPMN, while BPMN still complies with its stated aim of supporting BPEL generation from BPMN.

BPMN was envisaged as an authoring language that generated outline BPEL code for further refinement using a BPEL tool. What I am saying is, as things have turned out, BPMN actually has enough expressive power to generate executable processes - so why do we need BPEL at all?

You are simply missing the point of BPEL - BPEL is a standard that enables me as a user of BPM technology to execute "sub-processes" that happen to be services and know that I can execute them from wherever they come from. It's nothing to with standard notation - that's just a nice thing to have on top.

I know what BPEL can do, Jon. What I am saying is that the OMG are making BPMN powerful enough to do this too (as well as being a useful graphical notation). So why have 2 equivalent representations of the same thing?

Apart from the fact that such redundancy in the case of BPMN/BPEL offers no benefit in return for the inevitable costs, there are very serious problems associated with having generative stages in a software development pipeline. Some such problems are illustrated by Bruce Silver.

Silver recommends the implementation of round-trip engineering to solve the problem, but as anyone who has worked with CASE tools or (the modern equivalent) MDA knows, things are never so simple. Each technology has its own quirks that make true round-tripping very hard, so going down this route is a poor approach unless you are going to get major payback for it.

I use MDA myself, so am not arguing that generating software is bad. To the contrary, future blog entries will discuss how exactly this approach is likely to be the future of BPM. But in the case of BPMN/BPEL, I don't see any payback at all for using both technologies. There is no real intelligence involved in the generation of BPEL from BPMN - no additional code created that would save the developer any time. Once BPMN has an XMI representation, it's just mechanical translation of one XML format into another. All you get for doing this is potential impedance mismatches between the two formats.

So I predict that, in due course, the component tool vendors who are swallowing up BPM vendors (witness BEA and Fuego just recently, for example) will recognise that they can make things simpler for everyone - themselves included - by dispensing with BPEL entirely.

BPEL is not perfect - but it is here today - furthermore it will get better - OMG will take years to come up with something useful to replace if - if ever. Bruce Silver is right and he also said "BPEL is a good BPM standard when all the business processes involved are ‘web services’, it is however not as suitable if some processes involved are not ‘web services’, in those cases, XPDL is a much better BPM standard to integrate business processes." So following your logic why bother with BPEL or anything else when XPDL 2.0 already works with BPMN?

Based on my own experiences I have a pretty good idea as to what will happen to BPM tools once integration companies get hold of them :)

As I said above, I have no problem with XPDL for the uses to which it is suited. I am not making any statement at all about XPDL here, and do not intend to in the remainder of this series of entries on BPM standards.

The point I am making in this initial entry is, in fact, exactly the same point that you make yourself:

Based on my own experiences I have a pretty good idea as to what will happen to BPM tools once integration companies get hold of them :)

So perhaps we have finally arrived at a point of agreement :-)


Good post. I agree with your main point: that BPMN (or a future combined BPMN/UML) is the future for process description. Further, either an enhanced BPMN spec, or the upcoming BPDM spec, will provide the serialization for BPMN, therefore insuring portabiliity. BPEL is interesting only if it is an efficient implementation option - it offers no unique value-add in process description or execution. As Jon Pyke pointed out above, "BPEL... is a completely different and non competitive thing. BPEL is a programming language like Java or C++."

BPMN is the future for description of executable processes; and it represents a big step in the move toward model driven architecture (lower case, so as not to implicitly accept EVERYTHING IBM says about MDA)....

You might also see my post from a few weeks ago: http://blog.lombardicto.com/2006/02/bpelephant.html


Hi Phil

Good post to you too! You (and Lombardi) will probably be very interested in the next couple of posts in this series ...

All the best

BPMN will not replace BPEL, rather the two are extremely complementary and enable a revolution that moves us from entrenched development methodologies driven around UML and Information Engineering style approaches. IE / CASE always tried to tell the story that we could do 100% generation as we called it at the time, with a series of business and design models that then seamlessly turned into code that would run. The end game was always that the model was the application. Ultimately this laudable aim failed for a number of reasons. The sum of which was that the refinement and customisation of the models required as we moved through the lifecycle transitioned into something far closer to a programming model rather than a business model.

The strength of BPMN is that we work with the business, define the use-cases and the functional footprint in business terms. This theoretical structure will never map perfectly to the history and legacy or technology in the organisation. We need clarity of understanding and vision around the the cross line-of-business and cross organisational business processes. BPMN gives us this. We then need an engineering implementation that deals with the technical denormalisation and deals with the realities of our infrastructure and the technology world that we operate within.

Take a common reference example of DSL provisioning within a telco. BPEL is perfect for this runtime integration as an execution environment and also as a technical design platform for the complex integration needed. BPMN is important in this context for the business to understand how the provisioning business model is designed but BPMN can never take it down to the next level and provide the execution platform for the integration.

We need an engineering implementation, or a business runtime if you like that delivers a secure, scalable environment for process orchestration and possibly in the future choreography. It needs to be able to run standalone, or on a bus, with embedded security or with a declarative policy-led security environment outside of the process; it needs business rules and policies, pattern matching and intelligence; it needs near-time and real time analytics and dashboarding integrated into the process and then leveraged through simulation and BPA into the business process. We need audit and storage of the process assets in an open-standard XML schema. We need to orchestrate any service end-point, not just Web-services; but connectors, beans, people and workflow, files, databases, message queues etc...

BPMN by design will never deliver the complexity and resilience needed to make this real whilst maintaining simplicity and business focus.

What we need is a seamless round-trip methodology to understand the functional use-case from a pure business perspecitive and then implement it in a way that is absolutely neutral to the service end-point regardless or transport, protocol or implementation interface.

The question is not will BPMN kill BPEL but rather will BPEL and BPMN kill other proprietary and legacy approaches. Specifically older methodologies and tools and more importantly proprietary integration and EAI platforms. BPEL is the application, the fault comes into play if you adopt the model of import and customise BPEL and execute is some proprietary internal structure because you lose the ability to make the application portable and to complete the round-trip lifecycle.

Keep the business process implementation as executable BPEL, keep the business use-case as BPMN and round-trip tightly integrate the two.

Hi David

You say "BPMN by design will never deliver the complexity and resilience needed to make this real whilst maintaining simplicity and business focus" - but don't offer any support for this claim.

Myself I see no advantage of BPEL over BPMN in this respect. To the contrary, once BPMN acquires the XML representation the OMG are working on, it will not only be as platform-neutral as BPEL but will also be a much more expressive language - capable of expressing workflow patterns that BPEL cannot handle, for instance.

And with respect to "seamless round-tripping", come on! Anyone who has tried code generation in anger, using any technology, knows that round-tripping is never seamless. I have been using generation tools for a long time (I remember the first Oracle CASE tools, for example), and the most mature approach I have seen is OMG MDA as implemented by Eclipse EMF, which still has various major problems to be solved - something MDA experts are quite upfront about.

I use MDA to develop process execution software, but it is certainly the area that gives the most pain, and I look forward to the day when modellers are able to:

Easily synchronize their changes with those of colleagues
Align the model with others that are related
Introduce cross-cutting aspects of design
Decide what "utility" code really belongs in the model

If you can avoid round-tripping in process design, then do so, is my advice. Certainly BPEL adds no value that would make round-tripping a worthwhile idea, while the need for round-tripping is evaporating anyway as BPMN and other process standards mature.

BTW, I appreciate that Oracle is one of the vendors who have made a significant technology investment into BPEL, so am not expecting anyone from the company to agree with these opinions publicly :-) Please understand that my blog entries are not aimed at any specific vendor or standards body, just a general analysis of trends.

All the best

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives