Every so often, someone makes the argument that essentially nothing has changed in the world of BPM.  Actually, this isn’t unique to BPM – it is a common refrain across all kinds of software categories.

And it is tempting to buy into this, when you realize how durable a writeup like the history of BPM can be (this isn’t a bad writeup, by the way). But one has to remember that history *should* be a bit durable with the passage of time. Jon Pyke recently opined that no one in BPM has anything new to offer.  But the substance of his post is that the marketing isn’t differentiated, and the product positioning isn’t differentiated, and further, that the people who work at these companies don’t know what differentiates them.

Having worked on both sides of the coin (on the software side and the consulting side), I have to disagree with some of Jon’s conclusions because the input data is more limited than he’s realized.

For example:  of course the marketing messages are commoditized among BPM vendors, as is product positioning.  Sadly, it is perfectly easy to copy someone else’s marketing and positioning – it takes minutes, hours, or days at most to do so.  I think the tragedy in BPM is that all the vendors seem willing to implement “checkbox” versions of every feature that analysts care about, rather than go deep with the product in areas that produce real value for customers.  Unfortunately, vendors have been largely rewarded for such behavior with good product comparison reviews and chart placement – but their customers have not been similarly rewarded by this kind of investment.

There are real differences in these products, but it requires a much more in-depth understanding of the products to appreciate it.  Can we be surprised that customers have a hard time achieving this level of product knowledge during the evaluation process?  I used to work with someone who was always telling me how “nothing had changed” in the last 5 years in BPM – at a time when, 5 years before, there was no BPMN – and at that time, BPMN was the de facto modeling standard for BPMS offerings.

There has been quite a bit of innovation in the last 10 years in BPM, but some of the best ideas didn’t get enough investment to go from interesting to indispensable, and some of the best ideas really were commoditized – picked up by all the pure play vendors (and later, but the stack vendors).  I could argue that nothing much has changed since 1994, when I wrote a sales process application that leveraged Lotus Notes VIP to replicate sales data and manage workflow between Sales, Sales Engineering, Manufacturing, and R&D.  But that would be a bit disingenuous. I could write that solution in 1994, but I didn’t have a way to communicate the process to the business (BPMN), that accurately reflected the implementation so we could make sure we had it right.  And I didn’t have a standard data representation for analyzing the process data (for business process improvement).  I certainly couldn’t handle in a trivial way a process that required parallelism the way I can with executable BPMN models.

Jon says:

That’s why, and I’ve said this many times before, BPM is far too important a topic to leave in the hands of product vendors – this is a Business thing – the clue is in the name BUSINESS PROCESS MANAGEMENT. [...] They will talk about the presentation layer, the SOA integration support, analytics, modeling and what have you.

This is, unfortunately, true of a great many people in the BPM ecosystem.  However, it doesn’t sound like a few of the pure plays that have been acquired (take a gander at Phil Gilbert’s blog for several essays on the subject of business taking control back from IT), and it doesn’t sound like some of the new vendors (ActionBase as one example).  Whether these vendors are well-represented at Gartner conferences is another question entirely, but it is ironic that it is typically the small vendor that is more focused on business value. One of Jon’s last points:

Every vendor believes they are unique but the fact of the matter is many of the software metaphors used in these products were defined by pioneering workflow vendors such as Filenet, Staffware, Plexus and Wang

Well, honestly, software metaphors are meant to be re-used, so I’m not sure that that, in and of itself, is a point of criticism.  For example, some of the metaphors in older integration technologies like CORBA and DCOM are embodied in SOAP and WSDL – but not many would argue that web services weren’t a step forward. And if BPM functionality is truly commoditized – is that bad for the customer and the industry if it becomes more standard and more cheaply available?

I know it is tempting to look at the glass as half-empty, but with so many BPM vendors performing so well in a challenging environment, its hard not to look at the glass as half-full. Call me an optimist.

Theo Priestly on BPM Redux wrote about ArisAlign and its lack of “buzz”.  I’ve had similar feelings about Aris’ user experience, and the feeling that some of the enthusiasm espoused is a little forced – sort of trying to hard with the “I (heart) ArisBPM” pins, etc.

But the post reminded me of a theme that has been on my mind a lot over the last year: Design Matters in BPM. As if there was any doubt, I see more and more evidence that in the Second Decade of BPM, design will matter.  Not just a little bit.  I believe design will dictate whether BPM achieves ubiquity in the business. Design will dictate which tools will benefit from that ubiquity.

Apple serves as a good example of how much design matters in an industry that appeared to be commoditized (personal computing, cell phones).  Some might argue that BPM software isn’t commoditized yet, and therefore the focus might be on features/functions rather than “design”.  But I think the key elements of BPMS are, by enterprise software standards, fairly commoditized:  there are many players in the space, customers have a difficult time discerning the differences from a feature/function point of view, and ASP (Average Selling Price) is likely declining for most BPM vendors.  There are also a couple of open-source BPM software offerings on the make.

Combine the above with a trend toward putting BPM suites “in the cloud” and offering them in a SaaS model, and it really starts to look more like a utility.  But what takes it to the next level?  Here are some areas of BPM and my thoughts about how well they’ll differentiate vendors…

• Execution.  I think everyone agrees execution is nearly commoditized.  There are *real* differences at the execution level, but the market doesn’t recognize these differences in a way that channels dollars to the best execution engines.
  
• Simulation. Many of the vendors offer this.
• More modeling constructs? Already, vendors barely provide a fraction of the BPMN modeling capabilities defined in BPMN 2.0 (or even 1.0).  So, there’s an opportunity here, but fast-following will be pretty easy.
• Process Discovery? This holds some promise for differentiation in the short-to-medium term, in my view (there are only a few vendors who even claim this ability).
• Optimization? This has potential, but the current solutions simply don’t achieve it.  They work really well on small data sets and don’t (yet) let you efficiently do “optimization” on enterprise production data.  There’s a significant software investment to make here, and opportunity for differentiation.  Pair optimization with process discovery and you’ve got something really interesting…
  
• Modeling tools?  This is heading toward commodity rapidly.  Absent the advent of SaaS software I would have predicted an open source modeling tool would gain pre-eminence and get embedded in a lot of commercial products.
  
• SaaS / Cloud offering? There are already numerous choices and prices are heading toward standard increments.
  
• Community / Collaboration?  Outside of BPM, these are already fairly commoditized from a feature/function point of view.  Wikis, chats, Instant Messaging, Videochats, Communities – these features will not provide differentiation on their own.  In fact, vendors may rely on Wave or similar technologies to incorporate collaboration without making some of the IT investments that early adopters have had to make.
  
• “Dynamic” BPM or “Case Management”.  Call me crazy, but I remember CASE tools being all the rage in the mid-90’s.  I think unstructured, dynamic, and case management style processes are important, but I don’t think the technology required will offer differentiation to vendors for long from a feature/function point of view.  What they offer is a “better fit” to these use cases, but they’re not solving a problem that couldn’t be solved before.  (Note: Better fit matters, its why you should use BPM tooling to solve process problems rather than just slinging some Java or PHP code or hoisting a SOA stack into place)  To the extent that these “case management” tools are better, its a result of better design to suit the problem, not a case of out-featuring the other guys…
  

The opportunity for BPM vendors will be to produce differentiation based on the design of their products and offerings, by producing designs that engage the users, that elicit effective and efficient usage.  Collaboration, Unstructured BPM, Process Discovery, and Optimization all offer the biggest opportunities for differentiation by product design, in my opinion.

In closing, I should clarify that product design is not just skin deep.  Some make this mistake when they look at Apple Products and see only the outer shell.  Good product design goes much deeper than the UI, than the outer shell of the product.

The End of Days.. ahem… The End of BPM, is here.

Or is it?

We have several pundits proclaiming so (either anonymously or otherwise). We have several vendors and analysts and bloggers dancing on the grave of BPM (or the pure play vendors). We have even BPM advocates bemoaning the loss of the BPM vendors of yore.

But lets take a step back for a minute… and imagine a strange alternate universe…

[fade to black, gradually clearing away as the voiceover starts]

Let’s imagine a world where there are only 3 BPM engines in the world, like the three heads of Cerberus. One from Oracle, one from IBM, and one from Microsoft. Or, if you prefer hydras, we could have another one from SAP.

BPM will have achieved the ubiquity of RDBMS because every corporation that buys software from these giant software providers will have at least one BPM engine as part of their enterprise stack, along with requisite modeling tools. Along with myriad integration technologies to plug these into existing applications or even other BPM engines.

In this world, there will still be opportunities for start-ups to sell tools for building applications to run on these stacks, just as there are still opportunities for start-ups with better SQL tools.  There will still be opportunities for open source BPM engines to compete with commercial BPM engines, just as there are open source RDBMSes competing with commercial ones.  If the Techies try to bury BPM in IT, the Business guys will drag it back out into the light of day where it belongs because they have real business needs to address.

Because it has never been about BPM engines, the parts that the business never sees.  Or software stacks.  Its always been about the ease in building the applications that the engine runs, the ease of adapting those applications to changing business requirements (processes), and the effectiveness of the measurements, dashboards, and analytics that provide the learning feedback loop for the business.

[ fade to black and then the lights return ]

As we wake, groggy from this little daydream… what was so different about our alternate universe?

It turns out, while we like to root for David over Goliath, the various BPM software companies selling have largely done well for themselves, their shareholders, their employees, and their customers.  Not a one of the pure play BPM vendors went out of business (or even came close, so far as we can tell).  A few IPOs would have been more exciting.  And in times when enterprise software companies were awarded better multiples, might have made sense.

And the new batch of BPM tech and companies coming along is pretty interesting too.  I see no reason for melancholy with the batch of startups that are hitting the market with interesting products that take different approaches to BPM (or facets of BPM).

I think things might just get more interesting.  Ubiquitous BPM has a good ring to it.

So, when twitter turned up mentions of a new language from Google called Go, I was sure it was a prank.  I even looked at the calendar to see if it was some kind of day worthy of pranking the Internet at large.  After I saw a few more tweets and retweets about Go, I even clicked the link to see what it took me to (honestly, try searching for “Go” sometime… you would think the people at Google would understand that a common two letter word may not be a great search term…).

So I read the FAQ on the “Go” site here.  Despite my better judgment I do like some of the conventions and minimalism they’ve adopted, such as having postfix, but not prefix notation for incrementing.  And there were a few statements that *really* hit home for me, like this one:

Another point is that a large part of the difficulty of concurrent and multi-threaded programming is memory management; as objects get passed among threads it becomes cumbersome to guarantee they become freed safely. Automatic garbage collection makes concurrent code far easier to write. Of course, implementing garbage collection in a concurrent environment is itself a challenge, but meeting it once rather than in every program helps everyone.

Finally, concurrency aside, garbage collection makes interfaces simpler because they don’t need to specify how memory is managed across them.

They’ve articulated a key principle of their approach - that they are solving something that is a hard problem, not because it is hard, but because it is hard and useful to the end users (other programmers).  They are faced with a choice of solving that problem once in the language (implementing good, efficient garbage collection), or implementing it myriad times in the programs written with this language (a la C and C++).  Hard problems that have a lot of re-use and benefit are worth solving.

If we look at a good BPMS, it serves some of the same function – handling parallelism, memory management, and other key software architecture concerns for the business process author – in order to allow the author to focus more clearly on solving the business problem. BPMS offerings largely have a lot of room to improve on all these fronts – but they’re still the best thing we have for a “language” that fits the “problem” (despite rules vendors’ claims to the contrary).

I’m often faced with a problem that lends itself to being solved once, well – or many times, poorly.  And often the software engineers of our world tell me “yes, but that’s hard, and not on the road map.”  A great example of this is date calculations that transparently do things like comparing, navigating timezones, calculating differences, navigating business days (and calendars), etc.  A better example is robust versioning for complex assets like business process models which include all the implementation details.

Other “features” that caught my eye in Go:

• No generic types.  No exceptions.  They admit they don’t have a good solution yet, so they don’t slap a band-aid on it.  Try not to write code that breaks.
• No type inheritance.  A type is more like an “interface” – where any object that implements the methods the type requires are, by definition, “of that type”.  This reminds me a bit of protocols in objective-C, but without the necessity of pre-defining the relationships (technically, you can define and compile-and-link later in objective-C but that’s another story).
• No overloading.  Never in the history of software engineering has a more useless and anti-performant feature been introduced at a language level.  Nice to see another language that forgoes operator overloading.

Of course, this minimalism will be tested with time – especially if the audience of Go users expands – or if the language is handed over to a standards body full of people who really have it as an interest to keep tweaking the language (a la Java and C++) – over time making it increasingly complicated.

In the meantime, I’m just happy to be pleasantly surprised that this supposed prank has some decent substance.  Did Google really need to design a new language to handle concurrency and other large-scale problems well?  I can’t say for sure, but at least once going down that road they’ve made some promising early design decisions: focusing on the key, differentiated problems their solving, and postponing or not solving areas that are not directly related.

If you haven’t used the site, hunch, you might want to give it a look.  Its pretty interesting, as it attempts to crowdsource decisions.  Hunch also does a pretty good job of anticipating your answers to questions based on your previous answers to questions.

Recently Chris Dixon made available a blog widget which can help you understand your readership demographics a bit better (assuming the readers participate!).  I thought I’d give it a try…

Of course, I see some interesting possibilities for crowdsourcing vendor selection (BPM vendors), or philosophical debates like BPM vs. Business Rules. So I seeded a starting point, that is on Hunch now.  I need to finish adding vendors to it, and I need help from others to add more results, train the results, and add more questions!  (Anyone can login and add questions and results so please contribute! If we get enough contributions and training in, then this decision tree may have statistical significance )

Here’s the link to the BPMS decision helper…

Search CIO posted a good podcast about two weeks ago on the topic of selecting BPM tools / vendors, interviewing Mike Kravis.  There were a couple points I wanted to pull out from the transcript and expand on:

• Mr. Kravis says the first step is to determine the requirements, which of course is true. But the real trick is to make sure that the requirements actually make sense.  Often requirements are proposed that are actually designed to make it hard for any vendor to succeed – this can happen when the Business or IT want to keep using the tool they have, or are worried about job security or skills.  Just make sure that the requirements are related to increasing business value or decreasing implementation cost, and not just Enterprise Architecture decoration or Buzzword Bingo.
• Mr. Kravis points out that when he was choosing vendors previously, they really worried about the pure play vendors being acquired – but in fact it was the big vendors that got acquired while the pure plays stayed independent.  This was a pretty interesting trend a few years ago- several potential customers of pure play vendors were advised by BEA that they were takeover targets… but in fact BEA was the company that was acquired and swallowed up by Oracle.  The pure plays are still out there, and still look like the best options for those still in the buying process.
• Kravis describes a good evaluation process, but it is an expensive process.  If you’re a smaller corporation, you need to push for a faster decision.  My recommendation is to push for a contingent license with a vendor you feel comfortable with, rather than doing extensive evaluations with 3-4 vendors (including onsite demonstrations, etc.).  The on-site demonstrations will help – but it will also drive up your licensing costs because it drives up the cost-of-sale for the vendors (It may not be obvious, but if you make it *easy* for a software vendor to sell you software, they’re likely to be more forgiving on price).

Overall its a good interview, and some good tips.

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.

Appian just announced the launch of Appian 6 (which will be released in a few weeks).  Among the benefits touted are a further refined design interface (aligned with the theme of process acceleration), which appears to offer better re-use of various components within Appian:

New BPM Application Design interface, allowing customers to quickly navigate all shared components and form these components into logical BPM Applications for simple management and quick migration between environments.  The re-usable library of components includes Processes, Rules, Groups and Roles, Reports, Content Management Structures, Documents, Portal Pages and Collaboration Areas.

From what’s described in the release, it isn’t clear how this feature set compares to other BPM offerings, but at least on paper, this functionality would bring Appian 6 up to par with best-of-breed BPM Software.  Of course, the devil is in the details, and would reveal whether their implementation of the new design environment is more or less productive than another environment (which is why we recommend customers actually try to build something and lay hands on the tools they are buying).

Next, it looks like Appian is extending the XML definition of the process to include all the artifacts defined by the design environment, rather than “just process and rules”.  This allows for versioning the XML in source control tools, and makes it easier to migrate the process definitions without losing assets.  However, I have to say that I would have expected Appian to support this well before version 6, and this is a feature that at least some other vendors have supported since circa 2003.  Still I’d rather have it than not, and hopefully it is a stepping stone to additional functionality for import/export in the future (BPMN2? XPDL 2.1? native support for a version control system?).

The new user interface approach sounds (to me) like an improvement over the old, as well as something possibly differentiating to quite a few other vendors’ offerings – including the ability for particular “process applications” to have good meaningful URLs.  This is a seemingly simple innovation but it can be *important* for adoption of BPM in an organization.

We’ll have to check out the beta and/or general availability release and see how some of these features manifest in the coming weeks, as time allows (or, perhaps someone else will do it for us and we can read their review instead!). I’m also curious what, if any, impact Appian 6 has on Appian Anywhere, their SaaS solution – is Appian Anywhere moving to Appian 6, or have they split the codebase?  Or is Appian 6 incorporating improvements introduced into Appian Anywhere?

There’s more information in a release from MWD, a pretty reliable source of information in the BPM market.  The main point of emphasis in MWD’s report is that the product release is focused on bringing together the methodology and the technology to deliver BPM applications more easily – which I think is one of the real strengths of a good BPMS.

I’m tired of waiting. I think I’ve been spoiled by the pace of Web 2.0 and I’m no longer patient for each major release of enterprise software.

In a world where we can receive application updates to SaaS applications daily, weekly, quarterly, I’m tired of waiting for enterprise software to release major upgrades every few years.  In particular, BPM vendors, of all enterprise software companies, should know that continuous improvement is a better method than the big-bang release.  They should be embracing incremental improvement techniques, just as their customers should when deploying BPM solutions.  Why do they talk the talk and fail to walk the walk?

Every BPM vendor (every software vendor!) should read Steve Blank’s Manifesto for Customer Development. Steve Blank and Eric Ries writings should be mandatory for software developers in the BPM business.  Heck, their articles should be mandatory reading for people deploying BPM software as well.  The traditional “product development” model consists of four phases:

1. Concept / Business Plan
2. Product Development
3. Alpha/Beta Test
4. Launch / 1st Ship

And Steve Blank rips the heart out of this process:

The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.

So.  Off to a good start.  So what are the problems?

1. Focusing on a finished product instead of minimum feature set.  Lots of resources are going to be wasted on features that won’t matter to customers.  Those resources won’t then be available to invest on features that DO matter to customers.  Guess what?  Software vendors have finite resources.   These prioritization decisions matter.
2. Founders or Executives hand-off responsibility for validating the vision.  Marketing and Product Management now own that, and Sales.  The founders and executives aren’t hearing directly from customers which features are buying criteria.  Founders and top execs need to hear customer feedback in order to know when the ship needs to be righted.
3. Engineering becomes so focused on their ship date execution plan, they become immune to outside input, or changing the plan, except to move the ship date further out, or cut features.

In another article, this time on GigaOm, Mike Speiser argues for the power of Continuous Improvement.  Well, he’s preaching to the choir with me, because as a BPM practitioner I’ve been advocating continuous improvement for most of a decade.  Mike argues that often the reason people (and businesses) languish at a mediocre level of performance is simple:  they lack a good feedback loop.  Without timely feedback, they can’t tell if their actions will produce exceptional, average, or mediocre results.  The learning cycle is too long to take hold.

A fantastic example of what can go wrong in a big organization:

Let’s say you’re a mid-level executive — a GM or product manager of some sort. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers. And so does your boss, and her boss, and so on and so on. Here the only thing that you’re practicing and perfecting are your brown-nosing skills. How can you expect to learn in an organization with that type of feedback and incentive system? How can such an organization, by extension, possibly produce excellence?

The most telling quote of all:

The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.

Its worth reading that one twice.  Three times.  Now.  If you’re a BPM vendor, and you have an enterprise version of your product, ask yourself if this statement applies to you, your team, your product, your organization.  You may be saying to me right now- but we’re on version 5, version 6, 7, version 10, of our BPMS – so clearly we believe the gospel of continuous improvement.  But I say to you, how long was the development effort that led to this latest version?  Why was it more than 3 months?  Why is there a “major version” at all rather than a series of incremental improvements that migrate customers from old to new?

Many of the BPMS vendors are now providing SaaS or ASP oriented BPM solutions – at least for modeling and collaboration, if not for execution.  These solutions seem to get revisioned on a frequent and substantial basis, much like the majority of web applications and “Web 2.0″ out there.  I would now like to challenge the assumption (presumption) that Enterprise software can not be similarly improved.

What’s wrong with the traditional product development model for BPMS vendors (my observations):

1. There are large sets of features that languish without improvement for many years.  A mediocre feature was introduced in 2005, it was never revisited, except, perhaps once to fix a bug in 2006.  This “feature” might be something really important to customers:  reporting, versioning, integration with salesforce, etc.  But for whatever reason it never rises to the level of interesting for Product Management, or it gets cut in the interest of making the almighty ship date.
2. There are large swaths of potential features that never get addressed, because the product development team imagines it knows what is going to sell when the shiny new release is finally released.  So, that PDF export you wish you had in product continues to be something professional services had to provide.  That import from Visio the customer wants isn’t available in your otherwise superior product, and the customer goes with another product that does this out of the box.
3. Low priority defects never get fixed.  Why fix them, when the “new release” is coming.  Wait for the new release, then consider fixing these minor things on the new release.  The problem is, the new release will introduce its own set of important issues to fix, it will take time to confirm the minor issues are still issues on the major release, and by the time those minor issues are back on the table again, the answer from engineering will be: this is too low-priority as you’re on the old release – we have a new release coming that will be the one to fix this on.  So, you spend more time waiting for the Next New Thing than you do actually treating it like the tip of your product line.

If your major versions take more than 1 year to ship, you’re doing something wrong.  And that may be generous.  How do I know that?  Apple ships new versions of an operating system every 12-18 months.  That’s a much more daunting task than a new BPMS.  Much larger installed base.  So why does it work?

1. You have to make the investment in automated update mechanisms that work. Think Windows Update, Mac Update, etc.  These programs work.  The changes they propagate have to be *contained* and backward compatible.  But they work. It puts constraints on the engineering team – but they are *good* constraints that these teams ought to operate under anyway.
2. You have to compartmentalize your updates into components or units that can be upgraded without breaking everything else.  Think Apple replacing their legacy development framework with Cocoa – something that they did gradually over the last 10 years, piece by piece.
3. Independent components imply that you have to have good API’s.  If you don’t have API’s defined between the internals of your product that you feel comfortable documenting and publishing internally and to partners, then you should develop and implement such API’s as part of every revision to your product.  API’s provide the lubrication that allows for change in your product without putting unaffected parts of the product at risk.
4. You have to respect data formats.  The data is sacred and hast to be protected.  See #3 – without APIs protecting your data, you won’t be able to change the schema without breaking upstream services.  And you won’t be able to change upstream services without breaking your data.
5. You have to believe in the evolutionary/incremental over the revolutionary.  If developers think they can depart from the past without respecting it, you will get incompatible software and unhappy customers.
6. You have to allow for individual accountability for product.  If people don’t “own” something, they won’t have the appropriate baked-in incentives for improving it. My favorite question to find out if a company is serious about a feature set, is to ask who owns it – who’s your lead developer for this part of the product?  What are their other responsibilities?  How long have they owned it?  Can I talk to them about what they’re working on now and why?  I want to understand their thought process.

I see enterprise BPM vendors talking the talk about continuous improvement.  But I don’t see them walking the walk in their enterprise software offerings.

A quick recap of the stack vendor vs. pure play debate:

Round I occurred primarily on the ebizQ BPM In Action blog moderated by Dennis Byron, in the following posts:

• Appian/Why Not BPM?
• Pure Play vs. Stack Vendor
• Do Stack Vendors Stifle Innovation?
• How Do Stack Vendors Price BPM Software?

I think Round I essentially ended with Dennis and I agreeing to disagree – but I think the majority of comments that got past moderation supported my view.  He asked me for specific examples of stack vendors engaging in this behavior of giving away BPM while charging for, say, Websphere – before he would believe my assertion that stack vendors will give away a component against a pureplay vendor to win a deal (not just in BPM, but in any space).  Well, unfortunately any information I have along those lines is not something I’m able to disclose except in the most general way, which wouldn’t fit his definition for specific data point.

Round II is captured best in two blog posts on the BP3 blog – (and I welcome comments on our site, as they are only moderated after the fact – your comments will show up right away, and you’re only subject to moderation if they are viewed to be spam by askimet).

First, there was Stack Vendors vs. Pure Plays, and then there was a followup about Oracle’s acquisition of SUN.  In the latter post I focused on why stack vendors don’t have enough focus to really innovate… In the former post, I focused more on the overall debate:

[...] if a vendor is giving a piece of software away, you should be suspicious- anything a vendor is giving away for free (or nearly so) isn’t likely to get a lot of investment of R&D dollars going forward.  Software companies tend to invest where they see a competitive edge, and they tend to discount and under-invest where they don’t.  It isn’t irrational behavior, and it isn’t a question of good/bad or good/evil – its just the trade-off of stack versus pure play.

For some reason, others doubt these basic laws of Software physics, but I don’t.  As you can imagine, I was quite pleased to be vindicated at least partly by a recent post from Phil Gilbert, President of Lombardi, entitled with the usual flair:  “Flash: Free IBM BPMS Worth Exactly What it Costs” (for the humor impaired, he’s saying it is worth exactly the zero dollars it costs to buy it… ).  Phil rips IBM pretty good in his post, and I couldn’t resist quoting him…

So, here it is, quoted for you Dennis:

Today one of our customers said they were told by IBM: “why spend your money with Lombardi, we’ll give you our BPMS for free.” I finally agree 100% with IBM on something: their BPMS is worth nothing. Getting a cheap BPMS is like buying a dancing elephant for a dollar: cool, but who can afford to feed it?

I particularly like the dancing elephant line… but for Dennis Byron, I think you have your specific example.  Let’s take that elephant line again though.  Right, someone has to feed the elephant.  This isn’t just you, the customer.  Yes, Phil argues that the customer will have greater development and maintenance costs, and fewer process benefits, using IBM’s BPMS than by using, say, Lombardi’s.  But it is also about IBM.  How will they afford to pay their development staff on their BPMS if they are giving it away?  Someone has to be paying for software in order for IBM to maintain their development team – they have to feed the elephant.  If they can’t explain how many developers they have, how much that costs, and how their zero price solution will pay for those developers, you have to wonder how long Big Blue will keep making that investment, no? This same logic applies to smaller stack vendors, only moreso – they don’t have the financial resources of an IBM.

How else to Stack vendors use undue leverage to get a sale in a software category they aren’t really any good at:

But this notion of getting “free” or highly-discounted software from strategic vendors has currency. How many times has your company picked up some crap from some vendor because it’s on a discount schedule and you have to buy x amount of software each year to “maintain your discount.” So let’s discuss the cost of software, and the value of software.

Yep, that’s right.  They get you to buy into the notion of “maintaining your discount.”  Wow.  I sure hope my local car mechanic never learns that trick.

I have another example.  The McDonald’s near my office started giving away McCafe drinks earlier this year – to get people to try them.  I tried my free McCafe – and it was so bad I went screaming back to Starbucks.  The difference between a McDonald’s and Stack Vendors is that at McDonald’s their food/drinks have to be good enough to get my return business – I tasted the drink, and rejected the free value proposition.  At a big Stack vendor, they’re hoping you don’t actually “drink” that free drink – they just want to book the revenue, prevent a “competitor” from getting a toehold in their turf, and help you “maintain your discount.” If you don’t taste the software, you may never know you’ve been had.

As long as IBM is giving BPM away for free, maybe its time to ask why Websphere isn’t free… after all, JBoss is… Maybe they can explain why Websphere is worth some coin and JBoss isn’t?  And then maybe you can ask IBM why that same logic might not apply to the BPM space?

Phil, thanks for re-opening the subject and thanks for a very entertaining read!

Quick update: from a more recent Dennis Byron post on Open Source vs. Licensed Software:

The IBM-sponsored speaker is Matthew Brown of Forrester and the subject is portals rather than BPM but the findings and the underlying thought process can be applied to any project. The message is simple: open source Ts&Cs are like any other license Ts&Cs. And license Ts&Cs are only a small fraction of your IT project costs whether it be for BPM or anything else. And sometimes open source Ts&Cs can dramatically increase the rest of the IT project costs. To the caution of “pay me now or pay me later,” add the caution “what I give you with one hand, I take away with the other.”

Let me put this in context… IBM came to this conclusion:  License costs are a small fraction of your IT project costs.  Apply this to the debate above – that free BPM software can incur costs that far outweight the licensing costs of the paid BPM software  – whether it is opensource or just free.  And you’re actually more at risk if it is free, but not open source because you can’t modify or improve the source code yourself…

We have all heard about how difficult the banking situation is on folks holding a mortgage who maybe at risk of foreclosure. Last night I happened to catch this segment on ABC News: Nightline.

The more I watched the more irritated I became, and it didn’t even affect me!  Why? Because it is SO unnecessary. This is the result of process failure, pure and simple and has nothing to do with how complex any given mortgage may or may not be.

How do I know this? Because folks couldn’t get to any given department to begin the process of ascertaining complexity! Bank Of America, IndyMAC (now bankrupt), Countrywide, and most others should be embarrassed to no end in their lack of ability to serve their customers. You see, it’s not just mortgages albeit that was the topic of this televised segment, it’s almost any customer interaction anymore that is not a point-of-sale transaction. These companies and most others have spent the lion’s share of their capital in removing friction to capturing revenue, and reduce whatever costs possible to increase the margin. That’s expected by and large, but here’s the rub. They have lost site of the value of a customer and as such have no idea what areas are acceptable to refactor and what areas should be considered competitive, value-added differentiators on the operations side.

Simple enough image, companies for the most part do everything from poor to excellent in just getting their good or service out the door. It’s in that other arrow – “information flow” – that a lot of companies out there do a horrendous job. Requests come back into the organization from a customer and depending on their nature it can be a deal-killer for a customer.

In today’s world, you need quality in delivery AND in information flow to really be a serious, long-term competitor.  That paradigm is increasing in potency and speed a lot quicker than many organizations are able to determine strategies to deal with it. Ask yourself, will the next generation of customers/buyers be as forgiving as we have been in the past decade? I don’t believe they will be, because as time marches on, these next round of customers will have even more choice in who they do business with.  The implicit bet that these banks mentioned above are making is that their customers have no choices in today’s economic environment.  In the short-term that may be true – but it only takes one experience like this to lose a customer for life.  And it only takes handling this customer process really *well* to win a customer for years to come.

Folks, it is about process and even more important than the execution of process is knowing what and which processes matter. Companies have to stop with investing in every link in a chain whereby every link is continuously fed resources (that will not scale, it just burns money) and understand instead where is my WEAKEST link in any given chain; don’t forget the whole point of process improvement. Develop a superior relationship with a customer at the lowest possible cost.  When there are such glaring opportunities to differentiate your business without having to compete on price, one is hard-pressed to find a better investment in terms of ROI.  If you’re not doing process improvement with an eye on the customer then as our new President said, “you are on the wrong side of history”.

I have spent some time exploring this company (Athenium) and I think their approach and solution for Insurers is really interesting. Moreover, even though they have maintained a focus in just a couple of industries it’s not hard to see the potential across the board.

Their software solution is not a BPMS however, the outcome from its utilization is quite similar and the complexity is not nearly as sophisticated as system-to-system, or even human-to-system interactions. If you come from the business or operations side and have an interest in P&C claims processing, litigation management, or sourcing they are worth a look in my opinion. They also have a blog with content written by senior folks coming from these discipline areas; the content is very specific to the nuances of performing particular work.

For those companies out there who are not employing the “ostrich strategy” and are thinking in terms of longer than 12 months, there are some real opportunities which may be worthwhile to consider, outside of just cost reduction or revenue protection objectives. In fact, it would likely be a good time to take a moment and re-discover what your business value drivers really are. Keep in mind that selecting projects or otherwise making decisions with the center of gravity being “reduce cost”, “improve profit” are really only effects; these are not projects in and of themselves. The only way you can ensure you are chasing the right possibilities is by understanding the company’s value-drivers and the “what, which, and how much” of each; find the game changers in essence. Those things which can not only help in the short-term but catapult a company over the long term (+12 months) to be more competitive, more profitable and deliver better to what your customers actually want.

Some of the really potent game changers that you may want to consider pursuing in a downturn would be in designing new processes or products, reducing operational complexity, and certainly doing work to understand what your customer’s (former and current) and your competitors customers are really seeking from your organization.

Designing new processes or products/services in a downturn is a great way to employ your assets and since you likely will have cut in other areas, put your money back to work for the future. Business process management methods and tools can help accelerate time-to-market and just as important validate that you are delivering solutions that will truly matter. Getting something out there fast is good but not if nobody wants it or cares. There is a very prescriptive way to generate these new designs and equally important process-centric tools which will help create a foundation to actually sustain these innovations.

Reduce complexity, not just reduce your workforce. “We just need to do more with less”, for some organizations they seem to believe that the laws of physics can be defied in their conference rooms. The rest of the universe is at the mercy of said laws, but not the organization. If we assume your company is a tad more realistic, then now is absolutely the time to refactor areas of the business.

Here is a great area to look at first: in most businesses there is the notion of sales configuration and there is the back-office functions to support or fulfill those various customer order permutations.  A lot of businesses try to make the back office support functions more efficient (read: “cheaper”) and they do this through automation, consolidation, etc.  As we all know, this is a never ending fight….never ending. One option here is to begin to rationalize those order configurations with the support functions. In almost all cases they are decoupled from one another and that is a problem. Until that notion is embraced, you’ll just be bailing water forever. Again, now is the time to use resources to see what can be done to harmonize these functions, this will promote process flow; and flow is exactly what we need in core processes.

Another area is doing work to get better intelligence in what current, former, and potential customers are really after. Too much of the time reactive data alone  is used to make decisions on what a company needs to improve on or even offer as a good or service. Reactive data is data the company doesn’t seek out. Proactive data is information that the company solicits from its customer and prospect base. If you do not have a solid voice of customer program that addresses aggregation of both reactive and proactive data, strong analysis capability of that data, and the right vehicles to get that information transformed into projects, then again now would definitely be the time to invest.

Any rate, these are a few examples of some game changing initiatives that could really provide a platform for future capability that can be had much cheaper than when the organization is operating at capacity. Think of this as a hedge, once the volume turns up again in the business how fast will you be able to respond, compete, lead? Chances are you have cut deep, and recouping that prior organizational capability is going to lag significantly; longer than the downturn lasted as a certainty.

Sandy has posted a pretty good presentation on mixing rules and process, which pretty well captures how I feel about the subject.  I’ve never understood why the rules-vendors out there try to model the process using rules.  On the flip side, pure BPMS vendors sometimes fall into the trap of feeling they have to claim to have rules engines because the rules folks will try to claim that they have BPM.  I think customers who are interested in both BPM and BR functionality could do themselves a favor by telling vendors up front that they are using separate packages for this functionality – they’re likely to get more candid answers from the sales folks from both companies, as it allows the vendors to play to their respective strengths.

I’ve deployed several projects that integrated a BPM platform with a rules product, and its just easy to do via webservices or an API call in all but the most extreme cases.  Anyway, enough from me, here’s a link to Sandy’s post.

Disclaimer:  I used to work for a company that did a lot of work in the configuration space, which has a pretty big overlap with rules.  We did heuristic search, constraint satisfaction, resource allocation and pooling, spatial constraints, containment, and we even did massive rule systems that were super fast.  Intellectually it was a very interesting field because you take really hard problems (in some cases, problems that you could demonstrate were NP Hard problems) and finding “reasonably optimal” solutions in a very finite amount of time.  As I said, intellectually very stimulating.  In other cases, it was coming up with very creative ways to use simple rule-based systems to compute very user-friendly user-interfaces in millisecond time against very large rule bases.  But one thing I learned for sure: thinking about the world as a set of configuration logic or rules is a different way of thinking, and it just isn’t intended for the average Bear.  This is why I don’t see representing “everything as rules” as being a terribly useful way of approaching the world when it comes to involving your organization in the process of business process management or improvement.  I consider myself a reformed rules guy, and now, tongue-in-cheek, I see everything as a process!

Update: On a (somewhat) related note, a somewhat humorous post from Jim Sinur on how rules might have initiated the real-estate meltdown.

A business unit commissions a solution that involves people, decision points, multiple paths and real-time visibility. Sounds like a business process, right? Sounds like a perfect fit for Business Process Management; more specifically, a BPMN rendering and a BPMS tool to implement and execute the vision.

Some key aspects in this solution are:

• People
• Business Decisions
• Multiple paths sometimes in parallel
• Point to point orchestration
• Metrics

These are all aspects that support and imply a BPM solution.

Now, what if I needed a similar solution, but minus the people? What if I had a batch or back-office solution that did not involve people other than an occasional exception path? What if this batch solution was expected to process thousands of transactions daily? Would this still be a BPM solution or would it be a software program designed specifically for this purpose? I have heard many, even in the BPM field; argue that such a batch solution may not be suited for a BPMS implementation. That BPMS tools are not geared for this type of high-volume fast paced execution required of such a batch oriented solution. However, to that I say why not?

You see, just because “People” are not necessarily involved in activity steps within the process, the process is no less a business artifact than those which do involve people. Now surely I’m not advocating that every program written could otherwise be a BPM solution, but I am saying that many of these so-called batch solutions do indeed involve business decisions, multiple paths, and multiple point-to-point system-to-system communications; all of which require sophisticated orchestration and most certainly should have adequate real-time metrics. These solutions are often augmented and evaluated for efficiency and accuracy just like that of people oriented BPM solutions. Often these batch solutions do need to handle exception paths which may involve people. Should the program kick-out on exception to some other process solution? And if so, how do the solution owners manage the big picture of the process flow? More times than not, these batch solutions must maintain state in some manner. They must be prepared to handle system failures and contingencies. Is this all to be written rigidly into a program somewhere with very little visibility?

I also find that many BPM enthusiasts tout automation as one of the goals of BPM in a march towards efficiency. I agree with that sentiment, but once a process has been improved upon to the point of automation, is it no longer a process? Should it then be re-factored into a compiled program of sorts? I think not; for automation left unattended is a dangerous thing. An automated solution still requires checks and balances, reported metrics, and proof that the efficiency gains expected are realized; and what about improvements, new products that adjust the automation, new regulatory requirements that incur change in the solution? Even when fully automated, the business process still remains in the fore front.

Software programs and compiled, efficient code certainly has its purpose, and after all, these BPMS tools wouldn’t run without it, but when it comes to business visibility, orchestration, state management and multiple touch points; whether people are involved or not, Process Management solutions are quite applicable. And as these program interfaces become more and more modular through an SOA discipline, the orchestration and process management of those modules and services at run-time becomes increasingly important. So I challenge the BPMS vendors to stay focused on the process vision, but don’t stop at Mortgage Apps, Claims Adjudication, and Book Order solutions …… think further, faster, and with greater depth than ever before; I want to manage all my business solutions through a well defined, visible, and deployed process!

Thanks to Sandy’s blog post, I’ve once again been pointed to an interesting post in a blog I didn’t have in my Google reader (I’ve now added it!  thanks again Sandy!), in which Ismael Ghalimi gives unsolicited advice to the BPMS competition out there.  I can sum it up as:  “Use our BPEL engine!”

I want to discuss this theme in three parts:  The Case for Change, The Proposed Solution, The Proposed Benefits.

The Case For Change. The economy is hurting, and logically software vendors selling perpetual licenses will be commensurately hurt by reduced purchasing plans.  It isn’t a bad premise, though I will point out a couple of things.  During a slowdown in the early 90’s, software that had good ROI sold at accelerated rates, while software without large ROI stagnated or didn’t sell at all.  Products that extracted cost from expensive operations enjoyed great success.  On the other hand, during the 2001-2003 slowdown, I saw something else happen.  Instead of buying software to make complex processes and operations more efficient, I saw companies dramatically simplify their processes or products to eliminate the need for software (for example, PC and Server configurations became dramatically simpler, and fewer configurations were offered.  The same thing happened in telecommunications.  Complicated sales processes got streamlined).  I can’t say whether the current economic environment will spur more software sales in BPM or less… I have visibility to the deployment side, and companies that already own BPM are looking to get more ROI out of that software $.  But for those without BPM software, I’m not sure that they can effect the same kinds of rapid ROI that BPM platforms provide, and therefore I’m not sure how many of them will back off of plans to acquire BPMS packages.  Ismael asserts that many of their purchase plans will change.  I’m not so sure. If I look to 2003 and 2004 as examples, IT departments dramatically cut spending in the 4th quarter to preserve earnings for the current year (and yet, it didn’t stop BPMS vendors from selling in those quarters).  In the new year, however, priorities were reassessed and projects that were deemed to have a large probability of a large ROI were started. I can’t say for sure how this year will play out yet for BPMS vendors.

So, I’m not sure I buy the economic argument. But I do buy that replacing proprietary solutions with open source solutions or de facto standard solutions makes sense. Why? well, you focus your engineering efforts on the parts that differentiate you, and you rely on the Open Source community to provide for the plumbing elements.  If you find a bug, you fix it, build it, submit it back to the community, and benefit from gradually increasing quality of the overall solution.  Ismael uses the Database example, but I’d say this analogy isn’t perfect for his purposes, because the “winners” in the database space have been primarily licensed software vendors. A better example for BPMS solutions would be the J2EE stack.  Once upon a time it would have been hard to avoid using Weblogic or Websphere, but JBOSS has become a viable solution, and it doesn’t have additional licensing costs (though, the support contracts are actually quite expensive at present).  And you certainly wouldn’t want to write your own J2EE or LAMP stack for your BPM product – you want to focus on BPM and let someone else solve those interesting platform problems for you.

The Proposed Solution. Ismael proposes embedding (OEMing) Intalio’s BPEL engine in competitor products. In terms of his Blog post, it looks like “BPEL Engine” and process engine are being equated.  However, I think that several of the vendors use something closer tied to the parallel processing notation BPMN, rather than to the XML notation BPEL (there is a brief reference in his post that BPEL’s pi-calculus is better than Petri-nets, but without any supporting data directly in the blog post, since I think that was a bit of a tangent… and certainly doesn’t fit in this post!).  So while they may use a conversion of BPMN to BPEL and then in turn use a BPEL engine, it isn’t necessarily the case (they may, in fact, have a BPMN engine using some other technology).  This introduces some friction for vendors to adopt Intalio’s BPEL engine as a literal replacement for their own processing engines.  Nevertheless, I’m sure some vendors would benefit from getting a BPEL engine embedded even if it isn’t their main processing engine… (and therefore, worth it for Intalio to pursue such agreements where possible)

Looking at his database analogy… This isn’t the same as deciding not to build your own DB and “outsourcing” this technology to Oracle, Sybase, or MySQL… Its actually the equivalent of Oracle deciding to replace their Database Engine with MySQL or PostgreSQL on the grounds that they are cheaper and scalable and times are tough so Oracle could save some money by doing so… but read on for why that may not be their decision…

The Proposed Benefits. No more investment in “stack” technology, pick up a scalable BPEL engine.  The key here is, does the BPEL engine Intalio produces eliminate any competitive advantage or perceived advantage, that the other BPMS vendors have vis-a-vis the competition due to their own respective process engines?  I can’t answer that question for the BPMS vendors, but if we go back to the Oracle analogy, I think Oracle has done quite well (so far) by sticking to their guns and their own DB engine.  There are switching costs that can’t be underestimated too badly – its costly to switch someone from one Database to another… not to mention the monumental task Oracle would have of switching their own software stack to run on an open source database.  Similar friction would exist for the BPMS vendors to switch their process engines out for a BPEL engine.

Conclusion. So, it isn’t that I think this is a bad idea, I just think the bar may be really high, and I’m not (yet) in a position to judge if Intalio passes the bar (or if the other vendor solutions don’t set the bar high enough).  Ismael and Intalio should keep pushing this angle though, with the BPM vendors.  I don’t think any of them will be picking up the phone to call Intalio, as Ismael suggests, but I would suggest he approach them about co-development and OEM agreements.  Having the industry solidify around a common process engine would be a good thing, assuming that process engine is truly superior to all the engines out there today, and might help accelerate adoption of certain standards and innovations.  It would make it easier to expose useful APIs to the developer world (Ismael has some posts about building for developers that are pretty good too), it would make it easier to write solutions that will work across more than one BPMS vendor.  And it would make it easier to push BPMS education down into the college levels at some point.  Still, it looks like a tough hill to climb from here.  Keep fighting the good fight, Ismael.

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.

Like everyone else, I’m reading a lot of press about the economy, and most of it is negative. But in our little bubble of BPM, things are cooking along pretty well. Sure there are ups and downs but the trend-lines are up.

As if to underscore that, we’re starting to see the 1H2008 press releases from BPMS vendors. Lombardi’s is here (not to mention that it was well-covered by Bruce Silver’s blog, Sandy’s Blog, and the BPM in Action blog) and Savvion just released theirs here (if other vendors posted similar announcements I haven’t seen them yet). We’ve also seen some interesting investment news from Appian (a $10M investment round). Lombardi points to some impressive growth, especially regarding the license bookings (85% growth year over year). All indications are that the number could actually accelerate next year since they have seeded a much larger user base with Blueprint (their SaaS process mapping tool)- users that are likely to have positive impressions of the software and that may translate into more buys for the execution software (Teamworks).

Savvion also points out some nice gains- most profitable quarter yet (operating profit). However, in comparison to the Lombardi release it lacks a lot of detail. We don’t know how much profit grew year over year or by how much it exceeds previous profit numbers. And we don’t know how they’re doing on key metrics that might point the path toward growth (license growth, maintenance revenue renewals, consulting $, etc.). Not that either of these companies are required to disclose numbers, as they’re private firms, but the amount of disclosure from Lombardi is clearly greater so far. That speaks volumes about their confidence vis-a-vis the other pure-play vendors which are not putting out the same level of detail. And it puts pressure on the other guys to start putting up the same details. Hopefully with the Metastorm IPO filing, we’ll start getting at least two sets of more complete numbers to look at for trends.

Regardless of the shakeout in BPMS vendors, we believe the BPM segment is growing – the need for Process-oriented services is growing.  And we’re well-equipped to help customers with process-oriented solutions.  However, as an independent consulting firm, we keep our eyes open for this kind of trending data because we want to be playing good defense – we want to be where the ball is likely to go. That’s where the work will be, and that’s where we’ll make our investments. As a consultancy, we’d like to see all of these vendors grow at the kind of rates Lombardi is growing at, but we don’t have the numbers yet to know if Lombardi is typical, or the standout.  I think we have the most experienced Lombardi BPMS implementation team on the planet right now, but that’s another subject, and another post!