Dr. Stein of Aris has a blog about workflow patterns in BPMN2:

“In many areas, patterns are used to codify best practices. A pattern describes a solution for a problem. Originally, patterns were used in architecture to describe architectural design ideas. In software engineering, patterns are used to describe typical software design solutions, for example like client-server architecture.

In business process management, the so called workflow patterns by Prof. van der Aalst and friends exist. In their original description, they described the most important 20 workflow constructs like loops, decisions, and sequence flows. Later, Prof. van der Aalst and other research fellows extended the list of patterns and revised the initial description (see workflow pattern homepage). Still, the original 20 workflow patterns are valid and a useful tool to learn a modelling language such as BPMN.”

I’m just not excited about the van der Aalst “patterns” that are oft-quoted in BPM circles. The more accurate statement is that they are snippets of BPMN that demonstrate how various “constructs” work.  They’re useful demonstrations of how BPMN can work, and how to use a particular tool to diagram specific constructs.  And the work of van der Aalst and colleagues was very useful as well in identifying edge case diagrams that expose tricky aspects of the notation’s execution semantics.  They are not, truly, patterns as I would think of them.  Showing three activities executing in a sequence is hardly a “pattern” any more than three lines of code that execute in a row are a pattern.  Splits and joins are just constructs of the notation. The patterns don’t identify the usefulness of the pattern or the “why you would want to do this” aspect.  In that sense, they largely fall short of the bar for a pattern in my book.  A typical name for a “pattern” in this study : “Multiple Instances without Synchronization”… huh?  A name only a parent could love.  What’s the business case for this that helps me understand how it relates to business process? There isn’t one.  The point of these patterns, documented here, is to identify technical edge cases and compliance, not to create patterns that you will base your actual design work off of … and maybe that’s my main complaint.

The “four eyes” pattern is a pattern (where n-1 potential reviewers have to approve something before it moves on).  There are lots of real patterns out there – and generally they’ll get names that make sense- an “observer” pattern, the “shadow process” pattern, etc.  Having voiced my complaint, maybe I need to take some time to document a few BPMN2 style patterns to clarify.  Anatoly Belychook has described a few on his blog, in the past (as well as anti-patterns).

Dr. Stein of Aris BPM Blog:

Computer users love to challenge each other by starting totally useless “flamewars”. Just think about how emotion comes up if people discuss Windows vs. Linux, Extreme Programming vs. classical software development, iPhone vs. Android, PHP vs. Ruby or EPC vs. BPMN. Wait, EPC vs. BPMN? Yes, I noticed several times that people have very strong feelings about both process modeling notations and tend to favor one over the other. For example, both groups (EPC lovers and BPMN lovers) claim that their notation is more expressive than the other one. But how could that be? Is one group lying? Or is there just a big misunderstanding?

I’ve personally never noticed this EPC vs. BPMN debate.

Mr. Uwe Roedinger makes the argument on Aris’ BPM Blog that you have to decide which “middleware infrastructure will be the ruling one.”

Essentially Mr. Roedinger makes a few arguments that I take issue with:

Characterizing a BPMS as “middleware” reflects the notion that a BPMS is just a scripting tool for SOA services… It isn’t.  There are middleware components in most BPMS solutions, but they are typically designed to tie into other middleware components that are intended solely for that purpose, not replace them. BPMS is more than just scripting SOA.

Arguing that you can’t make pragmatic compromises about hand-offs between systems – for example, at some point handing off (via an event or webservice) control of a process from one software package to another. Of course ideally you continue to monitor the progress of that process through the other software package, but for expediency or pragmatism, it may be necessary to short-circuit the unification of all things process.  Of course the purist point of view isn’t surprising coming from a modeling and enterprise architecture background as IDS/Aris does.  And of course ideally you abstract your processes into a higher level process controlled by a higher level process engine – but you can achieve nirvana over time, it doesn’t have to come starting with the first architecture design session, as Mr. Roedinger seems to imply.

Mr. Roedinger argues you must have transparency, and that to get this transparency you must have one process ruler. This sounds good, but our practical experience in the field tells us otherwise.  We have worked with legacy systems that aren’t integrated, but which provide a lot of transactional transparency through back-end reporting that is keyed off of common identities (a loan number, for example).  Additionally, we’ve introduced BPM solutions that address a portion of the overall process, and exposed incremental transparency for the process (in addition to the transactional data) for the portions we control, and then advised on portions outside our control to get the data we need for reporting (transparency).  After all, as long as the right data ends up in a datastore, we can use this data to expose what’s going on inside the machine that is the process.

Mr. Roedinger also implies that a process, implemented by BPMS A, can be reduced to a webservice call from the “ruling process”. I’ll assume he means an asynchronous call, because the processes we deal with aren’t so trivial as to execute in a few seconds and be wrapped by a simple webservice call.  So, from an abstraction point of view he makes a good point, but in reality, an asynch webservice call is just two webservices calls separated by some time.  At this point, we’ve devolved to the “hand off an event through the middleware” scenario that he described – with the notable difference that one process represents the “parent”.

To that end, in several instances we’ve implemented a “shadow” process – which monitors the process being performed in other applications, to create unified process metrics, and initially simply to monitor, with the controls coming in only after one has had time to analyze the data.  I believe this sort of solution is closest to what Mr. Roedinger describes as the “right” approach – but again I’ll stress the incremental nature of such a roll-out strategy.

Finally, Mr. Roedinger makes use of an example where the customer was choosing between SAP’s BPM and IBM’s Websphere BPM:

My conclusion is, and the experiences from different customers prove this, that the decision for the leading process engine is one of the first that has to be made in an automation project. Kind of a best practice decision has been made by a big German customer, where SAP and IBM technology were set as standard. The SAP internal processes will be automated with SAP XI, the overall processes by IBM WebSphere. And, very important from IDS point of view, all of the processes are modeled with ARIS and used as input for the different implementation tools ;-)

This isn’t really a decision – the BPM that SAP offers simply isn’t general purpose enough to drive the processes outside of SAP.  Moreover, I’m not sure IBM’s offering is strong enough to manage processes inside SAP without deconstructing them.  If you start with a truly general purpose BPMS, and SAP – this decision is a no-brainer.  The BPMS can be used to implement processes that aren’t addressed by SAP.  Or the BPMS can be used to leverage SAP in processes that extend its usefulness, including monitoring or being notified of changes within SAP, or even effecting those changes via SAP.  Who rules isn’t the key question to me – its where can I extract the most ROI?  And I think the key thing IDS is after is that Aris be the ruling “process modeling” software.  Which, if IBM and SAP are your BPMS choices, is probably not a bad idea.

We would encourage people to be flexible and pragmatic in their application of BPM, and don’t dramatically change your project just to accomplish a “ruling process” strategy.  Keep your ultimate strategy in mind, but get your project done with a laser focus on the business objectives.

Not precisely a BPM reference, but on the Aris BPM Blog, Martin Kling posted an interesting article on Risk Management.  It points out the over-reliance on a poorly understood method can really hurt your business – in this case the reliance was on VaR (Value at Risk) – which was even used to make incentive decisions for traders.  As Martin points out, this incentivized traders to take positions that had a high likelihood of small gains or losses, but potentially a very small likelihood of huge losses (or gains).  The small probability portion is ignored by VaR – which focuses on the 99% cases, not on the 1% cases…

There’s also a link to the NYT article that goes into full depth.  Both Martin’s blog and the NYT article are great reads.

The tie-in to BPM?  Visibility matters… If your business is relying on processes that are “black boxes” to perform well… it may be surprised when a “Black Swan” event occurs (one of those 1% events), and how much damage it can do to your business.  Usually people associate “black box” with a computer program – but in this case, a completely people-driven manual process is a black box – the time delay for measurement and information to reach executives, combined with the lack of quality data, yields bad inputs to executive decision processes.

BPM and other technologies can help in a few respects:

1. Document the process in a non-ambiguous, but human-readable way (BPMN being the chief technology for that).  This removes a bit of the black box element of process all by itself.
2. Measure the process – not just the run-times of various components, but the snapshots of inputs and outputs.
3. The measurement of process allows for better analysis – correlation analysis in particular – to find out what inputs drive better business.

At any rate, technological solutions should be viewed as tools to aide decision-making by participants in the process, process owners, and executives.  When management starts to view the technology *as* the solution instead of an aide to capable human thought and judgment, additional risk is foisted upon the business, because software can not by nature be designed to react well to Black Swan events.  But when used as a tool, software can provide the information that let’s humans sniff out the problems as they occur.

(Note: in the article, it is suggested that Goldman Sachs did just that – they’re models weren’t producing what they expected by a small margin of error – so they got human risk experts together to do further analysis – which led them to reduce and hedge their positions.  This is a classic case of human judgment triumphing over reliance on the model – the model was not yet showing a real problem, but it was showing enough variance for a human being to worry about it.  )

The case for modeling without thought of execution…

I recently came across a blog entry from IDS Scheer on their Aris BPM Blog. Thanks to Sandy Kemsley for pointing me to it from her blog. Upon first read of the article by Sebastian Stein, I was struck by the difference in perspective between those who implement processes and those who model them.

For those who model (Modelers), the Model is the chief output and goal. Having a Model that will survive the test of time is the goal. You can see that bias throughout the post. In fact, the core philosophy is embodied right here:

“A business process model, depicted in one of the popular notations like BPMN or EPC, should not contain any technical details. If the underlying IT infrastructure or implementation technology changes, the business process model should remain stable. Your warning bells should ring if you have to change your business process just because you changed the implementation technology used.”

The two key points:

1. No technical details
2. stable with respect to technology changes

Something Overlooked by a Model-only Perspective…

But there are some problems with this… First, all the BPMN/BPMS tools that I have worked with support layering of processes. This layering allows the user to create a model that reflects Business sensibilities at the top layer, and if needed, several layers down in detail. So, if your need is to model something without “any technical details” you are not prevented from doing so in the BPMN-oriented tools that I’ve used.

Second, when you get to a certain level of detail, the process design should be informed by Technology. How so? It is important to understand if a transition is a manual or an automated one. Is it a non-value-added manual step? Then generally we want to automate it, or ideally remove it. Value-added manual step? Then generally we want to optimize around its constraints, but automation won’t be the goal. However, we may want to use technology to reduce errors, to improve time-to-execute, etc. In the posting, Sebastian doesn’t go into detail as to what he considers a “technical detail”, but it does beg the question: what is too technical? How about input and output data from a step in the process? These are critical process design considerations (if you know that a piece of data is required as an input, but you’re not sure where it comes from, you have a problem to resolve in your process design. And those inputs and outputs help define the “contract” of an activity or subprocess (or even of the entire process).

Third, Modeling tools today make it exceedingly easy to change a Model to adapt to Process changes. While it seems like a good idea to have a Model that is “stable” with respect to technology changes – the fact is, business processes change faster and more often than the technologies and systems that support them. The real problem isn’t keeping the Process consistent across technology changes – the problem is that the underlying technology may not be flexible enough to adapt to the new process model! At the least, the technology layer is often not agile enough to do so at a sufficiently affordable price and on a sufficiently short timeline (unless of course, that process technology layer is a good BPMS).

Fourth, the resilience that one needs, truly, is with respect to performance data. Performance data analysis is what will drive my process improvement activities, or identifying a process operating outside control limits. I need to be able to compare the performance of my process now to the performance of my process next year, to the performance of the process last year… If my process changes dramatically, how do I do that? Note: I’m not saying the technology changed. The process changed. So what I need is a way to track data that will make sense even in the face of relatively substantial changes in my process. BPMS tools can provide this facility, either baked in or via smart modeling practices, by taking snapshots of data at key milestones in the process that are not likely to change, semantically, even while the syntax (specific steps) of the process may change. To this end, even though the order entry portion of the process may change dramatically, you can still track information around the # of orders in, the value of those orders, the time it takes to process them, etc. even though the order entry process may go from highly manual to highly automated to web-self-service (or may yet encompass all three).

How do we Sum it up?

So the argument is that a modeling-only tool buys you a benefit (stability against technical change) that you don’t need, while not providing a benefit (technical agility with respect to business process changes) that you do need… yet still doesn’t address the key stability need -that of the measured process performance data. Moreover, the integration from most modeling tools to an actual functioning BPMS is, for the most part, non-existent from a practical perspective. Even when that integration exists, it is usually lacking process execution sensibilities in the model. There is a difference between drawing a model that represents the business needs and drawing one that can NOT be executed because of ambiguities and inconsistencies. For the best integrations I’ve seen so far, the products and the integration are all written by one vendor. (I’m definitely interested in seeing examples of this kind of tooling and integration and I’d be happy to write up reviews for such)

I’ve actually written an import to a BPMS suite using an Aris model as a starting point – and its hard!  There is a ton of non-relevant data in the export – positioning information, for example – and other information you need is difficult to lay hands on (roles/ownership).  To be fair, this wasn’t a BPMN diagram in Aris, but it WAS a diagram of a process, in a very unstructured environment.  It wasn’t any easier than parsing it out of Visio vdx files.  My recommendation, is that if you are given a process modeled in a modeling only tool – your first instinct should be to redraw that process in your execution modeling environment rather than try to import it (unless the importer ships with your product, in which case, give it a try!).  You’ll be surprised how fast you can recreate the model in your execution environment.

Now what?  Does an Execution-Oriented Model still make sense?

Okay. Given the arguments Sebastian presents, it seems he is suggesting that if you don’t know what product you will use to implement, you should use Aris to model your process (in fairness, if you don’t know what execution environment you will use, paper, visio, and Aris are all good options). And that, because it is “agnostic” with respect to the implementation tool you use, there is some derived benefit (this is really the point I disagree with). However, if you are going to build your solution in a completely different toolset, and you accept my premise that exports out of Aris (and other modeling tools) into execution BPMS suites leave a great deal to be desired, then you come to an interesting crossroads. Is he suggesting that once given an Aris model we should just write BPEL xml or some Java code to implement the process? or that we should then use a BPMN-oriented modeling suite to re-model and then implement the process?

In our experience, just “writing code” to codify a process in a modeling tool is a mistake. For one, how can the business determine if you have faithfully reproduced the process in your code? Extensive usability / UAT testing might reveal an answer, but it is a very expensive way to find out, and it only happens after all the code is written – and any mistakes will be very expensive to fix at this point because they could be simple mistakes or they could be conception or foundational mistakes. An Agile development process can help, but many organizations have trouble carrying off this approach with traditional software tools. If the technical team uses a BPMN execution environment (a BPMS) to build that process, then the business will be able to see the process in BPMN, a language (drawing) that they can understand, and understand the semantics thereof. By visually inspecting the design, the business can eliminate the greatest proportion of future defects at the earliest part of the design phase. And the technical team will implement each portion of the process in context of the business process at that point. And that is critical for providing useful business context to the technical team at the time they most need it.

Which Model is the Master?

And finally, now that your Process is implemented in an execution-oriented BPMS, as well as modeled in your modeling-only environment… which Model is the “Master”? Of course, you can make either answer work.  But let’s be clear about the choice you make :

Option 1:  The Model as drawn by the business in the modeling tool is the master.  it does NOT reflect what is actually happening in the business, or within IT, but it does show what the business was hoping the process would look like when the project started.  (Optionally, it may have even been revised and updated at the end to reflect some of the changes that implementation and testing revealed needed to be made).

Option 2:  The Model that works as agreed to by IT and the Business, drawn and executed in the BPMS environment.  This is the model that was actually tested by business users in UAT, by Unit Testing in IT, and system testing in IT.  This is the model that is actually running your business process in production, and it reflects reality.

Is it important that your original Model is resilient to technology change in this context?  Is it relevant that your model doesn’t have any technical details in it?

Or does it seem to be more interesting that there is now a BPMN model that represents what actually runs in your business every day, that can be measured and analyzed over time.  Does it matter that this BPMS is resilient to back-end technology changes (activities provide abstraction to what type of integration, and each integration can provide abstraction as to what specific systems are being tapped)?  Does it matter that this BPMS can support relatively rapid changes in process to adapt to your real business?  Does it matter that you can map the data you are tracking to your Model, to generate heat maps and highlight problem areas?

Well, you can guess where our heads are at.  Modeling is important, but Execution makes it relevant to the bottom line, and makes the Model itself more valuable.  If you want help turning your models into reality, we can help.