Keith Swenson has another post where he compares Case Management to BPM:

“The two approaches are very different:

• Sherlock Holmes will use a case management approach, not a BPM approach, when solving a case.
• Bank of America will use a BPM approach, not a case management approach, to support signing up people for new regular accounts.
• Admiral Thad Allen will use a case management approach, not a BPM approach, when responding to the oil disaster.
• Amazon will use a BPM approach, not a case management approach, to handling sales of common books.”

I’d propose another example:  I sure wish BP had been using a BPM approach on that oil rig, rather than a case management approach that allowed winging it with decisions like whether or not to use drilling mud.  I wish there had been a little more BPM going on in the mortgage business pre 2008 – not just signing up new accounts but making sure that customers actually met credit and income requirements.

I think there are more than just mundane examples of where a little more BPM would be a good thing.

Keith has another interesting comment:

To say that these approaches are the same, because they both help to get work done, ignores the very essence of BPM and case management. Yes, they are both techniques to help accomplish work, but they achieve this result through different means.

[...]

This has nothing to do with any vendor’s product. I am not making a sales pitch here. Those that say their favorite BPMS can do all of this are simply pointing out that these two management practices can be supported with similar technology – and many products will support both approaches. But remember, BPM, and Adaptive Case Management are not technology, not products. They are both approaches to managing work.

Interestingly, because they are both approaches to managing work, the same people are likely to be involved in both approaches.  One can argue about which approach “wraps” the other approach, but as BPM is an amalgamation of techniques and approaches, the question (to me) is whether case management is just another one of those, or whether it is a whole “methodology” unto itself.  A relevant example:  Six Sigma and Lean are examples of different approaches to process improvement that, today, most people lump together because they both represent useful sets of tools for the same set of people engaged in process improvement.

Steve Wood, in the comments, captures my thoughts well:

“So, for example, when I look at how an agent supports a customer through an issue. At the high level, it’s very BPM-like, at the implementation level it’s very hybrid. I can optimize some tactical processes to improve performance and also optimize tactical experiences to improve case management.”

And of course, Max J Pucher has a well-worded  comment also:

“Analytic knowledge provides conversation pieces but no practical how-to knowledge and is thus quite useless.

The ‘war of who owns ‘adaptive cases’ is thus quite senseless. I do agree that I am chasing windmills in asking for a common sense approach, but at that is also the reason why the question whether BPM, ECM, E20 or ACM will bring adaptiveness won’t be agreed upon.”

Its an interesting read in the discussion / comments and the wealth of different perspectives – even from people who co-authored “Mastering the Unpredictable”.  Unfortunately, as with most of these discussions, there is a little too much focus on the arbitrary limitations of software tools (the specific experiences of the authors with either specific ACM or BPM tools), rather than sticking to Keith’s original premise that we’re talking about two different kinds of work, but it is a small blemish on a good discussion.

Keith has an excellent post in the form of a Q&A session, as a followup to an ebizQ recorded session that didn’t have time to address all the questions that came in.

Some choice quotes:

The knowledge worker supporting “planning by doing” approach is less about up front definitions of a process.  In general it seems to me that rule sets are primarily useful in order to clearly specify an automated response, and must be prepared ahead of time.  It is hard to see how you would use such rules when directly performing the work.

I can imagine someone defining fairly trivial rules – such as requiring approval above a certain $ threshold after delegating some work to someone else, and deciding that “on the fly”.  But as he says, “in general” the whole point of rules is to address rules at design time, rather than on the fly at run-time (other than by executing the rule)…

4. HOW DOES THE CONCEPT OF A SERVICE ORIENTED BUSINESS APPLICATION(SOBA) RELATED TO SOCIAL BPM, IF AT ALL?
SOA is an orthogonal concept to BPM in general — although there is a widespread misunderstanding about them being similar or the same thing.

Agreed.

Q&A #7 was particularly well-done, as it relates to something Keith has been thinking or writing about a lot lately – unpredictable work and how to track it or measure it – too long to quote here, but please link over to Keith’s page and read it.  He breaks down at least 4 approaches to tracking unpredictable work for the purpose of better understanding it and improving it.

Keith has one more anecdote I had to quote because it is mind-boggling in hindsight:

I remember a friend who was at a company that was acquired by Computer Associates in the 1990′s.  At that time, CA ran an email system, but they allowed access to it only at lunchtime and after hours.  You see, nobody was allowed to access email “during working hours”.

Well, I think it is safe to say that “social” is facing some of the same challenges in the workplace today.  But 15-20 years from now people will look back and wonder that companies weren’t more encouraging of tools like Twitter and others to get work done.

Keith Swenson makes the case for simpler run-time editing of a process in the comments on one of his blog posts.  This might even be a small insight into where his conversion to the Case Management fold comes from:

“The difficulty with changing a process comes when the person who needs to make the change does not have the skill to understand the process editor and the implications of any given edit.”

This is a failing of many of the BPMS tools ( and even worse, for the pre-BPM tooling out there – no one even tries to edit the process for an ERP system! ) …

“This has led us to believe that to allow a process to be changed, there needs to be a very simple process paradigm — like a checklist — that can be easily modified by 100% of the managers. It is not a technical challenge, but instead a usability challenge.”

I think the basic point here is: software vendors need to invest in deeply understanding the needs of the users (managers) and invest in giving them control over complex changes with simple analogs (e.g. checklists, but I’m sure there are other approaches as well).  I think the software vendors still have a long way to go to make the hard stuff easier, and this is really the whole point of software engineering – to make the previously impossible possible, the previously hard easier, the previously complex understandable.

(Just yesterday I was checking out RAVEN, for example, which converts text descriptions of a process into flow.  It is a pretty simple modeling approach.  Blueprint offers something nearly as useful – you outline, which is converted into process flow on the fly.  However, Blueprint doesn’t attempt to parse your sentences for nouns that indicate swim lanes or actors.  )

Keith Swenson plays “Go Fish” with BPM Definitions:

This was not a scientific study — just a couple of hours of google searches to try and get a feeling for the deviant definitions.  The collection above is not representative — I picked what I felt were the most unusual definition.

Look, people have a lot of different definitions for what constitutes Tex-Mex*… but that doesn’t mean you won’t like it, or that it isn’t good.  You will, and it is.

People have different definitions of hot weather and cold weather, too.  I don’t feel that this diminishes our ability to discuss temperatures and humidity and, even, hot weather.  Colorful language is just part of the fun.

The part I find more agreement with:

My overall conclusion is that there is an “IT community” which talks about BPM as being equal to/converged with/part of system architecture/SOA/EA.  This community represents 30% to 50% of what articles on BPM.  There is another “business community” that represents the non-IT management side and sees no connection to system architecture at all, and that is maybe 40% to 55%.

The problem is that these two communities don’t communicate with each other.  They have their own magazines, their own blogs, their own books, their own analysts, their own forum sites.  Like the Democrats and the Republicans, these groups are being polarized by their own in-bred ideas bouncing around an echo-chamber of their own making.  It is a divide with potentially tragic consequences for the technology consumer.

Communication is incredibly important – BPM doesn’t cause this communication rift- but BPM projects really expose this issue because of the close proximity of the IT and Business team figuring it out and the iterative nature of the projects.

* if you don’t know Tex Mex, please come to Austin Texas and we’ll show you.

I’d been looking forward to hearing what Appian would say about their “Technical Case for Case Management”.  Part 1 was just a teaser, and Part 2 promised to get into more details.

But when I read part 2, I could just hear Keith Swenson’s dismay (or actually, share it).  Appian describes it thusly:

The first and foremost feature in a Case Management solution is “Ad-Hoc”.

While I appreciate the effort to explain how Appian addresses case management,  that is a very underwhelming start.  The use of ad-hoc activities in BPM and BPMN is well-known (and well supported by at least some of the tools that aren’t BPEL-based).

But this is *not* what Keith (and others behind the ACM movement) are talking about when they talk about case management or ACM.  While the “ad-hoc” activity may happen at any time or place or sequence, what the ACM crowd are after is that not only is the “when and where” undetermined at design time, but also the “who, what, and how” is ad-hoc – determined *at* run-time.

Hopefully we’ll see someone step up with a better explanation of the technical attributes of their case management solutions.  I shouldn’t be too hard on Appian – at least they’re trying to explain the underpinnings, and this was only part 2 – perhaps in subsequent articles they’ll have more to say – but part 2 was not encouraging to me.

Keith Swenson weighs in on Social and BPM:

Similarly, proper use of social software will be about individuals producing, publishing and running their own processes. Not collaboration on the design phase, but designing individually, and collaborating with a completed process.  This won’t just be the BPM lifecycle using social software, it will be the elimination of the BPM lifecycle, the elimination of a design phase, the elimination of the separation between designers and workers.

How our expectations have changed in just a year – I read the above statements and agreed.  And yet, I remember a year ago even getting people to buy in to the idea of social features around designing BPM was a stretch (here’s a post from barely 9 months ago on the subject).

One thought-  social collaboration on structured processes will be important, just as Keith argues that collaboration on “user-designed” processes will be important.  As Keith put it “collaboration on the finished product” (his emphasis).  Social collaboration of users within a process could result in best practices bubbling up – much like some of the improvements discovered on factory floors by the people who work the line – but you have to have support for collecting and acting on that feedback over time.

The only part I really couldn’t agree with:

“This won’t just be the BPM lifecycle using social software, it will be the elimination of the BPM lifecycle, the elimination of a design phase, the elimination of the separation between designers and workers.”

The work will change, but I don’t believe process design goes away.  I think it just means that a rising tide lifts all boats- making more processes accessible from an ROI and skills point of view – not eliminating the need for design on a significant number of processes.  In other words, I don’t think that process collaboration turns process designers into typists whose job has become obsolete because everyone does their own word processing and typing.  I think it is a bit more like introducing productivity tools that make something that would previously have been difficult, easier.  Lowering the barriers to entry, rather than eliminating the whole discipline and process of process improvement.  However, I reserve the right to disagree with myself in a year or two as we see what the future holds! We’re still learning what “social” can mean for our businesses – too early to close our minds to a range of possibilities.

(As an aside, this article from Keith is a good read, but I disagree with his conclusions)

Keith Swenson on Airline Mergers not using BPM, making the case for ACM:

Usually when I talk to BPM experts, they say something like “Of course you wouldn’t use BPM for something like a major airline merger”.    Most people understand that you would never use BPM to arrange a lunch with a colleague.    There is broad understanding that there are things that BPM is simply overkill for, or too slow for.

The merger between United and Continental is a unique event.  It has never been done before, and will never be done again in the same way.  It has similarities with other mergers, but not to the level of detail that specific action plan (process definition) could be drawn up and re-used.  This is a case where a pre-defined process will simply not be worth the benefit, or the cost in terms of delay.

Am I to believe that they used an ACM product for this?

Going into the weeds here, though I think that makes my basic point, here’s some of the background thinking:

Companies that engage in acquisitions a lot actually do have pre-defined processes for acquisitions – IBM, Cisco, Oracle.  Are there parts of the acquisition that don’t fit neatly in a box? sure there are.  That’s why it is called BPM, and not automation.  Keith is giving us a false choice: all paths must be defined in BPMN in order to be BPM, on the one hand; on the other – nothing predefined in ACM and process nirvana is achieved.  I’ll just assume that ACM would equal process nirvana in this case, and focus on the BPM choice to demonstrate my point.

With the right abstractions in your BPM models, you don’t model all possible choices, the choice is just data along the path to the next node, rather than having a separate path per choice. Nodes can be well-defined BPMN models, or they can be applications, or they can be “ACM” style processes like “Meet and make a Final Decision”, which may end up being 3 meetings or getting some additional emergent process defined.

Or they could map out the process they’d like to follow in Blueprint or ActionBase and go from there – much lower overhead for a one-off process- although THIS process has an effect measured in Billions so it might actually be worth it to spin up some cycles on defining the process even if it isn’t a running implementation of the process.  Yes, requires a little bit of thinking ahead – but it doesn’t require BPMN – and it also allows for documenting any changes as you go.  And yet, I’d still call it “BPM”.  From a technology point of view, these folks may not be using a BPMS to do their acquisitions.  But that doesn’t prove that they couldn’t.  Whether a BPMS would be helpful or not largely depends on how well it supports this kind of use case, and that varies widely from one software package/vendor to another. Part of the problem: is “BPM” defined by what a BPMS can do for you? or is a BPMS defined by what you need to do “BPM”?  Tough one.  But you see this kind of problem all the time in software market definitions.

Do I think ACM could be a good fit for an airline merger? Sure, depending on the specific software and its features – this isn’t a run-of-the-mill situation.  But if I use Keith’s logic, the fact that the airlines didn’t use ACM for this merger is proof that ACM doesn’t solve the problem.  (tongue in cheek)

Generally in my experience if your modelers can’t model the process, you need to find new modelers.  I might need to add a corollary though – your BPMS should be capable of handling abstractions well (like generic failure events, arbitrary data definitions, dynamic binding to service definitions or sub process definitions… )  It sounds like a lot of the folks writing about BPM and ACM still haven’t used a BPMS that supports these features.

(Incidentally, I agree with Keith that you wouldn’t use a BPMS to schedule lunch with a colleague.  However, that’s because there are already good software solutions for scheduling lunch.  If I was writing one of these solutions, like Tungle- I might very well use a BPMS to coordinate finding the right time on our schedule – because it is often done via electronic means and the back-and-forth is pretty inefficient.  Tungle.me didn’t use a BPMS – but they sure could have.  The point of BPM or ACM isn’t to do everything that they could do – it is to apply them when you don’t already have a good solution)

One of the more entertaining comments in the whole BPM, “you’re not my father” (Star Wars reference, sorry folks) debate:

Using an object model and letting actors express processes in terms of assembling (and continuously changing) those objects in the desired way is a very powerful way of creating applications. Is it an application? Is it a BPM process? Is it a Mashup? Who cares? The technical questions have to be asked at some point in time, but at first one needs to check with the business if they can get the functionality they need ASAP, and if they can adapt it any time they want.

We are discussing the ‘Emperor’s New Clothes’ here, I’m afraid. Let’s go and do something productive.

I think there is entirely too much gnashing of teeth over the new three letter acronym.  I might have to check out what Max’s product (Papyrus) really does now, after reading three interesting comments from him in as many days.

In the main body of the post, Keith rightly points out that there was way too much focus on BPEL in the BPM community, despite protestations from some fairly vocal members of the community.

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim’s intent):

• Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.  It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.  This works if the process is predictable.
• Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.  Since you can not predict it, you have to elaborate it as you go along.  You design it, as you are doing it.  There is no development life-cycle.  This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management.  By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don’t know, why not just call it “design by doing” and use that as the tag-line for your product offering… ACM doesn’t quite have the same ring to it, and it isn’t nearly as easy to relate to.  Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith’s blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:  a bunch of companies have already acquired one or two BPM software vendors.  How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?  Would you rather be the “XYZ” software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?  Of course!  (well, as Max says, he doesn’t care about the labels for his product, Papyrus, so I don’t mean to personalize this to Max, by any means!).  And if you’re a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle – RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.  But like some others (Anatoly for example), I’d like to keep BPM separate from BPMS (method from technology).  There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn’t benefit customers or practitioners.   I see managing unpredictable work as still being “process-driven” even if others don’t.  Design-by-Doing sure sounds like a process to me, folks.  Maybe a meta-process, but a process nonetheless.

I’d like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings – explain why your software is just the right socket wrench for the job, rather than a screwdriver.  Educate the market on why the software fits the problem definition.  As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

Dave Duggal attempts a take-down of BPMN in a comment on Keith Swenson’s blog, concluding with:

“There is a reason why business leaders are suddenly have wandering eyes, they don’t think BPMN is the vehicle for the component-based distributed future.”

I humbly refer you to Bruce Silver’s blog for a quick rebuttal.  The market is adopting BPMN more than ever, and at an increasing pace.  Better to spend your energies figuring out how to make BPMN more effective (in combination with whatever other techniques you recommend) rather than making your recommended approaches an either-or proposition.  I think I’ve been hearing about this component-based distributed future since CORBA. I’m all for distributed and component-based, but I don’t hear an either-or proposition, and this doesn’t sound like business-leader language.

The question business leaders ask is will BPM and BPMN yield ROI? and the answer is yes.

Great article by Keith Swenson explaining why large and complex organizations are difficult to model using “scientific management”.

I think Keith makes a couple of great points that are worth letting soak in:

• Complex systems are unpredictable
• Organizations that “Learn” can adapt when the environment becomes less predictable.
• If you divide your organization between brains and brawn, you are failing to reach your organization’s full potential.
• Learn from *near* mistakes – not just the *actual* mistakes.

Of his takeaways for BPM- my favorite is transparency:  people involved in the process need to understand the part they play and the context of the process if they are to help the organization learn and improve upon it.

Worth the read and there’s a good comment-stream as well.

On a tangent relating this to political science…

For very complex organizations, it may well be worth applying some theories from political science and international relations to your thought process. One of the most useful political science theories is “Realism” – the notion that nations act in their own best self-interest, in a rational and calculating way.  My first exposure to this was in Dr. Krasner’s course on International Politics.  Usually deviations from what appears to be self-interest can be explained by imperfect information or miscalculation – but in general realism probably most closely describes how most states will act at critical moments of international relations.  In large, complex organizations, it helps to assume that departments, teams, and divisions will apply a healthy dose of Realism to the way they behave.  Part of how you deal with overly complex systems is by having useful abstractions that give you a shortcut to understanding, not ALL of the minutiae of cause and effect, but rather the SUM TOTAL of these effects.  It is much like the difference between micro and macro economics. Realism does not deny the other effects, but it argues that they are secondary effects rather than the primary correlating explanation.

Keith put together a pretty interesting chart reflecting business process technologies over the last few decades, showing how they relate on a spectrum from predictable to unpredictable, as well as how firm the consensus about how to use the technology has become.

Keith Swenson, Thoughts on Collaborative Planning, "4 Process Trends & 1 Gap"

As usual, Keith presents a good thought model.  But of course there’s a gap that may or may not be real – it is Keith’s perception of the gap between manual (email) processes and workflow-based processes.  I think there are actually a range of technologies inbetween these two approaches-  ticketing systems, case management, and wikis are all examples of technologies that address the space described by the gap.  Still, I always find this kind of graph thought-provoking: it organizes your thoughts in support or in contrast to a particular point of  view.

Keith Swenson has a few posts on the frustrations of email these days – and after some time experimenting and a friendly nudge from me, he’s come around and tried OtherInbox.

The problem?  Too much spam, which makes email nearly useless.

The proposed solution (my take):  use an email provider that has a REALLY good spam filter.  Like Gmail.  I have a very old personal address that gets 99% spam but the occasional personal note comes through it.  I forward it through a Gmail account and as a result I see the 10 or so useful emails that show up on that email address per year.

But, Gmail only effectively filters spam.  It doesn’t help you filter merchant emails that you would like to receive, but perhaps not in the quantities that you receive them.  Only some merchants are nice enough to let you state how often you want to hear from them.  There are lots of opt-in situations where you are required to provide an email address.  You could use a single “spam email” to opt-in to all these confirmations, etc.  But then you can’t tell who gave your email address to the spammers when it does go bad, and you can’t turn it off selectively.

OtherInbox solves that problem by letting you give each merchant a unique email address that you can later turn off if it becomes an avenue for spam.  You can also use it to sign up for group mailing lists, and the like, which are more likely to get compromised than some commercial accounts.

I think between Gmail and OtherInbox, you can largely whip the spam problem.  For now…

Keith is consistently writing the clearest thoughts on the subject of “Process Reification” vs. “Model Preservation”.

In this particular article on the subject, Keith focuses on a very common misconception in the BPM community (even by some well known names in the field):

I have met so many people that think that BPM is just a scripting language for SOA services.  These people will argue at length that “BPM is a part of SOA because SOA is useful without BPM, while BPM is useless without SOA”

(Notably, he also references a good article by JP Morganthal which sounds controversial – keeping your SOA and BPM initiatives separate, but which actually makes some very good points about why SOA and BPM initiatives are motivated by different organizational and business imperatives).

But BPM is not just a scripting language for your SOA services.  To quote from Keith’s blog: “SOA is a tool we use, while BPM is what we do.”   I think this is a really important dichotomy to understand, and explains precisely why so many companies that purport to be in “BPM” still don’t really get it yet.

Having just referenced Connie Moore’s thoughts on collaborative BPM, it seems a propos to then turn our attention to “the process wiki” – which I learned about through Keith Swenson’s blog post (“Rise of the Process Wiki”) on the subject (and I’ve since seen a couple of additional references).

If something like the process wiki takes off, it could really change some things in the BPM world.  I’m still a little underwhelmed by what is already in the wiki, but I think that is partly because the vendor-specific collaboration forums offer more interaction with the models directly.  But, where I can see real value is in promoting discussion of the processes that are posted, trade-offs in design, etc.  That’s where it would play to a wiki’s strengths, in my opinion.

You can find a pretty good discussion of the site on Keith’s blog, as it dovetails nicely with his interest in model portability and XPDL as a vehicle for such.

“Window Dressing” can kill your project.  It can even kill your BPM project.  Keith Swenson wrote a humorous but educational piece on an in-house BPM project gone awry.  Anyone who has deployed an internal application can relate to his story, but if you’ve deployed your own technology (or your own BPM technology) it hits especially close to home!

My favorite point made in the post is that flashy or pretty UIs don’t add value in-and-of-themselves.  That the focus should start with function and value, and apply the Keep It Simple Stupid (KISS) principle.  The extra UI “features” are break-even, if not value-detracting, from a value proposition.

Interestingly, Keith’s very next post was about the same kind of window dressing… but this time on the “back end” of integration/services:

I was asked “What common mistake do people make that causes unnecessary delay in BPM projects?”  The answer: Many projects have a goal to implement too much at once.  Some projects attempt to turn a manual process into a completely automated “straight-through” processes where there is no human interaction at all.

It is true that the more you can automate a process, the lower the cost or running the process.  But the cost of automation can vary greatly from activity to activity.

As he points out, integration is expensive.  Wrapping that legacy application as a service, is expensive.  It often makes sense to start with more easily attainable goals as a fallback position – by enabling the process without integrations first.  A technique that we’ve found effective on our projects:

• Start by modeling the process flow (which includes steps such as process mapping, inputs/outputs, etc.)
• Get the right level of logical abstraction in the second pass (re-organizing the original process)
• Get rudimentary UIs in place to allow running the process with as few integrations as possible – fewer integrations even than what the project requirements are.  Make sure the happy path works.
• Build test services to mimic the behavior of the integrations where possible – this allows you to test the various outcomes, exceptions, etc.
• Now prioritize and build the integrations that improve the process, based on the value of the improvement as compared to the cost of the improvement.

In fact, a process can be deployed with substantially all of the integrations yet to be completed, if the business users and IT professionals can be pragmatic rather than idealistic.  As Keith himself states:

There is an emotional side.  Some people are shocked when I suggest that we simply assign a task to a user, and have that user manually update the information in the third party system.  It just seems wrong to automate the process so that people can manually do a task.  This group-think often pushes a project to an all-or-nothing stance in process automation.  Striving to automate that last 5% causes most of the delay and cost of a process automation project.

This is best-practice process improvement as enabled by BPM.  It adheres to some of the principles that folks in the Lean school of that would espouse: namely, that you don’t let technology get in the way of your process.  Figure out the process, then use technology to improve it as the process stabilizes.

(As an aside, on one of my recent projects, rather than wrap batch scripts as synchronous transactional web services, we just continued to trigger them the old fashioned way:  by inserting records into their job-scheduling tables and polling for results.  It isn’t a particularly exciting method of integration, but these batch jobs already supported it, and it gave us better velocity toward production deployment. )

Just giving a shout-out to Keith Swenson, who has changed his blog’s title from “Go Flow” to “Thoughts on Collaborative Planning”, and he explains why in this post.  I think its a bit like when you start writing a book, a page at a time, and at some point you realize you have the wrong title, or you can think of a better one.  Keith’s blog is more about quality than quantity, and every time he posts I’ve found it to be a valuable, thoughtful discourse, and maybe more importantly, he’s been thought-provoking.  Here’s hoping there’s at least another 3 years and 90 more posts on your blog, Keith!

A couple of posts on this subject recently, one of them by my good friend John Reynolds (Process Manager Interoperability).  Keith Swenson made a reference to the Wf-XML spec as being relatively little-known and he wasn’t kidding – neither John nor I had heard of it previously and no doubt part of that is because the name says nothing about what it can accomplish for you.  The letters “Wf-XML” just don’t say anything about what this spec will do for you (allow you to start, monitor, and react to the completion of a process run in another system/environment).

As John points out, it seems higher probability that consumers of BPM technologies will benefit more from technologies that help with interoperability between those BPM tools, rather than from the more complicated task of actually migrating those implementations across BPM tools.  Of course, the SOA camp ca well claim that they solve this problem – but it isn’t the service-oriented nature of the interface that is the problem – its having a purpose-built standard for the design pattern of two independent process platforms communicating about the state of a process instance (or subprocess instance).

Keith recently listed 21 questions in his blog that he recommends a prospective buyer should ask BPM vendors when comparing products.  Not all the questions are about interoperability exclusively, but the first few are definitely focused on interoperability.  However, you have to weight questions based on how important they are to you.  You can get a highly inter-operable product that doesn’t functionally *do* what you need it to do.  You can get a product that functionally hits all your needs but doesn’t support interchange formats… and you can find data points inbetween.

Unfortunately we’re still very early in the world of interchanging business process models.  I would be hesitant to place interchange high on my list for differentiating my vendors.  I would place more emphasis on functional requirements, total cost of ownership, and adherence to my IT approach.  After those needs are met, then I’d start sorting by other things (interchange of BPM models being one).  One of the things I’ve noticed is that the general assumption seems to be that if I export a business process from one tool to XPDL and import it to another, it will just run in the new tool.  That isn’t necessarily the case.  Different BPM tools provide a different level of support for self-contained implementation specifications (implementation of those activities or services), and generally speaking those implementation details won’t translate, because they aren’t explicitly part of any of the BPM specs.

Having said that, Keith has a few questions to ask that have an impact on interoperability or interchange, but are also key differentiators of product capability, including questions about nested processes and how deep the nesting can go, data tracking, event posting, supporting wf-xml, exposing processes as webservices, etc.  Check out his list for more in-depth discussion of each one!

Keith has updated the community with a Model Portability Landmark:  WfMC’s announcement of a BPMN Model portability test.

This is a great step forward, and Keith does a great job summing up the results.  Unfortunately, from my perspective, the portability standard uses XPDL, rather than the as-yet-to-be-approved BPMN 2.0.  I have nothing against XPDL, I just wish some of the vendors I work with supported it!  Without that support, I’m tempted to rain on the parade of this announcement of portability.  For example, missing from this list on WfMC’s website are Lombardi, Savvion, Appian, Intalio, Pega.  Well, Pega and Lombardi (arguably market leaders based on Analyst reports) were recently placed prominently in Gartner’s Magic Quadrant for BPM, and they don’t support XPDL.

However, there is a silver lining for those of us who don’t use products that support XPDL.  Whether BPMN portability can be accomplished or not is not longer a theory.  It is a fact.  It can be done, and it has been done.  Now the question is whether the BPMN-2.0 supporters will get to the altar of portability sooner than later… one can hope!