Getting the BPM Message Across

Many in business people still struggle to see the role of business process in building better performance (i.e. business results). So I thought I would share this little hook that I developed within one of my consulting engagements. It is based around preparing bread - the components of the bread, the flour, the yeast, the water and then baking it all together for an effective result. In your business it is the dough rising that equates to achieving its performance objectives … however those performance objectives are defined.

Whether aware of it or not, in most businesses the different ingredients are not well aligned or working together as well as they could be. Mixing the metaphors for a moment, they are not rowing together in a coordinated fashion. Business Process Management brings together a range of techniques and approaches—the BPM tool box. The components of this tool box help change agents in the business (the bakers) create their own special sort of dough. At the heart of that is an ongoing enquiry into business processes—if you like the water that binds the flour (your people), with the yeast (the technology).

There may be other subtle ingredients. But cooking is not only about mixing the right quantity of ingredients; it is also how you mix them, and how long you bake the mixture. You might think it is just a question of getting the right measure of ingredients. But first, it is necessary to decide on the sort of bread you want to make, and how it is going to be delivered, to whom. Alongside the choice of people (flour), the most critical element is the water (processes)—the ingredient that binds it all together.

Relatively speaking, adding the technology is the easy part. But it requires a considerable amount of rigor. This rigor is most apparent in the way we understand and model processes—because in the modern BPM technology, it is these models that drive how work is managed and driven through the business. If we want to change the way the business operates, all we then need do is change the models. No programming should be required (or at least only in very specialized cases). As much as is possible, everything is configured with models.

But to develop these models requires a rigorous approach and methodology—one that allows us to bind together (integrate) the people, processes and technology. The problem is that process models are like a bikini—what they reveal is suggestive. But what they hide is vital. (Paraphrasing Levenstein talking about statistics).

This is the central thesis of the BPM Process Modeling Fundamentals training course we have developed within BPM Focus. It not only features the very latest developments in BPMN (developed in collaboration with Stephen White, the main author of the BPMN standard), it also includes complementary techniques that help people really see their processes from a number of different angles. The next iteration of the course is due for delivery in London next week (May 1st and 2nd), then in Washington DC on May 24th-25th and Sydney on June 7th-8th. We are also delivering the course inhouse to a number of corporate clients. It should also be available on-line soon.

It is complemented by another program Ensuring BPM Project Success, which is oriented toward ensuring that BPM Programs are rooted in the organization appropriately (due to run in Washington DC on May 21st and Sydney on June 12th-13th). You could think of this second program as being designed to help you set up to guarantee success in BPM projects (or how to avoid getting egg on your face). It is designed to cure you of the legacy thinking that created the existing mess and provides an actionable methodology and framework for BPM success.

Loosing Touch With Reality

In a recent posting Get Your BPMN Schema Today, Ismael Ghalimi shows how close he has come to loosing the plot. He has certainly moved well away from the reality of standards since he formed BPMI.org with Howard Smith.

Everything has become an element of spin - even down to misrepresenting the article of Bruce Silver. He suggests that Bruce thought “BPDM is essentially useless, and that the BPM industry badly needs an XML schema for BPMN.” While Bruce did talk to the need for robust interchange formats, I didn’t see him say it was essentially useless (although Bruce did demonstrate that he doesn’t really understand software, schemas or the semantics of process … but that is another subject).

Ismael went on …

BPDM, currently developed by the OMG, is presented by its promoters as a universal interchange format for business processes. In reality, it’s an utterly confusing metamodel that brings very little to the table, and is used by legacy workflow vendors as a way to fight against the upcoming dominance of the BPMN+BPEL standard combo. Workflow vendors like nothing more than to protect their respective little niches, and have done a phenomenal job over the past fifteen years of ensuring that no useful standard would ever be developed in the space.

Normally, I wouldn’t bother to comment on such clearly biased diatribe. But as many people never get to read the comments, I thought I should post the carefully worded rebuke that came from Cory Casenove (on of the main authors of BPDM):

We were active in the BPDM specification and feel that some of the views presented here are not well founded and others are out of perspective.

The comments from the author about “legacy workflow vendors as a way to fight against the upcoming dominance of the BPMN+BPEL” is, frankly nonsense both politically and technically. The dominant forces in producing BPDM were BPMN vendors, business and process modeling practitioners, business/process modeling vendors and government representatives – not “legacy workflow vendors” at all. There is no plot and no fight, BPDM fully embraces and supports BPMN and provides added value as we will discuss below. Technically BPDM is a superset of BPMN with added support for SOA – far from the centrally managed style of the old workflow systems. Perhaps we can keep our debate at a higher level.

The observation that BPDM is complex to understand has more merit – but lets look at the context and why;

Process semantics: Some other approaches to process “exchange formats” are little more than pictures in XML. While this provides interchange of the diagram it fails to exchange a process specification. One of the reasons that BPDM took so long is that nailing down what is really being said in process models is harder than it may appear, the team had the advantage of being able to work with the BPMN team directly, to iron out the real semantics – and there were a lot of arguments and disagreement about what they really meant. BPDM captures the result of this and provides a way to exchange the process semantics, not fuzzy pictures or partial thoughts. Semantics like this does take more time to grasp – but the result is REAL sharing of process, not lock-in to different vendor’s interpretations and extensions.

Integrating process and SOA: Process orchestration is a valuable tool in the enterprise toolbox, but not the only one. Process is part of the business model that includes services, organizations and resources. The SOA perspective in particular has been fully integrated so that the process for doing and the services offered and used are well integrated into a coherent enterprise perspective. BPMN can’t fight SOA, it needs to join it. Orchestration and SOA are just different ways to look at process. BPDM provides a bridge between those views. That bridge can be ignored by those who only want to understand orchestration, but we don’t think it will be ignored by the users who need both.

So this additional “complexity” of actually understanding what processes mean and how they relate to services and other processes has an impact, but that impact is primarily the responsibility of the builders of process tools, frameworks and infrastructures – perhaps having them take the time to understand the semantics behind their diagrams and runtimes is a good thing, I’m sure they are more than capable of grasping it.

There will be an open source Eclipse based implementation of BPDM on ModelDriven.org/bpdm as well as a schema for interchange – those who just want to know how to exchange BPMN models can use this, without the complexity. Perhaps we can also use this forum for an informed debate on the best way to represent process and provide the best approach to our communities and organizations.

Cory Casanave

Model Driven Solutions (www.modeldriven.com )

Returning From The Cold

Well, after a continued absence, I suppose it is time to make or break with this blog thing. I just dont know where some of my contemporaries find the time. I suppose it is a balance, like everything in life - to keep the fires burning you have to bring in the coal, chop logs, eat, … you can see where I am going with this. With a punishing travel schedule, too many customers wanting work packages completed, completion of another training course (Process Modeling Fundamentals) and an ever present OMG ready to chew any free time, it just never seemed to be high enough up my agenda. But enough excuses - there are so many things that have happened, spin-pieces written and misleading posts that I really do need to put a few stakes in the ground. So with luck, I will get back to a quick post every day or two.

Lets start with the major step forward that happened at last month’s OMG meeting. BPDM was voted through for adoption by the Business Modeling and Integration Task Force. With a couple of notable abstentions from major vendors (not wanting to rock the boat but not quite ready to endorse), virtually every voting member gave a resounding yes to the hard work that has been put in by the team. (You can find out more about BPDM here.

Of course it wasn’t universally welcomed. We have a few die-hards in our industry who try and spin everything to their benefit (well I suppose most vendors could be put in that bucket). Any standard they have not been involved in developing, they are not interested in seeing being adopted widely. Especially one as far reaching and important as BPDM.

Not surprising really - these standards represent real software development costs for vendors (and in the end customers). For instance, if you had placed all your bets on BPEL delivering the answer to world peace, and outsourced (open sourced) all your development to your customers, then the emergence of a new direction in how business process models are managed and interchanged is nothing short of a major threat. Alternatively, if you had placed the UML metamodel at the heart of your software architecture, then the emergence of another metamodel at the higher business level of abstraction (rather than being purely software focused) just represents further investment (with little prospect of immediate ROI).

At the heart of BPDM is support for both the orchestration and choreography sides of the process coin. Orchestration is the bit we are all used to - purposeful activity strung together in a sequence. Choreography is more about the interactions of the roles involved - be they business partners and the company, internal roles or even between software services. Choreography is becoming ever more important as people start to realise that a serial input-output perspective of process doesn’t help you much when you have thousands of associates working on a problem in parallel (a subject I explored here). The point is that this sophistication is set to enable the next round of innovation in BPM.

A lot of energy is now being focused around creating the next version of BPMN which is set to be extended folded into the BPDM metamodel. It was really interesting to see who was now becoming very focused about making sure the scope of that effort achievable and yet also meaningful.

Most people never need be aware of the intricacies and sophistication of BPDM - it is all about how model information is stored and exchanged between tools. So even the most adept BPM business analyst will never be concerned with it. As far as most of you are concerned, it is just gobbledygook. All the end-user organization need worry about is that their vendor is working toward supporting the standard. Why? Because it will give them true portability and ownership of their important possessions - their process assets.

On the other hand, the vendors of BPM technology products should take a keen interest.

The other big step forward at the OMG was around BPMM (Maturity Model). This is now going through a fast track adoption process at the OMG. BPMM is equally important to the business side. It outlines the long term transformational nature of the BPM journey, describing and highlighting the practices and behaviors as the firm becomes more adept. Based around the 5 layer model we have all become used to in CMM, CMMI and PeopleCMM, it provides a comprehensive assessment mechanism. Knowing where you are is an essential part of working out where you want to get to.

Finally, for those of you who have read this far (it sort of proves you are interested in this stuff), you really should attend BPM Think Tank in Burlingame . Think Tank was a concept I helped put together as co-chair of BPMI.org as a way of getting some conversations going between the various (at that time competing) standards bodies. One could argue that this seminal event led to the eventual merger of BPMI.org with the OMG. This is a real opportunity to learn from the best in the business; to get together with your peers and share knowledge; and to grow a deep understanding of the value and power of process standards.

No other event involves every attendee as a real part of the action. Now in its third year, OMG’s BPM Think Tank is a unique gathering of experts with a highly interactive format that makes it a can’t-miss event.

The format is unique in that delegates spend significant periods to time deep in discussion around the real issues of BPM adoption and implementation. During these Round Table discussions, delegates learn from each other, facilitated by the world’s leading practitioners. They share their experiences and draw out the expertise in the group, before reporting back to the conference as a whole.

To help frame these collaborative discussions, plenary sessions feature a range of unique case studies and keynote presentations that highlight the best practices and pitfalls to avoid on the BPM journey. Other sessions focus on the value of standards and the best practice approaches toward their use. A Standards Body Panel session provides the opportunity to clarify the roadmap ahead, while a carefully managed Vendor Panel will explore the challenges and opportunities for technology vendors as we move forward.

The following firms are combining their talents to helping you learn how to maximize your BPM investment:

AFLAC, Allianz, BP Trends, BPM Focus, Bruce Silver and Assocs., Business Semantics, Capability Measurement, EDS, Forrester Research, The General Services Association (US Government), GTE, HandySoft, IBM, Intalio, Kemsley Design, Lombardi Software, McAfee, MEGA International, Microsoft, Oracle, PDL, Pi4 Technologies, Process Core Group, Queensland University of Technology, SAP, Stevens Institute Of Technology, TIBCO

The following standards groups and industry associations are also represented:

ACORD, OASIS, OMG, Supply Chain Council (SCC), TeleMgt Forum (eTOM), Value Chain Council (VCOR), W3C, WfMC

More Information