Also not sure why the US DoD’s enterprise architecture standard is impacting what is supposed to be an international standard

I want to give some background on the DoDAF conformance class, and how it came about, since I wrote most of the DoD document (the initial release is available here, if you are interested in a more recent version please email me).

Background

Large-scale system descriptions for government projects have to be delivered in views the follow either the DoD Architecture Framework or the Federal Enterprise Architecture Framework (FEAF).  The DoD Architecture Framework (DoDAF) in its original form didn’t even contain a view for modeling processes, because it was closely designed with UML views in mind. Recently people have taken to using the Event-Trace-Description view (called OV-6c technically) and populated it with process models. Process modeling is increasingly important in the government space, but there is a large variety of approaches that people employ, and frameworks like DoDAF are not prescriptive in terms of how their individual views should be populated, i.e. which methods people should use. That leads to the situation that people use IDEF, BPMN, FlowCharts, and all claim to be DoDAF-compliant.

The Primitives Project

In May 2008 a project was launched by the CTO and Chief Architect of the Business Mission Area to address three points

1. How can the DoD enforce a consistent representation of architecture descriptions (i.e. how can we ensure the diagrams created by different modelers will look similar)
2. How can the DoD leverage existing standards for architecture descriptions (i.e. we didn’t want to invent a new notation)
3. How can the DoD enforce that the resulting models are interchangeable between platforms (i.e. how do we create process model portability)

Pretty much from the get-go we determined that BPMN was the graphical standard for process modeling that the DoD would settle on. It was already in use in different projects, there is a broad base of tool-support, and an increasing knowledge base of modelers that are conversant in BPMN. Moreover, BPMN provides excellent support for cross-organizational process modeling and the handling of events, making it preferable to using IDEF0 or UML Activity Diagrams.

Not all BPMN models are created equal

Even if modelers all use the same notation (BPMN), there are different ways to express the same semantics. One particular example is the conditional sequence flow element in BPMN – you can model a split using an exclusive or inclusive OR gateway, or you can express the same semantics using conditional sequence flow elements. The example below shows two process fragments that are semantically equivalent, but the casual reader would have to read the transition conditions for the conditional sequence flow example on the right to determine whether this is an exclusive or inclusive OR split. The gateway on the left signals this semantic through the use of the X symbol.

Implicit and Explicit Gateways in BPMN

In previous research Jan Recker and I had looked at the uptake of BPMN in practice, and found that there were some language elements that were rarely used in the models we analyzed. Thus we started to tailor the set of BPMN constructs that we thought were sufficient to model processes at the requirements engineering level (the DoDAF OV-6c), and the systems engineering level (the DoDAF SvcV-10c and SV-10c). This led us to a first cut of “BPMN primitives”, but we needed to validate it. So we used the BPMN subset in the documentation of various processes within the Department of Defense, from the Business side (hiring people, paying suppliers, managing property etc.) to the Warfighter side (performing close air support missions). We also sent the specification to a number of individuals outside the DoD that provided feedback, and we presented it to a number of BPM vendors for their input.

BPMN meets patterns

It quickly became clear that if you want to ensure consistent modeling practices you need more than just a restricted set of the BPMN syntax – you need to provide guidance on how to apply the modeling elements in practice. Thankfully, Artur ter Hofstede and Wil van der Aalst provided a great foundation for this in form of their workflow patterns work. We adopted as many of these patterns as we thought feasible, and they became a mandatory part of the BPMN primitives specification. But beyond the elementary patterns (e.g., how do I model a process split?) we found that there were recurring situations with specific semantics – reviewing and approving a document, collaboration between two parties, voting on an issue etc. These were captured in a high-level pattern catalog that is meant to be extensible, work that is currently ongoing.

Beyond Modeling – Model Execution and Exchange

The final question we are after relates to the exchange of models between platforms (e.g. to take a model from an architecture tool to an execution platform). It is clear that not every vendor will support the full set of BPMN 2.0 constructs. The most frequent explanation from execution-level vendors (i.e. BPMS vendors) is that they don’t want you to model what they can’t execute. So if an execution engine cannot interpret a non-aborting attached timer event then its development environment will most likely not contain that symbol. But that doesn’t mean we are not pushing the vendors to extend their systems in this direction, and since the US federal government is a rather significant technology buyer having the BPMN primitives as a guide in terms of what BPMN support is expected should provide clarity for vendors that are working on their development roadmaps.

BPMN Primitives and the BPMN 2.0 Standardization Effort

A vendor that currently supports just a subset of BPMN has little guidance which elements should be supported in the future – in BPMN 1.0 through 1.2 there was just a core set and the full set of the language, and a big gap in the middle. In BPMN 2.0 there will be more milestones that a vendor can target: Simple, Descriptive, DoDAF and Full. There still is a big gap between the Descriptive and the Full subclasses, and there was debate within the OMG and with interested parties on the outside how a suitable subclass could be introduced between Descriptive and Full. That’s where the DoDAF BPMN Subset (i.e. the primitives) comes in – it is a user-driven, practically validated subset of BPMN that ensures a high level of expressiveness, while leaving out many of the constructs that can either lead to inconsistent representations for the same semantics or that are so technical that the vast majority of IS and systems engineers will not miss them. It is a yardstick for vendors that may still have gaps in their own coverage of BPMN constructs and it gives members of the training community a target set for higher-level BPMN certifications.

So there you have it – history and rationale for the DoDAF subclass in the draft BPMN 2.0 spec. Whether the DoDAF name is a wise choice for the standard spec I don’t know, Sandy certainly raises a valid question. But in terms of content I am very confident that its applicability goes way beyond the confines of the Pentagon.

Our previous post on the frequency of BPMN construct usage has generated a passionate response by Bruce Silver who we know and respect as a very active contributor not only to BPM blogging in general but also to BPMN education and application specifically. Bruce makes many good points in his post and raises a number of interesting challenges. However, on some accounts we disagree with a number of the inferences he draws, so we want to clarify some aspects of our original post.

First of all, the paper and post are the result of a joint research effort between Jan Recker (QUT Brisbane) and myself (Stevens Institute of Technology), which we have stated. Jan and I started working together due to the complementary nature of our interests – standards in BPM (myself) and practical usage of modeling methods (Jan). Our study has been motivated by the fact that we know so very little about how standards such as BPMN are actually used – as opposed to what vendors, consultants and trainers think how they should be (or might be) used. – and this is what we try to explore and understand. The post and the related study are but one snapshot of our combined research. Agree with our results or not, but please give credit where credit is due. Jan is one of the most prolific researchers on BPMN; and it would be unfair to ignore his substantial contribution to this research.

We have outlined our research method in great detail in the full version of the BPMN paper, the PDF of which has been linked to from the original post. If you missed it, click here. Of course, we could have written a great deal more about the mode of analysis, but let’s be frank: how many blog readers would want to see this information in the post? (let us know if you do!) And for those of you taking an interest in research methods – both Jan and myself are more than happy to discuss the ways in which academic research is conducted. More than welcome.

We started with a simple question: BPMN is divided into a core and an extended set of constructs – does this separation hold in practice, or are there other common subsets (dialects or creoles) that can be found in practice? If there is such a common subset, we would expect a sizable number of models to share it. We found no evidence of a larger common core. Only 6 model pairs out of the 126 models used similar BPMN subsets (i.e. there were 6 subsets shared by 2 models).

We looked at the similarity among all subsets by coding the occurrence of symbols as a 50-bit string and computing the pairwise Hamming distance. On average 7 symbols differed between the BPMN subsets, and since the average model used only 9 symbols that makes the true common core very very small.

We performed a hierarchical cluster analysis on the models, trying to find the constructs that were used in groups. Indeed, several well-defined clusters emerged from this analysis: Basic Modeling Constructs, Annotations and Explanations (which include the blank XOR Gateway – not something we expected), Organization Modeling Constructs, and Control Flow Refinements. Users that move beyond these clusters seem to add individual constructs as needed, but in a rather random fashion.

Whether the 126 models we gathered are representative to all BPMN uses is a good question. Of course, we don’t claim this to be the case and we are in fact expanding our collection of models (hey Bruce, want to send us some of your seminar models?). However, so far our results have proven stable. We spend a great deal of our time with organizations using BPMN and we can assure you upfront – this is indeed indicative of how people use BPMN.

Bruce likens a frequency count of BPMN symbols to a character count in a document. We disagree – BPMN symbols are more like words, since they have semantics and are governed by formation rules. There are no formation rules at the character level in most languages. One could liken the frequency count to the frequency with which words in the English language are used – and that provides a much more useful metric than a character count. Linguists talk about the difference between an active and a passive vocabulary – words that we use versus words that we understand. It is possible that the use of BPMN is emerging along the same lines – a modeler might understand many of the symbols, but will frequently restrict him or herself to a more limited subset. To illustrate this: You may understand many entries in Merriam-Webster’s dictionary of the English language, but you do not use them frequently (or at all).

Do the models we collected have errors? Absolutely. Some of them we find useful in modeling courses – to show the types of errors usually made in practice. Our intention was not to analyze perfect BPMN models – we find those in every training course and in tool documentations, etc. The BPM reality looks different. Our intention was to analyze the current practice of BPMN modeling, not the indended application of the language. English speakers abuse their language – I know I do – but that does not mean that their sentences are meaningless.

Turning to some of the conclusions we draw from our research, we would like to clarify some aspects: What we call ‘the real core set of BPMN’ is what our analysis showed to be the most frequently used BPMN symbols found in the models considered. This does not mean we imply this set to be the core set of BPMN to be used by everyone. Rather, this is the minimal set of BPMN constructs actually used in practice so far. Is this set little more than flowcharting? Absolutely true. Absolutely.

But what does that tell us? People, and organizations, use BPMN for purposes similar to those organizations ten, twenty years ago that employed flowcharting – they want to describe their operations in simple, graphical terms. The process modeling efforts in most organizations at this stage are simply not advanced or mature enough to start specifying service-enable workflows with exception behavior in BPMN. No, most people use it simply for flowcharting.

What we conclude from this observation is that the ecosystem of vendors, consultants and trainers should be aware of this and should plan, manage and employ their efforts (be it tool development, BPMN training or modeling workshops) accordingly. We present a number of conjectures based on these observations, some of which appear to be troubling to Bruce. This is worrisome to us, we hope we can clarify this a bit more:

• First, we see a great deal of training programs introducing the full BPMN specification to large number of stakeholders. Our results show, however, that most of this training is in fact only applicable to a small number of BPMN application areas. So we have to ask: Are there any tailored BPMN training programs? What should the ‘BPMN beginner’ course look like and how this body of knowledge then be extended by specialist courses? One of the suggestions we raise is indeed to start with the set of BPMN symbols that in fact are widely used in practice. Why? Because this would allow the BPMN beginner to instantly be able grasp, understand and use the majority of models in practice. Sure, (s)he would not yet be an expert, sure (s)he would not yet have learned about the benefits and expressive power of advanced BPMN. But (s)he can go out and leverage the knowledge instantly and make contributions. Without having to digest the complexity of a full-blown course. We do not imply that business users do not understand the more refined BPMN symbols, we have just found little evidence that they use them frequently.

• Second, we suggest to tool vendors to rely more on empirical information about BPMN use when having to make trade-off decisions in BPMN support. Let’s face it – many BPMS do not support the full set of BPMN constructs. This makes sense, because if the system does not have the capability to execute the semantics of a specific construct (say, a transaction around a set of activities) then if would not make sense to allow a system analyst to draw this symbol. So which constructs can a vendor neglect initially and which need to be supported? We would argue that it is of best interest to vendors to focus on those constructs heavily used in practice. Why? Because this would give them access to the widest share of the market. Simple as that. This does not mean, that our suggestion is of a static nature. Of course not. Over time, full support should be given – and (relating to our previous conclusion) also BPMN users should learn the advanced features of BPMN. But organizations and tool vendors alike often face a need to achieve results very very fast. Which also means that releases are built and deployed that are far from finished.

• Third, we think that our last conclusion was misread. Our intention is not to discredit the sizable development effort that went into the BPMN specification. More than 120 people participated in more than 120 interactions, be they face to face or conference calls. That’s a lot of BPM expertise leading to the current specification. We do not discourage advancement. 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.

We know a great deal about what BPMN can do in theory, how it is implemented in tools, how training programs (like Bruce’s) look like and even how we generate code from the diagrams and how the semantics can be tested and vigorously verified. But what do we know about how organizations engaged in BPM initiatives use it? Very little. Again, we were motivated by exactly this dearth of knowledge about real-life BPMN practice. Why? Because our 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.

We try to feed our empirical research back to the BPMN community – in the form of blogs, practitioner papers, or even directly by knocking on the door of OMG. Whether we are heard, and whether our findings have the type of impact we hoped is a different story. But we are always open for debate.

sig|pam is maintained by the illuminati of academic BPM research, so point your browsers to www.sigpam.org and find out what is going on in the BPM research scene…

I am no stranger to nordic countries. I taught in Estonia for a while and visited Finland a couple of times. And if Germans are known for their efficient ways, well, we can learn a thing or two from the people up north. In the course of my research on standards I came across the dissertation of Vladislav V. Fomin, who wrote on the Process of Standard Making using two case studies from the mobile phone industry. His dissertation is available from his alma mater, the University of Jyväskylä (more properly: Jyväskylän yliopiston kirjasto/Julkaisuyksikkö…). After some prodding and testing I found the link to order the book here. Filled out the form – off we go. But wait: No payment information was requested?!

A couple of days went by and I pretty much forgot the whole thing until an envelope arrived in my mailbox with the requested book inside, and a polite invoice for 10 Euros and 33 cents – the book cost 2 Euros, shipping 8 Euros and 33 cents. “Please instruct your bank to forward payment orders to …” Somewhat different from the usual Amazon.com experience.

Apparently, the default expectation of our Finnish friends is that people will pay, if you provide good service to them, as opposed to the typical US default, which is pay first, we’ll provide service later (maybe). This reminds me of a paper I read a while ago that talks about the impact of defaults on the behavior of people. Essentially, some choices we can and should make ourselves, but very often we just accept the default value we are presented with. If the default value is good for the individual, but bad for the society, changing this default may have a huge impact. For instance, Dan Goldstein and his colleagues found that the 28% drivers in the US are voluntary organ donors as opposed to 99.98% in Austria. The reason? The US uses an opt-in default, whereas in Austria you have to actively opt-out.

So how could this apply to BPM?

Well, consider the allocation of tasks to individual performers. If we let the performers choose freely, they might pick work that is easy, on top of the list, or simply fits into their current mindset. And the work that is on top of the list is typically the oldest work item. But in order to get the work done that is most beneficial for the organization it might be useful to restructure our worklists so that the topmost item (the default item) is actually the one the creates most value for the organization. We may want to reschedule our process instances based on their intrinsic value…

It may be a cultural thing, but this episode reminded me that if you provide good value, people are willing to pay for it. I certainly am. Jyväskylä, you’ve got an electronic money transfer coming your way…

Queensland University of Technology, Stevens Institute of Technology, Monash University, University of Queensland and SAP Research have launched a research project to explore the major issues within these projects and to develop improved modeling techniques and project management approaches for large-scale modeling initiatives. The outcomes of this project will streamline the design, integration, maintenance and communication of models with a focus on Enterprise Systems.

A series of initial focus group meetings are currently taking place with representatives of Fortune 100 Enterprises as well as members of the participating research organizations. Hot topics are: Showing the business value of modeling, finding the right level of process abstraction, and process standardization in multinational organizations.

• Raduescu, Corina, Tan, Hui-Min, Jayaganesh, Malini, Bandara, Wasana, zur Muehlen, Michael, Lippe, Sonia: A Framework of Issues in Large Process Modeling Projects. In: Proceedings of the 2006 European Conference on Information Systems (ECIS 2006), Goteborg, Sweden, June 12-14, 2006.

• zur Muehlen, Michael; Nickerson, Jeffrey V.; Swenson, Keith D.: Developing Web Services Choreography Standards – The Case of REST vs. SOAP. Decision Support Systems 40 (2005) 1, pp. 9-29.