Another reply to Bruce on this whole BPDM/BPMN debate. Yes, Bruce, I think this issue has very little to do with XML, BPDM or BPMN. I think this issue strikes to the heart of the matter: BPM is disruptive. Powerful, entrenched, legacy vendors don't like disruption. BPDM and the concepts inside BPDM are the most transformative of anything the BPM technology industry has seen so far. This is a chess game that's being played, not checkers...

Bruce,

No matter how you spin it, IBM/SAP/Oracle interests are offering up a new XML representation limited to, basically, what BPMN did four years ago. Why is that, Bruce? Why are we debating "how best to stand still" instead of "how can we get all this brainpower from IBM, SAP, Oracle, Lombardi, Mega, etc." together to extend BPMN to cover all the great business power in BPDM? Instead, IBM/SAP/Oracle are spending their time making sure the BPMN spec stands still, so that we're all, as Tom Waits put it, "waiting until yesterday is here."

I've come to the conclusion that this shift in power of process application development inside end-user companies is such a major change that the vested interests of IBM/SAP/Oracle will fight it. This is a change on par with what happened in the '80's as we moved to desktop computing. It's not some big conspiracy theory I'm advocating... it's just business. BPM is about changing the way business runs, using model-driven technology as the prime enabler of this change, and integrating real business people into a radically different software development life-cycle. Vendors who have billions of dollars invested and at stake have no interest in disruptive changes to the SDLC. They have an interest in the status quo.

Most of the elements of BPDM that are so "hard" are, in fact, elements that have always been planned for notation in future BPMN versions, like choreography. These have been discussed for BPMN since the BPMI.org days! So why is there so much push-back? Why aren't we having a very different debate? For example, it would be more interesting to me if the question was "how can we accelerate the choreography concepts of BPDM into the BPMN notation?"

But we're not having that debate. We're not using these 18 months (that's how long BPMN 2.0 will take, start to finish) to push the notation radically forward. We've got a lot of smart people arguing over a metamodel - again! We're wasting time - again! Why not leverage work that's been done (BPDM) instead of wasting time proposing yet another metamodel?

Those of us "on the BPDM side" want to change how businesses are modeled. We want to move business modeling forward. Why would we spend 18 months doing what can be done today perfectly well with BPMN and XPDL. If IBM/SAP/Oracle are really serious about easy-to-use serialization, then why don't they simply do this: release your BPMN tools today and have them serialize using XPDL. You can do that today. It's easy. I'll put this link in so their developers can easily find it. If IBM/SAP/Oracle adopted this serialization mechanism, it would be the standard, no question.

Instead they're stealing time... trying to get us to wait until yesterday gets here.

The power move is to embrace the concepts in the BPDM specification, and design a more powerful notation for them, while also embracing all the existing elements of BPMN. That's a notation worthy of our best efforts.

Whether we bite off the complexity of BPDM today, or in the future, we will have to bite it off. It's not the mechanics of BPDM that are scaring IBM/SAP/Oracle, it's the concepts. And those concepts - powerful business concepts - will prevail, it's just a matter of time. I'd prefer to accelerate the change, they'd prefer to slow time down, to wait until yesterday comes.

But don't be fooled as to the issue: this isn't about XML, it's about strategy. It's about BPM.

Phil

In a recent post, enterprise architect James McGovern wondered whether BPM products, like Lombardi's, support XACML.

So I replied with a comment discussing BPM and security mechanisms:

With respect to security there are two fundamental issues: who are you? and what do you have access to? In general, the OASIS SAML specification deals with the former, and the OASIS XACML specification deals with the latter.

Lombardi Teamworks explicitly supports SAML as a means of identifying who you are and passing that around. Very few, if any other, BPMS vendors support SAML and it's a non-trivial specification to implement. Lombardi Teamworks does support SAML and as a result, we have many very secure implementations and customers.

Authorization is a bit different. Generally speaking, XACML defines (1) the mechanics of defining a central set of authorization policies, and (2) how a service accesses those policies. That is, and this is key, you want the service being accessed to be its own enforcer, based on policies set in the central policy repository.

You want the called service to ask the calling application for credentials, and you want the called service to be the one that _allows_ access based on the policies. So as we see, the XACML check is done under the covers of the web service that "houses" the resource being called.

BPMSs (not just Lombardi's, but all of them) don't actually house the interfaces to external services, but rather hold pointers to those services. These are held as metadata inside the process definition. For example, the service endpoint address URI is stored, but not the WSDL. Therefore, the [XACML-based] security implemented under the covers of the web service operates independent of the BPMS [or any other client]. However, in most advanced organizations it relies on the SAML (or other) assertion of who you are and what context (application) you are running within. This is why it's the SAML implementation that forms the basis for security in the BPMS world.

James reflected on this in a subsequent post, and in that post he raised a few more questions... so let's continue the conversation...

1) When the BPMS is the service provider (not the consumer)

James says "the rationale for storing policies centrally is more than just one product needing to be its own enforcer. In an integrated world where a BPM engine needs to talk with an ECM engine, the need for these two to have the same access control policies is important."

Yep, I agree. I didn't make reference to it in my post, but of course for any services you expose from a BPMS (or ECM, or ERP or other platform) you should be able to author them so that the centrally defined policies govern who has access to that service. I suspect that all BPMS allow for this.

2) User interfaces, security policies and the BPMS

James says "It is good to see that XACML checks are done to protect web services but they may also be leveraged by UI components as well as access enforcement may require displaying or not displaying a particular feature/function."

Having UI's call the central policy server for presentation-layer rules on what aspects of a UI to show would be an interesting thing to debate. I'm not sure I'd agree with that as a good mechanism. It would be better for the presentation to drive itself based on the types of data that were presented to it (in the same way that device-dependent presentations are derived). That is, you don't want the presentation layer figuring out the security because that assumes the presentation layer has access to everything to begin with. So I guess I would take issue with the premise.

If, however, you want to drive your presentation-layer in this manner, you probably also want the presentation layer up and outside the BPMS. So while in Lombardi's BPMS (Teamworks) you can author UIs, we also give you the ability to easily plug in your own UIs for particular steps in the process. This would be the mechanism to separate the UI from the process definition, and also allow you to drive the particular UI from centrally-defined policies.

3) On BPMSs storing their own users

James says "I think many would agree that a BPM engine should store processes not users."

Yes, I agree. At Lombardi, you don't have to manage users in our store, if you manage them elsewhere (like LDAP or AD). I would say, though, that in the real world we've found that there are attributes you want to use in a process-context that aren't present in your corporate systems. These may be user attributes (like skill level for a particular job) or they may be role-related (a person's relationships to others change depending on the process context).

So in Teamworks, you have the ability to not only use the central user store, but, if you desire, you can also extend the attributes for a user (or role) without mastering that user... sort of a hybrid system. Again, if you manage the attributes centrally then the BPMS will pick them up. It's a matter of choice, and, to some degree, practicality.

We also think this "relationship" issue is bigger than LDAP and AD. Of course, matrix'd organizations have existed for a long time, and these basically reflect that my relationship to people around me change depending on context. For example, the CIO of Company X reports to the CEO of Company X for operational issues, but may also report to the CIO of ParentCompany Y for other things (like use of standard technologies).

As companies begin to measure more of themselves using process as the normalization, then these numbers of "matrix organizations" expands. So we think that organization modeling is part and parcel of the larger BPM discussion... and that these models will integrate with [LDAP or AD], but provide more extensive information. This is an area that I think will really change and expand in the coming decade, as the convergence of increasing security along with increased decentralization of computing resources gets mainstream emphasis.

Conclusion

Securing distributed systems has been long overlooked due to real-world needs to get technology out the door. But this aspect of enterprise architecture is critical to successfully embracing not just distributed technologies like BPMSs, but also important so-called social computing platforms like wiki's. Without good guidelines and well thought out policies, companies just won't embrace these critical technologies. And as a big company, it is critical you be able to embrace these because your smaller competitors are, and they are stealing your most profitable customer and product segments.

Thanks, James, for a good forum to have this conversation.

Technorati Tags: James McGovern, Security, SOA

Seems like there's been a lot of things going on in the BPM space over the past few weeks. Bottom-line? End-user organizations win as vendors as diverse as IBM, SAP, Capability Measurement, MEGA and Lombardi agree! The BP-* stack is on track... here's a couple of them, courtesy Object Management Group...

Business Process Maturity Model: The OMG formally approved the BPMM specification last week in San Diego. This is a great thing for the industry, as it provides a reference model for measuring a company's journey to process excellence. As you might expect, the primary beneficiary of process excellence is making the people in your company more efficient. Far and away the best way to do this is to reduce rework and improve your ability to estimate results. We're talking doubling the productivity of your people! All of your people... so if you want to put a number on the ROI of BPM, just assume you doubled your revenues with the same number of people and then estimate how Wall Street would value your company. That's what BPM can do, over time, and your progress along this is what BPMM measures. Non-trivial stuff. OMG is really stepping out on this one, as it is a business specification with (seemingly) little technology to implement. Of course, my view is that baking in these measurement strategies is exactly what technology can do, so it will be interesting to see how BPMM informs process management software down the road.

Business Process Definition Metamodel: Also formally approved is the BPDM specification. BPDM has been subject to a lot of hyperventilating so here's a bit of history that, hopefully, puts BPDM in its place, and also lets you know the business value of it, and what you should worry about:

1) As good as it is, the BPMN specification as delivered by BPMI.org (of which Lombardi was a member) was an incomplete spec in that it never defined a way to serialize it (a hifalutin way to say "save it to disk"). It left that up to each vendor who implemented it. Bad idea.

2) BPMI.org merged with OMG about 18 months ago, and a large part of the reason [most of us] chose to merge with OMG was its understanding of model-driven architecture. Specifically, many of the BPMI.org members wanted a standards-based, MOF-based metamodel for BPMN (MOF: a standards-based way to represent model definitions, and a standards-based way to deal with all the things you care about when you save a model definition, like versioning, schema, transformations, etc.)

3) BPMN is assumed by OMG, even though it violates their "rule" that technical specifications have an explicit MOF-based metamodel. BPMI.org members (like Lombardi and BPM Focus) who are interested join existing OMG companies who are already working on a "business process definition metamodel" task force to define the explicit metamodel for business processes generically. The desire to use BPDM as an explicit serialization for BPMN is added to the group's charter.

4) Last week, BPDM is adopted. So now, BPMN has an OMG-adopted standards-based metamodel. In addition to defining the serialization of BPMN in a platform-independent and computationally-independent way, BPDM also adds process notions (such as choreography) that BPMN does not currently support.

5) In June 2007, OMG will be issuing the BPMN 2.0 RFP (essentially the guidelines for a future BPMN 2.0 specification). This will say "merge BPDM and BPMN into one specification." In fact, if and when adopted (probably March '08) BPMN will stand for "Business Process Model and Notation."

6) BPMN and BPDM are technical specifications. They are meant for vendors who are serious about providing robust process solutions that span an enterprise's entire sphere of business processes, which means that they are cross-platform, cross-execution, cross-legacy-system, cross-functional, global environments. BPDM isn't meant to simply "store BPMN into XML." It isn't meant to store only those processes a single engine can execute. It is meant to support many "notations" or views. It's not a specification that you should need to read, any more than you should need to read Microsoft Word's file format specification... but it is able to be understood by many vendors, and across many platforms. There has been some criticism that BPDM is "hard." Well, yeah. For the vendors. But when used, the business benefit is that many tools (provided by vendors who do the hard work) will be able to easily share information. You see, the issue is not whether a specification is "hard" or "easy," but whether the functionality it enables is hard to use or easy to use. And of course, vendors compete in this space. Companies adopting BPDM, like Lombardi and MEGA and others, have an incentive to make interoperability drop-dead easy. We'll do this with BPDM.

7) Why should you care about BPDM then? The only reason to care about any specification is if it drives business value for you. So BPMN & BPDM are important only if you expect to make process improvement an ongoing, enterprise capability. If you're using a BPMS as a point solution for a specific app-dev initiative, they are less valuable (as with any standard, it is when you try to scale across the enterprise that they pay off). As I've explained, BPMN and BPDM will be merging. And, primarily, the changes in the 2.0 iteration will be to BPMN, not BPDM. BPMN will be extended to support the new notions of BPDM, and elements of BPMN will be changed to conform to BPDM. So vendors jumping on the BPDM bandwagon now will have a 1-year head start on the next version of BPMN, which is the primary notation for implementable business processes. So, what's the business value of BPDM? The fact that it represents the next version of BPMN, which is becoming the language for business processes. Vendors who are all about supporting BPMN on top of their process languages (whether those are BPEL, XPDL or proprietary) will be triangulating off of BPDM... the only question is when, and how.

8) BPDM is a huge advance for the industry. Model portability across vendors is pretty important, and this achieves that in a way that is tool-independent (i.e. also notation-independent). The ability for everyone to draw similar pictures using BPMN, and save them using the same file format across tools will expand access to many new users; but the ability to have tools that represent the identical process without diagramming the identical process will move process excellence even further. Concepts like business milestones, as opposed to BPMN activities, for example. In retrospect I wish OMG had simply developed this inside the BPMN spec to begin with... but this does not diminish the value of having this specification approved. We'll correct that mistake over the next year. Until then, let's make sure every one of us vendors moves to this spec... then the move to BPMN 2.0 will be trivial!

9) BPDM was approved by 20 or 30+ organizations at the meeting. The primary contributors to the specification were:

• Adaptive
• Axway Software
• Borland Software
• Model Driven Solutions
• EDS
• Lombardi Software
• MEGA International
• Unisys
• BPM Focus
• U.S. National Institute of Standards and Technology (NIST)

It was a good week for end users, because the notions of business value and, in BPMM, business-facing standardization of process excellence techniques and technologies were advanced.

Technorati Tags: BPDM, BPMN, OMG

You can't judge a book by it's cover. Today we have autobiographies that turn out to be fiction, and we have fictional accounts of the truth. Why, these days, you can't even tell a book by the book.

I guess it's always been this way. Neither Hemingway nor Malraux could have been who they were without their participation in the Spanish Civil War... who knows how much of their fictional accounts were true? Theodore White and Anonymous both participated in battles of a different kind and wrote non- and fictional accounts of each, respectively. I tend to think that Anonymous's fiction was more accurate than White's non-fiction.

And then there was Hunter S. Thompson. I mean, can you say in. the. moment.? He didn't write fiction or non-fiction. I don't know what he wrote. Drudge meets Jonathan Schwartz maybe. The First Blogger. Hunter S. Thompson: Patron Saint of Bloggers. I miss Hunter but you can't say he ever let a fact get in the way of a good sentence. He didn't even let a good sentence get in the way of a good sentence. And as for history or trends... he'd shoot before worrying about such weighty matters. He just participated and then wrote about what he'd participated in. Or wrote and then participated in what he'd written about.

What's all this got to do with "process"? Well, nothing really. But there is the ever-present hype factor of technology, the myth of the silver bullet all told with the straight face of the zealot-vendor or zealot-open-sourcer. What's real and what's fiction?

Today I read Kiran K. Garimella's new book The Power of Process. I was pointed to it by James McGovern, who says it's "one of the most enjoyable reads I have had in a long time." Hopefully James meant "one of the most enjoyable business reads" he's had in a long time. If not, James, here's a few truly enjoyable reads of my past month: Carter Beats The Devil, Peter Guralnick's Dream Boogie: The Triumph of Sam Cooke, and And A Bottle Of Rum: A History Of The New World In Ten Cocktails. Less enjoyable but a solid business read is Patricia Seybold's latest: Outside Innovation (get it?).

Not wishing to bury the lead (led, actually, if you're a journalist) below the sixth paragraph: I recommend Garimella's book for IT people who are tasked with "selling" BPM to the business. It's an effective distillation of many of the concepts of BPM and does a good job of staying above the fray. I think some biases do come out a bit... but overall Kiran does a very good job of dealing with the big topics of SOA, Six Sigma and LEAN and their relationship with BPM.

The book is written in the fictional story-style of The Goal, so it is easy to read and because it's written this way, he's able to have characters ask the questions you'll be asked and delivers the answers without it being dry.

Overall, Garimella walks through the TLA's with humor and gives pretty much just the right amount of airplay to them. He does a great job of articulating that BPM is not SOA, and also that BPM is more organizational than technical.

But the book suffers from some confusion. Although at the outset, Garimella has one of his characters state clearly that the implementation is distinct from the architecture [of SOA], he routinely gets implementation confused with architecture (and process management) throughout much of the book. This is particularly evident when he talks about modeling and executing. His main BPM protagonist in the book correctly identifies MDA (Model Driven Architecture) as the basis for abstracting the Process Model from the real-world implementation, but he then drives right down to the [so-called] benefits of the BPEL execution language. MDA is, in fact, rooted in the belief that the model is abstracted from the implementation. They, in essence, have nothing direct to do with one another. The model is transformed into an implementation, and the implementation can be one of many.

For those of you who don't know my biases, let me give it to you straight: BPEL has nothing to do with Business Process Management. It has nothing to do with BPMN portability. It is an implementation language that, if used at all, generally impedes agility and increases cost.

However, the principles of MDA are the basis for modeling the business. MDA rests on the foundation of having a CIM, or Computationally Independent Model. This is where agility, portability and re-factoring are enabled - at the CIM level. The corollary to being independent of implementation constraints means that I am also able to choose different implementation mechanisms for different types of problems. Who cares how a process is implemented if the following exists:

-- we share a common understanding of the process ("share the model")
-- that common understanding is faithfully executed ("the picture is the process")
-- the common understanding can be shared with others ("the model is portable")

The more the industry focuses on implementation, the more BPM is just the same old thing.

In addition, as Garimella points out really well, understanding messages in the context of the process (call this "BAM" for now) is far more important than requiring a particular implementation mechanism. Thus, modeling using an implementation-independent model is key to modeling processes that live (and report, and can be managed) on top of many different types of systems, services and people. Indeed, for processes at companies of any size whatsoever, being able to model "above" the execution layer is required, given the investment and magnitude of existing legacy systems.

And now for a word from our sponsor...
Of course, OMG (the Object Management Group, an international standards organization) is "father of MDA." And, the OMG's combination of BPDM (for BPM models) and UML (for SOA models) are both standards-based, computationally independent models that deliver the flexibility and portability required for business and service modeling. Transformations off of these CIM's into PIM's and PSM's (simply, the mechanism under MDA whereby a computationally independent model is transformed into a deployable application using one of a number of implementation languages) can be made to Java, BPEL, etc.

And this, James, also answers another question you had a while back, I believe: I think you asked in a blog about your ability to transform from a MOF-based metamodel into BPEL or other execution languages? Yes, coming soon... look for progress on this from OMG sometime between December and March when BPDM is approved (it's final version has recently been submitted, so a vote is forthcoming) and also some good work tying BPEL, BPMN, UML and BPDM together... and you'll be able to measure your effectiveness at doing this within an upcoming OMG-based Business Process Maturity Model...

Kiran Garimella's book is a good read for IT folks needing some concise explanations to technical topics... and watch the OMG for other good news on the standards front about many of the things Garimella writes about...

Technorati Tags: BPDM, BPEL, BPM, BPMN, James McGovern, OMG

In his post a couple of days ago, Bruce Silver despaired at the state of BPDM - the OMG specification that allows for real portability of BPMN. I agree.

You know desperate men,
they'll do desperate things

- Jimmy LaFave

However, standards take time... indeed if you don't take that time then you end up with something that won't be used. And given the importance of business process, and the new process platform that will replace ERP as the center of the business world, I think a few months is not too high a price to pay to get it right.

BPDM stands for Business Process Definition Metamodel. It's a hifalutin way to say "the file format," essentially. One key reason Microsoft Office has become so dominant is that its files are transportable across versions of Office (for the last few years) and across platforms (Mac and Windows). Without that portability, the desktop productivity tools would be a bit more fragmented around the world.

An implementation-independent process semantic is the lynchpin for this new platform. It will provide this common file format for the visualization of business processes (the "BPMN" standard, used in tools from 60+ vendors). It will provide the implementation-independent format that execution-oriented vendors who use BPEL or XPDL can use.

Without an implementation-independent standard, the business process world will splinter into dozens, or hundreds, of proprietary silos. Remember, before Java, what the development world was like? BPDM is for process what Java is for development.

There is real business value here because with this capability, business users can use tools they can use, and then transfer the processes to the implementation folks who can use the same file (essentially) for their work. It's exactly like being able to draft a high level PowerPoint presentation, hand it off to your graphics artist for cleaning up those drawings, and then getting back the revised PowerPoint and being able to use it.

Different tools were used by different people, based on their skills, but it was all able to be transformed from and into a common format - up and down the line.

Those who oppose BPDM are taking a short view, and most likely a proprietary view so that you're locked in to their world or because they don't have the money to invest in standards for their product.

A few months ago, the first semi-public version of the spec was published (it's available to any OMG member), and it has been updated 2 or 3 times since then. In December, after dozens, if not hundreds, of person-years work, the committee working on BPDM is expected to formally submit it for adoption. If everything goes well, the OMG will adopt BPDM and it will be available to the general public in January. There is a chance all this is shifted to March, but for now the BPDM committee tells me they will be ready to make the submission.

But regardless of whether it's December or March, the day is soon approaching when the new business process platform has its equivalent of a common file format. This will unleash innovation among vendors unseen in this space, because then, everyone's tools can work with everyone else.

So keep up the pressure, Bruce... we need to get this wrapped up. But also don't sweat a couple of months and start telling your clients to go to a silo'd implementation language like XPDL... because the dawn of implementation-independent portability is fast approaching, even if it's pretty dark out there right now.

Technorati Tags: BPDM, BPMN, Bruce Silver

The role of technology in the enterprise is changing. Of course, that's not a new idea, but I thought I'd take a moment and discuss how it's changing and why it's important.

The problems with big business today (and, increasingly, businesses in the SMB space too... let's say, above $500 million) is that they are getting too complex to manage effectively. Stated differently, the hodge-podge nature of the underlying systems in a company directly impact the reporting and visibilty that management has of the company. You know the systems and complexity I am writing about: all those which have either been home-grown, bolted onto or added to through acquisition of companies or expansion of product lines... "leading edge" ERP systems based on 1980's technology concepts and 1950's management concepts.... software contemplated before you began outsourcing and offshoring.

I know of one company that just went through an implementation of a "leading ERP application" and they now have less visibility into their products and processes than they had before. And this implementation was just completed! What the company failed to realize is that it wasn't transactions they needed a better system for... it was the newly fragmented processes introduced by their new contract manufacturing model. And ERP vendors offer little in the way of simplifying complex processes that live inside and outside the firewall.

The new software must offer a new paradigm, and new tools, that mask this complexity without forcing you to replace it. The new software must offer the ability to abstract your company and its capabilities so that the visibility and management is independent of implementation. The new software must offer you the ability to define how you want the company to be managed and how you want the company to behave, and then there must be direct, visible reporting linkage to the tasks you want performed and the behaviors you expect.

In short, you need to model your business, and you need to be able to manipulate your business via those models.

This isn't a very business-y word, "model", but it's where we're headed. This abstraction, these models, must allow you to easily see recurring patterns, so that the same model can be used to describe different parts of your business... re-using these models, or processes, over and over.

These models must have built-in notions of visibility and help you to understand whether your business is, in fact, running based on your model, or if you are off course. The model of your company needs to reflect compliance and trading relationships and a host of other details that you just don't have visibility into today... much less the understanding of how you might easily change those things or how that change would impact your performance.

There's a lot yet to be invented here but the first step is understanding this: in order to achieve the economy, the compliance and the agility you must have to compete in the 21st century, you need to eliminate the complexity that today's information systems impose upon you. And this means you need to be dealing with a software representation of your company that is an abstraction of the current "physical" state. This abstraction, this model-based world, is what Enterprise Process Management is about.

This is not about a graphical tool that let's you build an application faster. And this is definitely not about a simple "modeling" tool that doesn't lead directly to execution and visibility. Simply drawing a picture is not a "model-driven business."

A model-driven business requires a new kind of platform, a platform that runs in concert with your existing underlying systems, and helps to mask the complexities of those systems. In fact, so much of the complexity is masked that real people in the lines of business of your company will directly manipulate these models, developing reports, doing what-if analyses, determining in real-time exactly what part of which process has the most impact on some dashboard metric that just went "red."

This is about changing how you manage your company for the better, reducing the complexities (and therefore costs) that have been inserted by doing business in a more complex way than you did business even ten years ago. It is about taking back your business, and using simpler tools with more powerful insight so that, once again, the business runs the business.

Technorati Tags: 21st Century Process, BPM

Just wanted to send a quick note of congratulations to Bruce Silver... six months on the blogroll! During the past six months, Bruce has stimulated a lot of good BPM debate, has stirred up a flurry of commentary and deep analysis of BPM standards and has also brought a bit of needed humor into the mix. At one point he even had Oracle's Edwin K and I agreeing on something... will miracles never cease?

Thanks, Bruce!

Technorati Tags: Bruce Silver

The technology standards organization OMG has painted the issue in stark relief, moreso than any other BPM conference I've attended this year. BPM is about people. People implementing, people using, people changing the way they do business. BPM products and standards have to be useful to these people... Otherwise, the product or standard is useless.

Conferences always have two things going on about them. There is a string of details, and there is an overarching theme. Sometimes, like it is here, these are at odds with one another. So it's ironic that it's OMG's Think Tank that's made it so clear that technology (and related standards) is not the key factor in business process management success.

At the conference we have discussed all the technologies, all the standards: BPMN, BPDM, BPRI, BPEL, XPDL. We've also seen presentations where frameworks were key to success...and others where the lack of a pre-defined framework was the key to success. Yet time and again, the presenters and participants came back to the key ingredients that made their real projects successful or not: the cross-functional set of people and the cultures of the companies doing the work.

Your BPM initiative must focus on creating a culture of (read: incenting) the community of people responsible for and participating in the process, and the community of partners and vendors who will assist you. These people need to be flexible and working within a process or methodology to discover, define, implement, use and improve a process in the context of business goals.

This focus on business goals and the cross-functional set of people (vendors and partners included) is required for BPM success, regardless of tools and technology. Be sure you have the right team.

- Phil Gilbert (via mobile)

There's been an interesting back-and-forth between Edwin Khodabakchian of Oracle and Bruce Silver of Bruce Silver regarding BPEL, BPMN and the promise of business process management in general. To get to it, read Bruce's post, Is Oracle Discovering BPM?, and look at all the comments.

In the comments, Bruce and Edwin bring up various of the posts in my blog so I'll take them on as I have time over the next couple of days. I'm doing this in no particular order... but first, let's get right to the heart of it: Do I hate BPEL?

Words Matter (unless they don't)

Bruce sort of lumps me into a "BPEL-hater" camp, and Edwin then proceeds to discuss Oracle's take on BPEL, BPMN and a host of other things. Now, I've spent a bit of time around politics and know the best way to pigeonhole someone is to say, for example, "do you think BPEL is key to solving world peace or are you a BPEL-hater?"

Well it's neither, so, right here right now I'll take the oath and state categorically, without hesitation, equivocation or mental reservation: I neither love nor hate BPEL. I'm a BPEL agnostic. Why? Because I think BPEL has nothing to do with the management of business processes. And I believe that the management of business processes is what business process management should be about.

Non-intersecting non-parallel lines

BPEL is orthogonal to the problem-space of managing business processes, and of becoming more process-centric as a business. It is an execution language that, if your BPMS requires code, arguably makes writing that code easier (as Edwin points out, it includes more workflow semantics than other languages; it also assumes a world of web services. It also has limitations, which proponents promise to iron out in spec changes and proprietary extensions over the next few years). But being able to tell a computer chip about a process (i.e. writing code) is the least interesting aspect of aligning a company around process. In fact, as I have argued, if you have to code up a process, then you are probably impeding the business change that you were, in the first place, striving for.

Just because BPEL is called the "Business Process blah blah blah," don't confuse it with business process management. IT vendors are horrible about conscripting business-sounding terms to describe technical mish-mash, and then trying to define a business problem as something their technology solves. It happened with "business rules" and now it's happening with "business processes." (Sidebar: like business processes, which do and will continue to live everywhere, whether written in BPEL or not, business rules exist in a lot of places and you should optimize where they live based on ease-of-change and governance issues, not on dogma around a single "business rules repository" just because it uses the moniker "business rules").

In fact, my whole point is that business process management (lower case) is nothing to do with an implementation language. Companies that successfully implement bpm strategies will do so irrespective of what language they choose; there will be zero correlation between companies who are successful and what language they choose. Quick, how many great processes at Dell and GE and Wal-Mart are written using BPEL? Yet, they seem to be doing an OK job of things. Were BPEL available in 1992, can you imagine Lou Gerstner lining up everyone and saying "OK, we're going to save IBM by using BPEL." If you think so, reread "Elephants Can Dance" to see how it really happened. Governance. Alignment. Change. From the business. However, I CAN imagine a CEO today lining up everyone around a bpm transformation, and using that as a catalytic converter...

The technology portion of business process management demands an integration of technology into the fabric of the business... a technology embed... and this will result from tools that look and feel more like Word than Visual Studio; more PowerPoint than Visio, even. BPMS vendors who focus on the language of their engines, rather than the business problems of their customers, have failed to achieve significant market share, and they will continue to do so.

Enter Christopher Locke from The Cluetrain Manifesto, "Too much development is focused on whiz-bang technology, and not nearly enough on the cultural revolution all this implies and in fact demands. Imposed infrastructures hinder more than help. Most so-called empowerment initiatives are embarrassingly paternalistic, to the point of backfiring entirely."

The key to BPM is a less-code future, not a "this is the type of code you write" future. Any serious advance in bpm technology would be away from YAWL, and toward business facing tools that describe, via metadata, process behaviors. Advanced engines in all realms will be virtual machines, interpreting metadata in, essentially, real-time. BPM should be no exception. To strive for code seems wrong...

The keys to managing business processes successfully

Above, I posited that BPEL won't be a correlating factor in whether companies achieve success in transforming themselves around a process notion. There will be high correlation of success among companies which:

• Decide to manage themselves, or at least core capabilities, in a process-centric manner. This is a business imperative, not an implementation imperative. Many implementation methods will achieve success, including BPEL implementations. The technology component of this will be a new set of tools that the business can use to drive and integrate IT with more velocity than they've been capable of doing in the past. This is key... the limitations to date have been less about IT's unwillingness (or even the supposed Business-IT divide)... it's been about the capabilities of the business to confidently engage in conversations with the technical people. Great BPMSs will foster that conversation through new tools that engage the business more effectively in all aspects of the process lifecycle, from the beginning and then in continuous change cycles.
• Provide strong leadership from the top of the organization on both business and IT sides, embracing a process-centric approach to business design ("business SOA") and technology implementation (BPM on top of SOA, and as a driver of SOA). There will be more common traits among the leadership of successful companies than among the implementations.
• Standardize on a common graphical representation of the process across all users at run-time, at simulate-optimize-time and at design-time. (Fyi, I use the term "simulate-optimize" to distinguish the analyst's activities between running "what-if's" based on simulation data vs. historical data. Both are important and have different uses during the process lifecycle). At Lombardi we use BPMN for this, but the issue is that your organization uses a consistent standard that is rich and includes all aspects of a process's behavior. Global rules and events not depicted on the diagram will impede your ability to scale, and will impede agility, so be sure the modeling best practice fully describes the models, in the modeling tool. BPMSs that require experts to understand the system once it's deployed will fail, because the whole point is to continuously be able to change. If global rules or events are affecting the a given process, then my ability to pass ownership around is non-existent. We're back to Old School. The promise of BPM is achieved only if the model is depicted as surely as a map. Trade increased when trade routes were fully documented and could be read by all the sailors. In the same way, trade will increase as we scale our processes, and BPMSs are the systems upon which the corporate maps are drawn and executed.
• Embrace tools that foster business and IT participation during simulate-optimize-time and design-time.
• Ensure tools that provide 100% round-trip engineering, so that there is no manipulation of code independent of the graphical depiction of the process (the process cannot get "out-of-sync" and you are able to seamlessly move from the graphical model to execution of any version of the process). This is commonly referred to as a "shared model architecture." Now, to Edwin's point, you might be able to manipulate code directly, or manipulate the diagram directly - either may be done in a shared model environment. But, if you make a change in one place, it MUST be represented in both without hand-retooling. The best of the environments will allow you to use a modeling tool to its fullest extent AND run that process. If you need to constrain the model (as in a BPMN to BPEL constrained view of the world) you insert friction into the modeling exercise, and lose business users. Otherwise, process understanding is impaired, execution does not match the (documented) diagram, and we're back to being "monkeys with pants" as the Ask.com commercial says. With BPMN to BPEL implementations, you get a proprietary interface that attempts to translate something which per the standards doesn't translate exactly... beware of so-called "round trips" between BPMN and BPEL. The specs are defined, and they don't match up. And they won't match up for some time.
• Standardize on BPM tools that incorporate strong BAM, event handling and correlation on business events. These aspects of process applications are generally the key to higher value. These elements must be present in the graphical model (diagram). The business should be able to model the event flows as easily as the human interactions. Not implement, but model them.
• Standardize on BPM tools that provide superior levels of out-of-the-box visibility into processes built using those platforms. This is because very few organizations really build all the reports they intend to build... therefore out-of-the-box process-specific reporting is essential for real-world success.

Conclusion - I don't hate BPEL and I don't love it, either

BPEL iisn't about visibility, and it's not about change management, yet those are the central problems of business process management. BPEL as a technology is orthogonal to the problem of business process management.

It's simply a new way to write code. It has nothing to do with the management of business processes. I don't love it or hate it; other than that it is a distraction. BPEL isn't necessary to achieve the benefits promised by business process management - and therefore it's an impediment in the market conversations that are occurring with respect to business process management.

BPM is about the business, and more specifically about driving a change-oriented process culture into the business, using the enablers derived from the internet technologies and their forebears. Indeed, if BPMSs were to become synonymous with BPEL engines, then the business benefits of BPM would be reduced to the efficiencies of a few people writing a few programs. The bpm cause would be set back for years. That would be a shame.

Interestingly, Edwin stated it perfectly when he wrote that "BPM is a promise/a vision. A promise that users will take control of their business processes by having better visibility into them and by being able to continuously adapt and extend them." That's wonderful!

That's a big vision. It's an inclusive vision that embraces millions of people improving their work lives and expanding their markets. Let's work on that, not on which language a given programmer should use. Programmers are already involved in processes, and they're not the bottleneck. Business participation is the issue, and BPEL doesn't help that a bit.

Technorati Tags: BPEL, BPMN, Bruce Silver, Edwin K, Oracle