Bitch slappin’ BPMS: a BPMN and BPEL war of words

Bitch slappin\' BPMS

Yeah, baby! Ain’t nuthin’ like a good blog war-o-words. And a juicy one has just broken out between two influential voices: Nick Malik and Bruce Silver. And I suspect we haven’t seen the last of it. (At least I hope we haven’t. July is a slow month; we could use some American Gladiators-style trash talkin’ right about now.)

Apparently, Nick found the top dead center of the button you shouldn’t push in Bruce’s mind: he says BPM is never going to live up to expectations that non-developers will create applications.

In reply, Bruce — slappin’ Nick right upside the head – replies that Nick has to “prove” his assertion by showing that someone — anyone — in the “BPM community” has made a claim that modeling leads directly to completed applications.

While I hope the histrionics continue, this is really nothing more than two purists trying to keep their rivers from converging.  (I gotta admit that I find these near-screaming matches to be more educational than so-called “polite debate” for the very simple reason that they strip out the fluff in favor of direct frontal attacks everyone can understand.)

We all know from long, bitter experience that the “third rail” in the Microsoft world (touch it and die) is developers. MSFT will do what it takes to keep developers tied to the Windows API. Anything that could loosen that death-grip is a danger, and that includes end users working in standards-based tools that could care less about the underlying OS.

And from what I’ve read about the “BPM community” there’s a fair bit of wishful thinking there, too. Bruce is probably correct that no responsible entity has claimed what he believes Nick is claiming. Yet, you don’t have to say the “E” (execution) word outright to lead people to the conclusion that your BPMS does it directly from pretty pictures. Go ahead, spend five minutes on Lombardi’s site and tell me you don’t see it there.

What do we care? Well, let me be the first to pre-announce our upcoming ActiveVOS release, scheduled for mid-August, in which we actually converge the rivers. We will have the most complete BPMN modeling capabilities and, of course, we have the world’s best and most complete BPEL deployment, execution and management system.

ActiveVOS will make it possible for business users to come very, very close to execution via BPMN. And we believe that developers will take that non-executable model and “finish” it in a 100%-standards-based environment that frees them and their businesses from .NetJail.

Forgive me the nested platitude, but the issue boils down to that old saw that says, “Get the right tool for the job.” Developers need modern, standards-based languages that execute on the metal; business analysts need modern, standards-based ways to describe what systems have to accomplish. Being doctrinaire about which is the “correct” way to serve business and IT is beside the point.

So, while it’s fun to see the purists bloody each other, we intend to deliver an implementable, cost-effective and complete way to achieve what neither side really seems to want. And that, dear readers, is what a visual orchestration system is all about.

Tags: , , , ,

6 Responses to “Bitch slappin’ BPMS: a BPMN and BPEL war of words”

  1. Bruce Silver Says:

    Slapped down good, I guess, since so far Nick has shut up, not put up. I don’t think I’m a purist, but I am a member of the so-called BPM community, and while that community does not speak with a single voice, I think I’m correct in saying Nick’s characterization of BPM is an outsider “making it up.” One quibble I have with your piece is that point-click implementation design without code - even if you do it all in BPMN proper (impossible) - is not the same as implementation by business users. It sounds like your company, along with many others in the BPMS world, is offering the former. I think the nub of the issue is that the target user of your design tool or Lombarardi’s is considered by guys like Nick to be a “business user.” Real business users would laugh at this (or like me, consider it just out of touch).

  2. Nick Malik Says:

    Clever play on the debate. Best of luck with your new release.

    I’m a fan of good tools, and it sounds like you have a fairly good product. I’d like to correct one potential misinterpretation that your readers may get from all of this: I do no speak for any Microsoft product or even for the Microsoft corporation. I am simply a vocal guy who happens to be an Enterprise Architect at Microsoft.

    Believe it or not: I’m quick to agree with Bruce about one statement that he made: business users do not develop ‘executable’ anything. Not executable BPMN nor BPEL (which is by definition, executable). They need a model developer (emphasis on “developer”) to create the application for them… even in your tool.

    And that won’t change. I’m not implying that there is anything at all wrong with your tool. To be fair, I have not reviewed it, and I hope you forgive me that I don’t have the time to do so. I’m not criticizing your tool. I’m simply pointing out that, as a general purpose tool, you are effectively creating a general purpose programming environment. Your environment, and approach, does not make the assumption that you can go without code, but it is still a programming environment.

    Executable business process management has a place, but for us to see the ability to create a general purpose application with BPM as the primary value point, we will have to see a rich environment that includes all of the business information and a huge ‘library’ of functionality. That can be done. Your app, along with a very complete and consistent enterprise architecture that includes services, MDM, and a rich data environment, has a good shot at building that app. On the other hand, the conditions that make that possible are uncommon.

    And that is why I feel that BPM tools will fail to live up to the hype. Because the incremental value that they add is small compared to the cost of developing the rich data and functional environment in which they will prosper.

  3. Alex Neihaus Says:

    Bruce, Nick: thank you both for commenting here and clarifying your remarks.

    Bruce, I hear you that the term “business user” is fungible for many different roles in an enterprise. When we talk about business users working in a visual orchestration system, we mean people who are likely to be documenting in tools like Visio today and who are responsible for working with IT to develop apps. Where they are organizationally varies from company to company, but I agree with you they aren’t necessarily the ultimate end user of the app.

    Nick: I didn’t mean to imply that you speak for Microsoft. And I disagree that enterprise architectures have done much — or will do much — for the ultimate business end user. That’s because a typical piece-parts architecture is so darn hard for developers to use that nothing gets done on it and they remain fat, dumb and happy in Java. (OK, some small percentage are doing apps in C# (-: )

    Our concept of a visual orchestration is focused on precisely this problem: give developers an integrated, all-in-one toolset that works, is standards-based and which promotes collaboration with the business users.

    A VOS renders the debate about which ESB, which registry, how to secure messages irrelevant. With VOS, developers get to the heart of the problem: creating modern apps.

  4. Jim Ballas Says:

    Good discussion…
    The closest that a tool has come to something a business user could use to develop an executable app is the visio plugin from itp-commerce. It can guide a user through a process of converting a powerpoint to a BPMN, and has a nice interface to attach services to the activities. Being probably the only environment that isn’t eclipse based might be one reason it comes closes to the goal, IMHO.
    Jim

  5. Luc Clement Says:

    Jim,

    I’d like to point out that in just a few week Active Endpoints will be shipping with the ActiveVOS 6.0 release “ActiveVOS Designer for Business Analysts”, and integrated BPMN modeling and simulation with “ActiveVOS Designer”. We’re targeting the former as the name suggests to Business Analysts and application architects they work with. The modeling and simulation components that ships with “ActiveVOS Designer” are on the other hand are targeted at the developer and the application architect they work with.

    Our goals were simple: help document requirements, and drive Business and IT collaboration. As usual, the team outdid itself. Why stop at modeling and simulation when you can add KPI and Goals; export to various document formats; make seamless the transition from the “model” to “implementation” and vice-versa, and finally directly incorporate people and services up front.

    Not only will it allow you to take input from an Analyst presenting you with a Visio diagram, it also will allow you to import (i.e. migrate) UML2 and XPDL, and BPEL of course.

    We’re pumped for 6.0

    Luc

  6. William Vambenepe’s blog » Blog Archive » BPEL as a source of application management metadata Says:

    [...] by a business analyst (a topic that has been discussed at length already, including here, here, here, here, here, here and around the 5 minute mark of this podcast). Today, let’s look at it as [...]

Leave a Reply