Column 2 by Sandy Kemsley : BPM standards

{ Category Archives } BPM standards

Architecture & Process keynote: Bill Curtis

The second part of the morning keynote was by Bill Curtis, who was involved in developing CMM and CMMI, and now is working on the Business Process Maturity Model (BPMM). I’ve seen quite a bit about BPMM at OMG functions, but this is the first time that I’ve heard Curtis speak about it.

He started by talking about the process/function matrix, where functions focus on the performance of skills within an area of expertise, and processes focus on the flow and transformation of information or material. In other words, functions are the silos/departments in organizations (e.g., marketing, engineering, sales, admin, supply chain, finance, customer service), and processes are the flows that cut across them (e.g., concept to retire, campaign to order, order to cash, procure to pay, incident to close. Unfortunately, as we all know, the biggest problems occur with the white space in between the silos when the processes aren’t structured properly, and a small error at the beginning of the process causes increasingly large amounts of rework in other departments later in the process: items left off the bill of sale by sales created missing information in legal, incomplete specs in delivery, and incorrect invoices in finance. Typical for many industries is 30% rework — an alarming figure that would never be tolerated in manufacturing, for example, where rework is measured and visible.

Curtis’ point is that low maturity organizations have a staggering about of rework, causing incredibly inefficient processes, and they don’t even know about it because they’re not measuring it. As with many things, introspection breeds change. And just as Ted Lewis was talking about EA as not just being IT architecture, but a business-IT decision-making framework, Curtis talked about how the concepts of CMM in IT were expanded into BPMM, a measurement of both business and IT maturity relative to business processes.

In case you haven’t seen the BPMM, here’s the five levels:

Level 1 - Initial: inconsistent management (I would have called this Level 0 for consistency with CMM, but maybe that was considered too depressing for business organizations). Curtis called the haphazard measures at this level "the march of 1000 spreadsheets", which is pretty accurate.
Level 2 - Managed: work unit management, achieved through repeatable practices. Measurements in place tend to be localized status and operational reports that indicate whether local work is on target or not, allowing them to start to manage their commitments and capacity.
Level 3 - Standardized: process management based on standardized practices. Transitioning from level 2 to 3 requires tailoring guidelines, allowing the creation of standard processes while still allowing for exceptions: this tends to strip a lot of the complexity out of the processes, and makes it worth considering automation (automation of level 2 just paves the cowpaths). Measurements are now focused on process measures, usually based on reacting to thresholds, which allows both more accurate processes and more accurate cost-time-quality measures for better business planning.
Level 4 - Predictable: capability management through statistically controlled practices. Statistical measurements throughout a process — true process analytics — are now used to predict the outcome: not only are the measurements more sophisticated, but the process is sufficiently repeatable (low variance) that accurate prediction is possible. If you’re using Six Sigma, this is where the full set of tools and techniques are used (although some will be used at levels 2 and 3). This allows predictive models to be used both for predicting the results of work in progress, and for planning based on accurately estimated capabilities.
Level 5 - Innovative: innovation management through innovative practices. This is not just about innovation, but about the agility to implement that innovation. Measurements are used for what-if analysis to drive into proactive process experimentation and improvement.

The top two levels are really identical to innovative management practices, but the advantage of BPMM is that it provides a path to get from where we are now to these innovative practices. Curtis also sees this as a migration from a chaotic clash of cultures to a cohesive culture of innovation.

This was a fabulous, fast-paced presentation that left me with a much deeper understanding of — and appreciation for — BPMM. He had some great slides with this, which will apparently be available on the Transformation & Innovation website later this week.

Now the hard part starts: trying to pick between a number of interesting-sounding breakout sessions.

BPEL for Java Developers Webinar

Active Endpoints is hosting a webinar this Thursday on BPEL Basics for Java Developers, featuring Ron Romano, their principal consulting architect. From their information:

A high-level overview of BPEL and its importance in a web-services environment is presented, along with a brief discussion of the basic BPEL activities and how they relate to Java concepts. The following topics will be covered:

Parsing the Language of SOA with Java as a guide

Breaking out of the VM: evolving from RPC to Web Services

BPEL Activities - Receive, Reply, Invoke

BPEL Facilities - Fault Handling and Compensation (“Undo”)

The VP of Marketing assures me that he was allowed only two slides at the end of the presentation, and that otherwise this is focused on the technical goodies.

You need to register in advance at the link above.

BPMN survey results

I really didn’t sit down this afternoon to write that last enormous post on the Great BPMN Debate, I remembered that Jan Recker (co-author on the research paper that sparked the debate, although not a participant in the debate) had sent me a pre-release copy of a paper that he authored, “BPMN Modeling — Who, Where, How and Why”, which summarizes the results of the survey that he conducted last year. One thought led to another, and before you know it, I’d written an essay on the most exciting thing to happen in BPM standards in ages.

Back to Jan’s paper however, which will be published this month on BPTrends. He surveyed 590 process modelers using BPMN from over 30 countries, and found some interesting results:

BPMN usage is split approximately in half over business and IT, which is a much higher percentage of IT users that I would have guessed. Business people are using it for process documentation, improvement, business analysis and stakeholder communications, whereas IT people are using it for process simulation, service analysis and workflow engineering.
As you might expect given that result, there’s a wide variation in the amount of BPMN used, ranging from just the core set for basic process models, to an extended set, to the full BPMN set. It would be interesting to see a correlation between this self-assessment and usage statistics based on the actual BPMN diagrams created, although as far as I know, the survey respondents didn’t submit any examples of their diagrams.
Not surprisingly, only 13.6% received any formal BPMN training, and I believe that this is the primary reason that most people are still using only a tiny subset of the BPMN constructs in order to create what are effectively old-fashioned flowcharts rather than full BPMN diagrams.

He finished with a list of the major obstacles that the respondents reported in using BPMN, or places that they would like to see improvement:

Support for specifying business rules, which echoes many of the other discussions that I’ve seen around having some standardization between process and rule vocabularies and modeling languages.
Support for process decomposition, although I really didn’t follow his argument on what this means.
Support for organizational modeling, particularly as that relates to the use of pools and lanes: sometimes, for examples, a lane indicates a role; other times, a department. There are some things happening at OMG with the Business Motivation Metamodel and Organizational Structure Metamodel that may help here.
There are some BPMN constructs that are less often used, although it’s not clear that anyone recommended getting rid of them.
The large number of different event types is problematic: “ease of use of process modeling is sacrificed for sheer expressive power”. This is a variation on the previous point (and on the crux of the Great BPMN Debate), indicating that actual BPMN users are a bit overwhelmed by the number of symbols.

I’ll publish a link to the paper when it appears on BPTrends; it’s fairly short and worth the read.

2008 03 13 BPMN Comments (1)

The Great BPMN Debate

If you have even a passing interest in BPMN, you’re probably aware of the great debate happening amongst a few of the BPM bloggers in the past week:

Michael zur Muehlen and Jan Recker publish an academic research paper on BPMN usage, “How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation“, to be presented at an upcoming conference. To quote the introduction in the paper, its aim is “to examine, using statistical techniques, which elements of BPMN are used in practice”, and they laid out their methods for gathering the underlying data. They used some standard cluster analysis techniques to identify clusters of BPMN objects based on usage, and determined that the practical complexity (what’s really used) was significantly different from the theoretical complexity (the total set) of BPMN. Michael teaches in the BPM program at Stevens Institute of Technology, so I wasn’t surprised to see a stated objective related to BPMN training: “BPMN training programs could benefit from a structure that introduces students to the most commonly used subset first before moving on to advanced modeling concepts.” Note that he says “before moving on to”, not “while completely disregarding”.

Michael then blogged about the paper but went further by listing three implications that were not expressed in the paper:

Practitioners should start with the more commonly-used BPMN elements, and leave the more specialized constructs for analysts who will presumably be doing more complex modeling.
Vendors that support BPMN can make a realistic determination of what percentage of BPMN diagrams can be represented in their tool based on today’s usage of BPMN.
Standards bodies should consider if they should be creating additional complexity if no one is using it.

It was these implications that sparked the arguments that followed, starting with Bruce Silver’s post directly challenging much of what Michael said in his post. It appeared to me that Bruce hadn’t read the full research paper, but was commenting only on Michael’s blog post, hence didn’t fully appreciate that the paper was really just analyzing what people are doing now, not making any value judgements about it. Bruce was a bit harsh, especially where he suggests that Michael’s “BPMN Overhead” label on the least-used objects was “clearly meant to mean ‘useless appendages’.” Bruce had some valid rebuttals to Michael’s three implications, and although I disagree somewhat with Bruce’s first two points (as I commented on his post, and was rewarding by Bruce telling me that I was stating the bloody obvious), I agree that the standard makers have not included unnecessary complexity, but that they have created a standard that the market still needs to grow into. However, I find the BPMN specification to be overly verbose, creating a greater degree of perceived complexity than may actually exist.

Michael responded to Bruce’s post by pointing out that the aim of their research was to find out how people actually use BPMN, not how vendors, consultants and standards bodies think that they use it (or think that they should use it). Michael restates his three implications in greater detail, the first two of which seem to align with what I thought that he said (and stated in my comment on Bruce’s original post). His clarification on his third point was interesting:

We actually like BPMN’s advanced vocabulary. But have you asked end users what they think? Well, we did. Not only in this study but also in Jan’s large-scale BPMN usability studies we did find that users are in fact very troubled by the sheer number of, for example, event constructs. Are they used at a large scale? No. Do users understand their full capacity? Typically not. Why is this not at all reflected in BPMN development? That is exactly our point. Sure, our argument is a somewhat provocative statement. But if it helps to channel some attention to end usage, that’s fair by our standards.

Bruce responds in turn, saying that if Michael had presented this as “statistical correlations between diagram elements in a sample of BPMN collected in the wild”, then it would have been okay, but that the conclusions drawn from the data are flawed. In other words, he’s saying that the research paper is valid and interesting, but the post that Michael wrote promoting the paper (and including those unintentionally provocative implications) is problematic. As it turns out, in terms of Michael’s group of the 17 least-used BPMN constructs, Bruce could live without 15 of them, but will fight to the end for the other two: exception flow and intermediate error event. However, Michael doesn’t say that these are useless — that’s Bruce’s paraphrasing — just that they’re not used.

There’s a bit of chicken-and-egg going on here, since I believe that business analysts aren’t using these constructs because they don’t know that they exist, not because they’re useless. Many analysts don’t receive any sort of formal training in BPMN, but are given a BPMN-compliant tool and just use the things that they know from their swimlane flowcharting experience.

Anyway, Bruce finishes up by misinterpreting (I believe) the conclusion of Michael’s post:

Michael ends his piece by asserting that the real BPMN is not what vendors, consultants, and trainers like me say it is, but the way untrained practitioners are using it today.

What Michael actually said was:

[O]ur own experiences with BPMN and with those organizations using it gave us this hunch that the theoretical usage (what vendors and consultants and trainers tell us) often has little to do with what the end users think or do (the practical usage). And why is it important to know what the end users think and do? Because it can help the researchers, vendors, consultants and trainers of this world to channel their attention and efforts to those problems real users face. Instead of the problems we think exist in practice.

Although it’s not completely clear, I believe that Michael is saying that we need to understand what people are doing with BPMN now in order to design both training and systems.

This was an interesting debate to watch, since I know and respect both Michael and Bruce, and I found merit in the arguments on both sides although I don’t fully agree with either.

There was an interesting coda on the validity of BPMN for model-driven development with Tom Baeyens weighing in on the debate and stating that BPMN should stick to being a modeling notation and not be concerned with the underlying execution details: “[t]he properties can be removed and the mapping approach to concrete executable process languages should be left up to the vendors.” Bruce responded with some thoughts on model portability, and how that drives his categorization of BPMN constructs.

If you’re at all interested in BPMN, it’s worth taking the time to work your way through this debate, and keep and eye on Bruce and Michael’s blogs for any further commentary.

2008 03 13 BPMN Comments (14)

BPMN and the Business Process Expert

There’s something funny about chatting via IM with someone as you’re listening to them give a public webinar, even when you do know that the presentation is pre-recorded — I was on Skype with Bruce Silver today during his webinar The Business Process Expert and the Future of BPM on ebizQ, where he was speaking with Marco ten Vaanholt of SAP’s BPX community.

Except for one “happy smiling faces” graphic worthy only of Jim Sinur’s blog ~~pimping~~ marketing team, I really enjoyed Bruce’s presentation, although I’ve heard at least parts of it before. He started with a comprehensive description of BPM and why model-driven design is so critical to process agility, which he segued into a description of BPMN and its importance in making process models executable: the heart of model-driven design. He feels that it’s necessary to define the role of Business Process Expert (BPX): someone that bridges between business and IT, creating executable requirements for BPM solutions. Obviously, BPMN is a critical skill for the BPX, and Bruce offers a number of resources including a free series of articles and e-learning modules that he’s done on the SAP BPX community and the longer paid courses that he offers online and public classes through BPM Institute. No wonder he hasn’t blogged for months: he’s been too busy creating all this.

Marco ten Vaanholt talked about the importance of BPM and SOA — fairly motherhood sort of stuff — then dug into some details of the SAP BPX community, which is an incredibly well-developed resource for anyone involved in BPM, whether you’re an SAP customer or not. The core of the BPX community is collaboration and collective learning on business scenarios, process lifecycles, change leadership, social responsibility, horizontal and vertical practices, modeling tools, methodologies and a variety of other topics. It’s not just a discussion forum, however: there’s a lot of really valuable content, such as Bruce’s articles and e-learning, from both SAP and the community in general.

Marilyn Pratt, the BPX community evangelist, has been keeping me up to date on what’s happening on BPX and the worldwide community events in which she’s been involved, and I’m looking forward to catching up with her and seeing more of BPX in action when I attend SAPPHIRE in May.

There was some good Q&A at the end about process modeling and the BPX community. Definitely worth watching the replay, which should be available online at the original webinar link above.

2008 02 28 BPM
BPMN Comments (2)

IIR BPM: Me and the role of standards in BPM

I’m up now, and here’s what I’ll be presenting:

| View | Upload your own

I know, it’s long, but I’ll breeze past a number of the slides that I put in there just for reference. If this isn’t enough on standards for you, I highly recommend Michael zur Muehlen’s BPM standards tutorial, both the slides and the audio. I liked it so much, I stole a couple of his slides, although he’ll probably sit in on my session to keep me honest.

2007 11 13 IIR BPM Comments (0)

IIR BPM: Facilitated session on standards

Alec Sharp led a facilitated session on standards that we love, hate, or wish were there (or don’t care about). This is a bit similar to the BPM Think Tank roundtables, but we’re at about six small tables so had a chance for some mini-break-out sessions to discuss ideas, then gather them together.

The notes that came out of this:

One group had some general comments about standards, stating that a common language can simplify, but that the alphabet soup of standards is too complicated and IT driven.
Another group hates BPMN because they feel that a 200-page specification isn’t understandable by business users, and that BPMN is really for specifying automated process execution but is not for business consumption. It’s stifling and constrains what can be modelled.
Standards aren’t written in plain English. There are two sets of standards: methodology standards and tool standards, and we often confuse the two. Once is focussed on human-driven processes, and the other on technology-driven processes. A great analogy: the people coming up with the tools have never baked the cake, or even eaten one.
Standards are often misunderstood, both in terms of who they’re for and what they’re for: they’re misinterpreted by marketing types. [I see this a lot with BPEL having become a standard "check box" on BPM RFPs rather than a real requirement.]
Standards can seem inflexible.
Interchange standards are either insufficient or improperly used by the tools, making it near-impossible to do round-tripping between different tools. They’re intended to use for translation between business and technology domains, but notational standards are possibly becoming less understandable because they are targetted at flowing into interchange standards. [I'm not sure that I agree with this: IT may require that business model in specific forms rather than just allow business to use BPMN in the way that they best fits the organization.]
Standards should be discovered, not invented [Vint Cerf, via Michael zur Muehlen], and BPM standards have been mostly invented.
In defense of standards, one person noted that the form of a sonnet is one of the most constrained/standardized forms of writing, but that Shakespeare wrote some of his most beautiful works as sonnets.
I got in a few comments about the importance of interchange standards, and how round-tripping is one of the primary problems with these standards — or rather their implementation within the BPA and BPM tools.
There’s an issue with the priority when adopting standards: is it to empower the business users, or to support IT implementation? If the former, then it will likely work out, but if it’s for the latter, then the business is not going to totally buy in to the standards.
The relationship with the business has changed: it used to be treated as a black box, but now has to be more integrated with IT, which means that they have to bite the bullet and start using some of these standards rather than abdicate responsibility for process modelling.

I don’t necessarily agree with all of these points, since this turned into mostly a standards-bashing session, but it was an interesting debate.

2007 11 13 BPMN
IIR BPM Comments (4)

Updated BPM standards tutorial

Michael zur Muehlen sent me a link to the updated version of his standards tutorial, and to the audio recording provided by the BPM conference organizers in Brisbane. Enjoy!

2007 10 29 Comments (0)

BPM standards tutorial slides

Michael zur Muehlen, who I met at the BPM Think Tank in August, gave a tutorial on standards at the recent BPM conference in Brisbane, Australia. He noticed that I’m giving a presentation on standards at the upcoming Shared Insights/IIR BPM conference in San Diego next month, and invited me to check out his slides on Slideshare:

Considering that I have to submit my slides this week, these could really come in handy to help fine-tune my thoughts.

2007 10 01 Comments (1)

Info on XPDL 2.1

I received an email last week from Nathaniel Palmer of WfMC on the upcoming XPDL 2.1 specification:

We are now in the process of developing the specification for XPDL 2.1 with the final list of changes to be completed by the next WfMC meeting on October 11-12, 2007.

It is expected that XPDL 2.1 will incorporate changes coming out of XPDL 2.0 as well as those required for BPMN 1.1 compatibility. In addition, however, we are soliciting further input, particularly from those with experience working with XPDL 2.0 or earlier.

Interested parties are asked to please respond directly to XPDL Working Group Chair Robert Shapiro with one or both of the following:

1) Proposed Changes for XPDL 2.1 Specification - please be as specific as possible providing details about what to change in the existing specification;

2) Volunteer to Help Re-Write the Spec and Update the Schema - please
be willing commit two or more days over the next three months to assist in this endeavor.

Please contact Robert Shapiro directly via email at robert.shapiro@global360.com

The time for the release of XPDL 2.1 is as follow:

October 12 - Finalize List of Proposed Changes
November 15 - Finalize Details for Identified Changes in BPMN 1.1
December 15 - Draft Specification for Internal Review
January 15 - Updated Specification For Public Review
February 20 - Vote on Adoption of Final XPDL 2.1 Specification

XPDL will continue to be an important standard for the serialization of business processes (i.e., the file format that you use to save it, once you’ve modelled it in BPMN) for some years to come, and it still remains to be seen what impact that the new BPDM format will have on the use of XPDL.

2007 10 01 XPDL Comments (0)

BPM Think Tank Day 2: BPEL Roundtable

The second roundtable that I attended on last Tuesday’s sessions was on BPEL, headed up by Ismael Ghalimi. It was great to finally meet Ismael in person: we’ve been corresponding by email and blog comments for quite a while, and have even done a webinar together, but this is the first time that we’ve been in the same place at the same time.

We started with a discussion of BPEL4People, and how it’s changed from the original specification (which proposed implementing human-facing tasks as web services rather than changing BPEL) to the current specification (which proposes extensions to BPEL for human-facing tasks).

The title of the roundtable was “is BPEL relevant”, and we covered several aspects of that. First, a few people around the table (which included a few vendors with a vested interest in BPEL) stated that BPEL is relevant in the same way that SQL is relevant: as a standardized language that allows a separation of the design/development environment from the execution environment. Based on the lively discussion, some of these guys have spent a lot of time thinking about the BPEL-SQL analogy. My argument (I have no vested interest, so could have easily argued the opposite way) was that maybe it *should* be relevant in that way, but really isn’t in the consolidated model-design-execute environments that we see in BPM today. The real question may be, at what level is BPEL relevant: model, design, code or execution? Everyone agreed that it’s not relevant to business users or analysts, but it’s not clear where the line of relevance lies.

We also discussed how native BPEL execution providing code monitoring during execution, such that any code faults will have more semantic information included without having to build a monitoring stack on top of it. What remains to be seen is if BPEL4People will provide some level of business-relevant monitoring, or if that still has to be built on top of the execution layer.

What we’re seeing is that for the most part, it’s the larger vendors that are adopting BPEL — possibly as a common language to glue together all the BPM pieces that they’re acquiring – whereas the smaller vendors provided a consolidated (and therefore closed) suite environment where the execution language doesn’t matter, and in fact, their engine may be a competitive differentiator.

2007 08 02 BPEL
BPMThinkTank Comments (3)

More on the Metastorm-Proforma acquisition

Metastorm CEO Bob Farrell gave a briefing this morning about their acquisition of Proforma; not much that wasn’t covered in the press release except the following:

Their customers were demanding BPA functionality that obviously went beyond what they offered as part of their BPMS.
They’ll be using Proforma’s CIF as an interchange format — a major mistake for process models in my opinion. Although CIF does provide support for a number of other enterprise architecture model types, they’re really going to be using this for getting process models into the Metastorm BPMS execution environment. In a post that I did at the end of the Proforma user conference last year, I noted that in spite of their lip service to standards, they only support BPEL export via a CIF remapping, XPDL wasn’t on their roadmap yet, and I’m not sure that they had started to think about BPDM. Of course, if they abandon the hope of selling ProVision to users of other BPMS’, then this may not matter much since it will just be an internal interchange standard between their own tools.

2007 08 01 BPA
BPM Comments (0)

BPM Think Tank Day 2: BPMN/BPDM Roundtable

I’m just getting to the last of the BPM Think Tank sessions, namely, the roundtables and one lunch session that I had documented on paper. The three sessions of roundtables spanned Tuesday and Wednesday afternoons, and were some of the best conversations that I had at the conference. I’ll cover each of the ones that I attended in a separate post, then the summaries of the others in another post, just to keep things from getting too long. These were fairly unstructured, general sessions so the notes might be a bit fragmented

The first roundtable that I attended was BPMN and BPDM, with Stephen White of IBM and Antoine Lonjon of MEGA.

There are insufficient books and tools for educating the community on how to use BPMN for different purposes. There is a requirement for a reference document to educate end-user organizations that is smaller and more understandable than the specification (possibly both a business-oriented primer and a technical reference). Stephen stated that additional reference documents will be available within a few months. There is an HTML version of the specification online at ModelDriven.org.

Small consulting organizations and independents can’t realistically get involved in standards creation so we’re always “users” of the specification. I didn’t raise this point, but do agree with it — paying my own travel expenses and missing out on days of revenue to attend standards meetings several times each year is just not in my budget.

BPM vendors are unlikely to replace their own internal model formats with BPDM, but will translate to/from BPDM. Vendors need to review and understand BPDM and how it maps between different representations. There is a need for BPMN/BPDM conformance testing and certification of BPA/BPM products.

BPDM gives BPMN credibility as a modelling format since the specification is now “complete”. There was a great deal of discussion, both in this session and at other times during the think tank where this same point was raised, namely, that BPMN was rushed out without a serialization format, and that may have been a short-term mistake. One person at the table was concerned that combining BPMN and BPDM, and thereby increasing complexity, may be a mistake.

A comment that Phil Gilbert made on my TIBCO webinar Q&A post made a valid point about how there’s two main use cases for BPMN: non-executable process mapping and analysis by business analysts, and “visual coding” to create an executable process. We discussed this a bit at the roundtable, particularly around how business analysts could use the basic shapes (i.e., skip some of the internal graphic symbols that distinguish between different flavours of the shapes) and hence might benefit from a much simpler training program to get started. There was some discussion about how far up the chain that BPMN will or can be used for modelling businesses, e.g., whether it can be extended to strategy and goals or whether that’s more the mandate of BMM (Business Motivational Metamodel)

I had an interesting side conversation with Antoine after the roundtable ended about adoption patterns for BPMN and BPDM. Although standards organizations tend to have the “if you build it, they will come” attitude towards standards adoption, I believe that there needs to be some good reasons put forward for why BPDM provides benefits to the end customer and for the BPM vendors before we can expect to see widespread adoption.

2007 07 30 BPMN
BPMThinkTank Comments (0)

BPM Think Tank Day 2: John Alden

Replacing the scheduled Bill Curtis (who had to cancel due to a family emergency), Chief Process Officer at McAfee, John Alden of Capability Measurement (which he co-founded with Curtis) gave the second day keynote on the role of the Chief Process Officer in business process improvement.

Responsibilities of the CPO:

Champion enterprise process discipline: quantify the need, articulate the vision, and infiltrate the mindset. It’s important for the CPO to be an internal evangelist for process improvement. Low process maturity organizations are spending 30-40% of their total time doing rework due to errors earlier in the process. In mid-maturity organizations, processes are stabilized but not standardized. In mature organizations, processes are standardized to reduce variability.
Drive process measurement: quantify business cases, support local management needs first, and mature the measures with the process over time. Derive the measurements, or KPIs, from strategic goals. Measures in immature organizations are unreliable, inconsistent and inaccurate; in mid-level maturity organizations, they become more standardized; and in mature organizations, they become strategic.
Coordinate enterprise process integration: represent cross-functional interests, establish enterprise process capability, and coordinate enterprise improvement projects. This requires optimizing the workflow rather than the functional performance of any given group, that is, focussing on the end-to-end process rather than silos: moving from siloed improvements, to coordinating functions through cross-functional processes, to enterprise processes that draw on functions as roles. There needs to be some sort of enterprise infrastructure to support these efforts, possibly through a centre of excellence.
Develop local process improvement capabilities: build business unit BPI capability, support local BPI activities, and establish enterprise improvement assets.

Alden talked a bit about BPMM, and how it needs to start at the local level and have the right type of leadership from the local managers, and finished up with a brief look at the CPO function and the related process improvement structures that are in place at McAfee.

I would have love to hear Curtis talk about this himself, since I’m sure that he’d bring more passion and hands-on knowledge about his role at McAfee to it, but Alden is very knowledgeable in this area and was a reasonable substitute.

2007 07 24 BPMM
BPMThinkTank Comments (0)

BPM Think Tank Day 1: BPM Standards Panel

The final session of the day was a panel with representatives from four standards organizations: Fred Cummins of OMG (BPMN, BPDM), Charlton Barreto of W3C, Keith Swenson of WfMC (XPDL) and John Evdemon of OASIS (BPEL), moderated by Fred Waskiewicz of OMG.

The first question was on the focus or mission of each organization:

OMG has a focus on modelling business processes by business people through specifications such as BPMN and BPDM.
The W3C’s focus is on “keeping the web from fragmenting”, which seems a somewhat lofty goal. Relative to BPM, it’s about providing a testable architecture.
WfMC’s mission is to help the process design ecosystem work together better by providing process-specific standards such as XPDL. XPDL stills reigns as the de facto interchange standard for process models, with over 60 different systems and open source projects supporting it, and I can’t imagine that WfMC is going to back away from that for quite a while.
OASIS is involved in both orchestration, through BPEL, and choreography, through BPSS. Evdemon acknowledged some of the shortcomings with BPEL, such as the lack of support for human-facing tasks, looping and subprocesses, and discussed how they are addressing those with upcoming extensions.

So far, so polite. Everyone seems to be acknowledging everyone else’s position, and it seems like one big happy standards family. The question is, of course, is there room in the landscape for all of these? If so, how do they fit together? Is there One Language To Rule Them All?

Barroto called for more workshops to bring together the standards bodies to work out the issues of overlap and compatibility, and Evdemon agreed; I understood that that was part of the reason for the BPM Think Tanks in the first place, but they seem to be suggesting something different, like a technical skunkworks of some sort where the engineers just get together and hack it out. Since they come from the two organizations that produce much more technical standards, that’s not a surprising view, but I’m not sure that it is sufficiently sensitive to the nature of all of the types of people (including business people) who might need to be involved in the development of BPM standards.

Great question from Phil Larson of Appian: since BPMN is the only thing that everyone can agree on, why is OMG messing things up by including BPDM into BPMN, when there is still an active competition (on some level) between BPDM, XPDL and BPEL (when it’s used as an interchange standard rather than an execution language)? Phil Gilbert responded that BPMN wasn’t right in the first place since it was missing the representation part, and the inclusion of BPDM fixes that somehow. I’m not sure that answers Larson’s question, and he came back to ask if WfMC and OASIS see BPDM as a threat, and if not, why not? Swenson reinforced the big happy standards family idea that all of these can exist together, but mentioned something about migrating from XPDL to BPDM; Evdemon also said that if something better than BPEL comes along, then you should be looking at it. To me, it sounds like both WfMC and OASIS are in a wait-and-see mode to see what BPDM will turn out to be in reality, and both seem to be making noises about how if a superior standard emerges that handles all the use cases, then it would make sense to consider moving in that direction. As if they could say anything else.

That’s it for day 1. We’re all headed for the bar to see which vendors buys the first round.

2007 07 23 BPMThinkTank Comments (3)

BPM Think Tank Day 1: Modeling Notations/Metamodels

For the next two sessions, we’ve split into two tracks, business and technical, and I’m in the technical track where Stephen White of IBM (the “father of BPMN”) is talking about modeling notations and metamodels, namely, BPMN, BPDM and UML.

White started out by listing all of the process-related standards both within OMG, and those external to OMG, such as BPEL, XDL, ebXML BPSS (ebBP) and WS-CDL. I’m starting to think that they missed a great opportunity at lunch with the vegetable soup: a few letter-shaped noodles and we would have had alphabet soup for lunch as well as the dose of it that we’re having now.

He then focussed specifically on the three key process standards within OMG: UML, BPMN and BPDM.

UML’s been around quite a while; I know it primarily as a way to model software development concepts, and have never been happy with the attempts to shoehorn it into business analyst usages since it is difficult to explain the visual syntax of some UML diagrams to business users when they need to review them. UML activity models were added as a variation of state diagrams, and were beefed up with some business semantics to allow for use by business analysis to model business processes, but they’re not as functional as BPMN diagrams for business process models and have pretty much been replaced in that area by BPMN; I expect that they’re used mostly for modelling flows within software (by developers) than for business processes these days.

BPMI first developed BPML (an XML process execution language) which was later replaced by BPEL, and realized that a graphical notation standard was required, leading to the development of BPMN. BPMN was developed to be usable by the business community, and to be able to generate executable processes (through mapping to a language such as BPEL) by providing not just graphical elements, but the attributes for those elements. BPMN is intended to be methodology-agnostic, and to allow a business analyst to model a process in as simple or as complex an amount of detail that they deem suitable for the application.

White covered the basics of BPMN: the four core elements of activities, events, gateways and connectors represented as shapes, then variations on each of those such as the border type and thickness of an event to indicate if it is a start, intermediate or end event. I covered some of this in my recent webinar on business process modelling, or there’s tons of more detailed BPMN references around the web including Bruce Silver’s BPMN course.

This is turning into a bit too much of a BPMN primer, but I’m hanging on for the BPDM part. Also, I’m in the middle of the second row and can’t exactly sneak out unnoticed.

There seems to be a huge point of confusion with some of the audience members over pools and lanes in the swimlane elements of BPMN, and when to use a pool versus a lane; this seems like one of the most obvious things in the standard, so I’m not sure why this is a problem. Pools, in general, represent separate spheres of control; a business process starts, ends and has all of its elements within a single pool. Pools are often used to represent separate organizations in a B2B process representation. Lanes are sub-partitions of pools, usually used to indicate an organizational role or department, or even specific systems that participate in the process in some way; elements of a business process will be in different lanes of the same pools to indicate where (or by whom) that element is executed. Only message flows pass between elements in different pools, which implies a level of asynchronicity; whereas sequence flows are used to connect activities, gateways and events within the same pool, whether in the same lane or not.

BPMN 1.1 was just completed, with a few notational changes:

Signal, a new event type, denoted by a black triangle within the event circle shape. A signal is used to broadcast a specific state to other processes outside the immediate scope.
Reduction in scope for link events, because of the inclusion of the signal event; these are now basically goto events within a process.
Visual distinction between events that throw and catch, indicated by whether the internal icon is filled or an outline.
Rule event is now called “conditional”.
Icon for multiple events is a pentagon rather than a 6-pointed star.

Nine minutes after the session was supposed to end, we finally start on BPDM, so I think that this is going to be quick. I’m starting to understand by standards are never released on schedule…

BPDM was started in 2003 as a metamodel of business processes, initially without a notation and later aligned with BPMN. It’s intended to support the specification of multi-party choreography (think of message flows between pools) as well as process orchestration: basically, orchestration is what goes on inside a pool, that is, internal business processes; choreography is what happens between pools, that is, B2B interactions. BPMN 2.0, which will include BPDM, will update how choreography processes are modelled.

BPDM, as the metamodel, defines the meaning of the notation and provides the standardized structure behind it that allows for translation between different modelling languages. In BPMN 2.0, the meaning of BPMN will be changed to Business Process Model and Notation to indicate the inclusion of the BPDM metamodel into BPMN 2.0.

2007 07 23 BPMN
BPMThinkTank Comments (0)

BPM Think Tank Day 1: Derek Miers

Derek Miers started the afternoon with an overview of OMG’s BPM standards.

Adopted specifications

BPM (Business Motivation Metamodel)
BPMN (Business Process Modeling Notation)
BPDM (Business Process Definition Metamodel)
SBVR (Semantics of Business Vocabulary & Rules)
BPMM (Business Process Maturity Model)

Specifications in progress:

OSM (Organizational Structure Metamodel)
BPRI (Business Process Runtime Interfaces)
BPMN 2.0 (Merged notation and metamodel)
PRR (Production Rules Representation)

BPMM is concerned with the evolutionary improvement path that organizations take from immature, inconsistent processes to a more mature set of business processes, and is targetted for use by the business side within organizations.

BMM is an integrated approach for deciding, documenting, communicating and managing key elements in business design, intended for use by business managers.

SVBR is more of a vendor-focussed standard for business rules: like other serialization and interchange standards, this is something that is built into products but isn’t much seen by business managers/analysts.

BPDM is an interchange format for moving between process model types: a metamodel that allows, for example, XPDL to be translated to BPDM and on to BPEL. Interesting to note that OMG puts XPDL in the same layer as BPEL, WS-CDL and ebBP, that is, execution models, with BPMN and BPDM being up in the business models layer. I’m not sure how much of this representation is political in nature, to allow BPEL and XPDL to be included in a BPDM world; since BPDM does serialization for the purposes of interchange, XPDL would only be used for interfacing with systems that don’t support BPDM, and BPEL would be used only when it was required as an execution language. This is a technical standard: business analysts won’t really care except that it provides them with interchange between tools as required.

BPMN we all pretty much know about: a graphical process notation standard, used by business analysts and others who need to create or understand process models. Version 1.1 will be released within the next few weeks, and 2.0 (which rolls in BPDM to provide notation, metamodel and interchange in a single standard) is targetted for the end of 2008.

OSM is a standard for modelling (essentially) the organizational chart: organizational units, position, authority, responsibility, relationships, contact information, organization rules, and matrix structures. A current de facto standard that covers part of this is LDAP, for example. OSM is targetted at business managers, but will need adoption by the modelling tools and BPMS vendors. There was a decision made to separate the process (BPMN/BPDM) and resource (OSM) architecture, although they are closely related: OSM will tie into BPMN concepts such as swimlanes.

BPRI is a standard providing an interface to process execution artifacts in order to extract information for monitoring and analysis. I think that this is a prime target for RSS feeds as a standard way of extracting runtime data from executing systems; that would at least provide a standard transport, leaving still the development of the standard for the payload. Derek indicated that this is one working group that is having trouble getting participation and traction in the industry, so if you’re interested in participating in this (or in any of the other OMG BPM standards), contact OMG.

On his summary slide, he has one line that says “Don’t leave it to the vendors to control your destiny”, yet the room is full of vendors with a sprinkling of independent like Bruce, Brenda and I, and I’m not sure that the end-user organizations that this is obviously targetted at are even in attendance.

OMG specification documents are freely available to the public, although I’ve always found it difficult to find them on their website. Apparently there’s a link from the OMG home page to the specifications catalog, and all of the specifications are linked from there.

Tagged OMG

2007 07 23 BPMThinkTank Comments (2)

BPM Think Tank Day 1: Phil Gilbert on OMG & BPM

Phil Gilbert was up next for a brief talk on the role of OMG’s BPM steering committee, which he chairs, as a lead-in to the more detailed discussions of OMG’s BPM standards to come.

He discussed how the steering committee started as BPMI.org in 2001, which released the first BPMN specification prior to BPMI being merged into OMG in 2005. The steering committee provides a platform around which input to standards can be gathered — specifically BPMN, BPDM and SBVR — but doesn’t actually vote on passing the standards. Ever since I was involved in satellite image standards back in the 80’s, I’ve never really understood how standards bodies work in their entirety, but am thankful for people like Phil who get in there and do the heavy lifting.

He covered their roadmap:

BPMN 1.1 (available now)
BPDM 1.0 (just released)
Merging BPMN and BPDM into BPMN 2.0, so that if you support fully support BPMN, you will support BPDM as well
Working on the relationships between the OMG standards and UML, XPDL and BPEL
OSM 1.0 for organization modeling (later this year)
SBVR 1.0 for rules
BPRI 1.0 for the runtime interface to processes

He finished with a great point: as more of these standards become baked into process-related products, the idea that you have to work with a single vendor — much less a single product — will become obsolete.

2007 07 23 BPMThinkTank Comments (0)

BPM Think Tank Day 1: Jim Adamczyk

The second keynote of the day was Jim Adamczyk of Accenture on how standards play a critical role in creating value with BPM. He said that they have about 40 current projects that are focussed on BPM — the discipline of creating process-centric business and IT architectures — in addition to those doing “low-level workflow”, although it’s not completely clear where the distinction lies. They’re early enough with all of these projects that he couldn’t even list client names, which means to me that Accenture is a bit late to the game here.

He moved on to talk about the value of standards, both notational and serialization, covering much the same territory as I did in a webinar recently: notational standards like BPMN allows users to move between different modelling tools more easily, and serialization/interchange standards make is easier to move processes from one system to another.

He made some great points about how changes are specified: the tendency is for business to actually specify the system change (e.g., add this function to this screen) rather than focus on their business process and KPIs — I struggle with this constantly with my customers, and have to constantly remind the business side to state their requirements, not try to design the system. The problem is that IT has been letting them do this for years, either because it’s easier to not have to learn enough about the business to do the specifications and design based on actual requirements, or because it effectively passes the buck for any mismatch between requirements (what the business needs) and specifications (what the system does) to the business side. But I digress.

Adamczyk stated that a client’s need for standards depend on their entry point to BPM, although I’m not clear what he meant by this. He said that IT almost always drives standards and that business rarely wants to implement standards; I completely disagree with this in the case of BPMN, since there are significant tangible benefits to the business side from having everyone use the same modelling notation, and I have few business-side clients who don’t recognize this. I agree that the business side doesn’t explicitly care about XPDL or BPDM or BPEL or whatever is being used for serialization, but they will start caring if it means that they can’t do round-tripping between the modelling and execution environments. However, he’s deep in the weeds talking about WSDL and LU6.2, so I think that he and I have different views of BPM standards. Since he went on to talk about how Oracle Fusion is one of the most commonly used BPM platforms amongst their client base, I think that we have different views of BPM, too.

Then he made the comment that if you use of the BPM suites (like Lombardi or Appian) that you probably don’t care about BPM standards, which couldn’t be further from the truth. Many companies use a separate process modelling tool even though they use a BPMS, so both notational standards and interchange standards are critical. They’re even important between tools from the same vendor, such as Lombardi’s Blueprint process discovery tool and their TeamWorks BPM suite, which uses BPDM for process model interchange. And there’s the advantage hiring a new analyst who already knows BPMN, even if they don’t know the particular BPMS that you’re using, because that particular standard has become so widespread, and the reduced training requirements that result.

He does have a future view for the perfect world enabled by standards that includes federated orchestration, consistent policy and governance, dynamic and predictive infrastructure, and consistent methodology/training/tools; ranging from consistency on one platform to coverage of all platforms.

Although an engaging speaker, Adamczyk seemed to spend a lot of time apologizing for things that might be missing or inaccurate in his presentation: according to him, he doesn’t really know a lot about BPM standards, nor about the utilities vertical (the industry of his unnamed client example). He also said that he’s here as a proxy for CIOs (this is billed as a “CIO keynote”) rather than as an actual CIO. Enough, already: tell us what you do know, not what you don’t know.

2007 07 23 BPMThinkTank Comments (0)

BPM Think Tank Day 1: Paul Harmon

Phil Gilbert kicked off morning with welcome and logistics before turning it over to Paul Harmon, who gave a keynote entitled “Does the OMG have any business getting involved in business process management?” I love a little controversy first thing in the morning.

He started out with a fairly standard view of the history of BPM and process improvement, from Rummler-Brache and TQM in the 80’s to BPR in the 90’s to BPM in the 00’s. He pointed out that BPM has become a somewhat meaningless term, since it means process improvement, the software used to automate processes, a management philosophy of organizing businesses around their processes (the most recent Gartner viewpoint) and a variety of other things.

He broke down BPM into enterprise level, process level and implementation level concerns (with a nice pyramid graphic), and gave some examples of each. For example, at the enterprise level, we have frameworks such as SCOR (for supply chain) and high-level organizational issues such as the Business Process Maturity Model (BPMM); Harmon questions whether OMG should be involved at this level since its primary focus is on technology standards. Process-level concerns are more about modelling, documenting and improving processes, and spreading that process culture throughout the organization. Implementation-level concerns includes the automation of processes, including execution and monitoring, plus the training required to support these new processes.

He made an interesting distinction between stable processes,which need to be efficient and productive, and dynamic processes, which need to be flexible. Processes that are newer or need to be changed frequently are in the dynamic range; in my opinion, these tend to be the processes that are competitive differentiators for an organization. IBM has recently thrown the concept of “value nets” into the mix as an alternative to value chains, but Harmon feels that both are valid concepts: possibly using value chains for stable processes, which might even be candidates for outsourcing, and value nets for more dynamic processes.

He also made a distinction between process improvement, process redesign and process reengineering, a division that I find a bit false since it’s more of a spectrum than he shows.

There was an interesting bit on model-driven architecture (MDA) and how it moves from platform-independent models (in BPMN) to platform-specific models (also in BPMN) to implementation (e.g., J2EE); for example, there may be parts of a process modelled at the platform-independent level that are never automated, hence aren’t directly mapped to the platform-specific level.

He put forward the idea that process is where business mangers and IT meet, and that different organizations may have the implementation level being driven by either the business side or the IT side, and that there’s often poor coordination at this level.

He then discussed BPMS and came up with yet another taxonomy: integration-centric, employee-centric, document-centric, decision-centric and monitoring-centric. Do we need another way to categorize BPMS? Are these divisions all that meaningful, since the vendors all keep jostling for space in the segment that they think that the analysts are presenting as most critical? More importantly, Harmon sees that also the BPM suites vendors (those that combined process execution/automation with modelling, BAM, rules and all the other shiny things) are leading the market now, the platform vendors (IBM, Microsoft, etc.) will grow to dominate the market in years to come. I’m not sure that I agree with that unless those platform vendors seriously improve their offerings, which are currently disjointed and much less functional than the BPM suites.

Harmon’s slides will be available under OMG-BPM on the BPTrends site. There’s definitely some good stuff in here, particularly in the standards and practices that fit into each level of the pyramid.

Good thing that I’m blogging offline in Windows Live Writer, since the T-mobile connectivity keeps dropping, and isn’t smart enough to keep a cookie to stay logged in, but requires a new login each time that its crappy service cuts out. Posting may come in chunks since it will likely require me to dash out to the lobby to get a decent signal.

2007 07 23 BPM
BPMM
BPMThinkTank Comments (0)

Column 2 by Sandy Kemsley