Well, it wasn’t that long ago when the pure play BPM acquisitions had us all wondering what would happen to the pace of innovation in our corner of the world where business meets IT on a daily basis.

But besides the big players, Pega, IBM, Progress, Oracle, SAP, Software AG, Fujitsu… and a few of the smaller old guard still competing: Appian, ActiveVos, jBPM, Handysoft, Intalio, Global360, Ultimus, Papyrus, etc.  We also see some new players in and around BPM:

ActionBase – focusing on user defined processes, case management, unpredictable work, etc.

Signavio – BPMN modeler in the cloud, but also partnering to white box their modeler with various other tools (including Activiti)

Serena -

RAVEN – An interesting take on starting business process models with simple sentence structure descriptions.

Activiti – new open source effort, execution-oriented, led by some former jBPM members.  Uses a version of Signavio for modeling.

Process Maker – another opensource/cloud offering.

etc.

And I’m probably missing or even insulting several companies based on my overlooking them in this list off the top of my head (my apologies!).  So, here’s my offer to anyone with an innovative BPM product – send me a link and a quick blurb and I’ll update this post or create a new page in our blog to include that information for posterity.

So what’s the point?  There’s a lot of innovation going on in our space.  The sheer number of products targeted at making modeling processes more accessible is surprising. And then there are new execution engines.  I think because the market is no longer trying to compare every offering to Lombardi or Savvion as the definition of a “BPMS” – some of these other offerings now have an opening to start adding value to companies’ BPM efforts without having to get into a direct comparison across the board- just competing based on their strengths.

Innovation in the BPM market is alive and well.

Anatoly has an excellent post attempting to explain the difference between Design Patterns and Templates:

• Debuts are templates: learn them and use them, chessbooks plot the game 20 moves ahead from the initial position.
• Typical combinations of the middle game are patterns. E.g. fork is a pattern: if you can see an opportuntiy then use it or threaten to do so. Two rooks on the same vertical is a pattern too while two pawns is an antipattern: try to avoid such a position if possible. But no chessbook contains instructions how to make a fork starting from the initial position.

It’s an interesting point in the BPM arena because patterns are more generally useful, but a good-fit template may save you more time on a specific situation. The Template, however, just gives you a head start- it doesn’t advise you for future improvement efforts, whereas good knowledge of patterns can save you time and effort over and over again as you develop processes.

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.  )

Redux Online’s guest blogger Ashish Bhagwat reposted styles of process, distinguished by their attributes… including: Case Management.  Was it posted by Gartner sometime in the last couple months, given all the debate on Case Management?  Nope.  It was posted in 2005.

Recently, we have had few on Case Management and unstructured processes. Those may have been triggered by an acquisition or two, or certain technological developments that made case management easier to achieve ‘technologically’ than earlier. But, most of us know it is not new in terms of problem space, in terms of definition and also in terms of implementation. I have been looking for something to confirm this – Case Management flavor of process management has existed almost all along.

And I stumbled across this picture that described the “styles” of processes in June 2005. I thought I’d share it and remind all of us that problem space has not changed by much!

I find myself in violent agreement.

Jakob Freund of Camunda debunks the notion that BPMN doesn’t work, after detailing a good story about deploying a BPM project with a German manufacturer:

So why do I tell you all this, apart from soliciting our stuff  . It’s just that I have recently read some blog posts, articles etc. about BPMN, following discussions or even (wannabe) “flame wars”, that deny BPMN’s capabilities to serve as an improvement for business-it-communication. But most of those authors do not seem to have any real project experience with BPMN. Well, maybe I am wrong. I just thought I should tell the world that there are enough people out there who do not have any programming skills at all, but use BPMN the way it is meant to be used, and it works.

So BPMN is no silver bullet, and must be improved, I totally agree with that. But it is a step in the right direction that we should benefit from instead of asking for the business-it-silver-bullet that cannot become reality anyway. Sometimes I think we ask for magic solutions and then moan about getting fooled by vendors…

I wholeheartedly agree. Thank you, Jakob, for sharing with us-

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.

This post on the Silicon Alley Insider really impressed me:

Turns out, Apple’s run of incredible products (and growth) has been achieved with a staggeringly low R&D spend. How low? Apple only spent $4.6 billion on R&D over the past four years, while revenues soared from $25 billion to $43 billion.

In contrast, Microsoft spent 700% that amount on R&D during the same period, a whopping $31 billion, while growing at an anemic pace, despite flippant M&A. Likewise Cisco and Intel spent about 400% as much as Apple on R&D – $19 billion and  $23 billion respectively. These are astounding differences above Apple’s research and development spend, especially considering that during this period Apple developed the iPhone and iPad.

In fact it’s rumored that Apple brought the iPhone to market for a mere $150 million, doing so organically without acquisition outside of a touch gesture recognition company named FingerWorks.

That’s pretty incredible.  And it points back to something we’ve posted previously, that while Apple’s design process may look expensive, it is actually more efficient than the alternatives.  Anyone who has spent time in the software business (as I have) knows that a badly designed software feature costs a lot more *after* sale than it does to build.  And well-designed software, which may not only cost next-to-nothing to support, but also may increase sales by creating positive impressions and network effects, doesn’t cost that much more to build.

I read a lot of BPM coverage and commentary.  I also read a lot of software industry news and startup news, and Apple-related commentary, because of my personal interests and because of cross-pollination.  Sometimes a theme will emerge that cuts across these interests and it just jumps off the screen.

Right now, that theme is simplicity. Neil Ward-Dutton touched on it when he mentioned the new focus IBM has on “consumability” in its acquisitions. But lets take a quick diversion to talk about some articles that make the same point.

Television

First, this hilarious post by Mark Cuban: “The Future of TV is… TV” (Now, why didn’t I think of that?!). In a world run amok about streaming video and TV going away, Mark points out:

You know what is AMAZING about VOD  ? It gives you thousands of choices and its already connected to your TV. It just works.

You don’t have to buy another box. You don’t have to figure out how to connect it to your TV. You don’t have to stream from another device over your WIFI netork and get all confused about how to pull video from the internet. It just works.  That’s what you want when you unbox that great big flat screen TV. You want it to work…. like a TV. Easily. Quickly.

That isn’t to say money won’t be made streaming video.  But TV isn’t going away – and people aren’t shelling out for new HDTVs for nothing.  Interestingly, Mark has a followup on this article because of the Google TV news – and his answer for the future of TV is still… TV (however, he sounded like he liked the Google offering as announced).

Twitter

Not long ago, SAI covered Twitter’s announcement of a new product called “Blackbird Pie“, a product for “embeddable tweets”. I guess the idea was that you could quote someone more reliably.  But it is something like a 7 step process – and one of those steps is to go to this twitter url and paste in the URL of a tweet that you want to embed/quote.  Of course, most people use twitter clients, so they’re not looking at a tweet URL to begin with.  What people typically do is just quote someone.  Or if they really want to get clever, take a screenshot of the tweet so that the wording isn’t as likely to be questioned.  Simple.  For a service that prides itself on “simplicity”, it isn’t clear that Twitter still realized how crucial simplicity is to its service when they roll out unnecessarily complicated features like this. Worse yet, according to SAI:

Besides being WAY too complicated, here’s what else is wrong with Blackbird Pie.

• Twitter justified its existence by saying that it would prevent people from being misquoted. Problem is, it’s very easy to manipulate Blackbird Pie code to misquote its source.
• If tweets are supposed to be embeddable, THEY SHOULD ALL HAVE AN EMBED BUTTON JUST LIKE YOUTUBE VIDEOS, EGAD.
• There’s no easy way to customize the code Blackbird Pie pumps out. What if you want the tweet to be 640 pixels wide?
• We tried using the embeddable tweets. Didn’t work. Didn’t work on TechCrunch either (see below).
• Blackbird Pie has already crashed.

That criticism stings because it reminds us of other false starts from Twitter.  The article goes on to skewer the @anywhere feature as well, and the fact that it co-opted the “Retweet” but didn’t implement it the same way… and yet decided to use the same name (adding to the confusion).  Not content to be a simple status and notification service with a lightweight footprint, Twitter is overcomplicating things as it tries to extend its control.

Apple

Meanwhile, in Cupertino, Apple puts out a product that simultaneously elicits rave reviews and dismissals.  It is so easy to focus on what it doesn’t do. Amy of the “Cheerful Software Manifesto” has a wonderful way of putting this, I just had to quote it verbatim:

The iPad, though, unlike the Newton, is going to win, and win on an epic scale.

Nevertheless, the shortsightedness of punditry is evergreen. Instead of praising the iPad, critics express their disappointment, because they expected more. They expected a genre buster. They expected something they’d never seen before, something beyond their imagination. Something revolutionary.

They’re disappointed that the iPad is so… well… unsurprising.

Therein, of course, lies the genius.

THE IPAD IS BARELY A SURPRISE AT ALL
The design, delivery, and timing of the iPad couldn’t be more different than the Newton. The iPad wasn’t a surprise at all. It’s the capstone in a family of devices.

There’s a cozy, pre-existing slot in people’s brains that the iPad fills quite nicely.

“Oh,” they say. “It’s a big iPhone.”

It doesn’t matter if they utter that phrase in distaste. That little sand grain of dismissal becomes the core around which will form a pearl of understanding.

“Trying to deal with email on the iPhone is tough. The screen’s too small.”

“I wish we could both work on this at the same time.”

“I’d like to sketch concepts with touch, but I keep running off the borders.”

Ding ding ding.

(The emphasis was hers)

Her point: rather than change everything, or revolutionize (as the Newton attempted to do), we need to prepare the ground, and build on what went before.  The iPhone has laid the groundwork for the App Store, and the developer community, which in turn prepared us for the advent of the iPad.  Jon Gruber takes this point further with “This is how Apple Rolls“:

Next, consider the iPod. It debuted in the fall of 2001 as a Mac-only, FireWire-only $399 digital audio player with a tiny black-and-white display and 5 GB hard disk. The iTunes Store didn’t exist until April 2003. The Windows version of iTunes didn’t appear until October 2003—two years after the iPod debuted! Two years before it truly supported Windows! Think about that. If Apple released an iPod today that sold only as many units as the iPod sold in 2002, that product would be considered an enormous flop.

Today you can get an iPod nano for $179 that’s a fraction of the original iPod’s size and weight, with double the storage, a color display, video playback, and a built-in video camera. Apple took the iPod from there to here one step at a time. Every year Apple has announced updated iPods in the fall, and every year the media has weighed in with a collective yawn.

There’s never been one iteration of the click-wheel iPod platform that has completely blown away the previous one, and even the original model was derided by many critics as unimpressive.

The same thought process applies to Mac OS X, and (so far) to the iPhone… and likely it will apply to the iPad.  Where each year (or so) a significant improvement will be made to the platform, but perhaps never blowing us away as compared to the previous version.  But comparing versions across 2-3 years, we’ll see improvements across the board.  A big part of this is starting as simple as possible.

There’s a simplicity to the Apple ecosystem and products that really makes it easier to engage with their products as users.

Business Process Management (BPM)

Mike Gammage talks about “Cracking Complexity” – and how BPM creates strategic value:

Institutional complexity stems from strategic choices about organizational and operating systems. It’s a consequence of the number of nodes and interactions within an organization. It’s about geographies, customer segments, business units, products, regulatory jurisdictions and manufacturing locations.

Individual complexity is defined by McKinsey as “how hard it is to get things done”. It’s the complexity that the vast majority of employees face – typically due to poor processes, confusing roles, or unclear accountability.

Apparently most execs focus on institutional complexity, but individual complexity can really impact the bottom line (negatively).  If individuals can get their job done more easily, and more importantly have visibility as to how to get their job done, then you’ve really increased your organization’s efficiency.  As Mike puts it: “There are jaw-dropping hidden costs arising from confusion in roles and accountability across end-to-end processes. And similarly enormous costs of IT failure where IT and the business are not speaking the same language. ”

If BPM is defined correctly, then it’s a C-Level issue. BPM is not about new ways to automate, it’s a far broader canvas. Process excellence goes way beyond just standardising and automating. BPM is about the management, adoption and continual improvement of every process, whether automated or not. And it’s about wrapping in compliance, risks and controls so that it becomes possible to manage the business in 3D.

Framed in this way, BPM is the key to reducing individual complexity – “making it easy to get things done” – whatever the level of institutional complexity.

So, if BPM is about simplifying the individual’s experience of the business – managing for the complexity inherent in any large organization, rather than just trying to oversimplify – then what is, exactly, the role or mission of the BPM software vendor?

Phil Gilbert commented on one of our posts recently:

The shame in all this is that what gets lost in all this scope creep is the original goal, the original promise: BPM technologies should focus on reducing the technical barriers to the definition, creation and maintenance of business information. Instead, we seem to be paying for the Original Sin of BPM which was to focus on BPEL (or BPML before it) as anything to do with any of this. We defined BPM properly, then the industry and some of its early proponents corrupted the delivery.

[...] The beauty of BPM, though, is that it’s about HOW existing technical capabilities can be exposed to a broader audience, an audience more directly connected to the business outcomes than ever before.

Phil goes on with a very good example, versioning… something that literally everyone can do.

“HOW do you version artifacts in a way that’s easy for less technical people to understand?”. Versioning is something everyone can do… so the interesting question isn’t “do you allow versioning” but, rather, HOW do you expose this core capability so that it is accessible to a broader audience and can scale technically.

And the how is important because, as Phil points out, it translates into lower costs and better outcomes.  And honestly, it makes it more likely that you can envision those outcomes in the first place if the how is well thought out – and simple.

It is why installation should be easy, and why we shouldn’t have to hunt for myriad third party libraries and their appropriate hotfixes and fixpacks.  It is why the “checkbox” method of software evaluation doesn’t really cut it (at the very least, use a 1-10 or 1,3,9 scoring methodology so that you can weight things that really *work* versus things that barely get a nod from analysts – but better yet, really understand the depth of the product).

Some argue that BPM is too complex, and therefore shouldn’t be used. For some this is a theoretical argument, but for others they are putting their money where their mouth is and building product that starts with a simple core.  But that is the long road to building out a BPMS.  However, not all vendors are making their BPM offering more complex – as Phil points out above, they’re working hard to make previously complex issues, like versioning, transparent to the user.  It is also why cloud computing will be come increasingly relevant – simplifying (to the user) the task of allocating computing and networking resources to applications.  This is the real magic of software development done right – making previously complicated activities more accessible.

Software companies, and in particular BPM vendors, need to continue to invest in the deep thinking and deep investments to create tools that simplify complicated work; and they need to realize that this is an iterative process – we don’t need the whole thing on a platter 5 years from now – a little progress every year would be great.  Similarly, BPM practitioners need to really think through the processes they build for their participants- providing advanced functionality in a highly consumable package is what BPM is all about.

A conversation with a friend went something like this:

Friend: When are your HR folks going to act on “Descriptions will be added soon”

Me:  Oh, actually, I think *I’m* the HR person that needs to update the descriptions.

Friend: in that case, when will u describe the role of a process improvement consultant?

Me: Good question. I wonder if we should describe it on our site or leave it a mystery.

I mean it.  Should we really explain what we want?  If I describe it all would anyone sign up for it? Am I giving away the secret sauce?  Maybe its better to leave it open ended and just describe it as it is: a person with the objective of improving processes.  We then veered into a discussion of roles.  Some of the analysts have proposed roles like the new business process analyst or the roleplay actor.

But there’s too much discussion of new jobs and roles to hire for.  We should be focused on developing our people.  Focused on skill, capability, and competency.  Ideally, all three in one person.  Too much focus on a specialist for every niche, rather than on investing  in creating exceptional multi-disciplinary team members.

And we got to talking about “generational differences”.  If you’re to believe the majority of media coverage, all the “millenials” are using twitter and social networking sites like crazy, running circles around their elders.  I really detest this sort of generational stereotyping, because it strikes me as intellectually lazy, prejudicial, and smacks a bit of endorsed age-ism (As an aside, I just listened to a podcast on Millenials from Forrester that quite literally made me cringe.  Mere words can’t describe it).  It also misses some interesting points:  the real professional value of all these networking tools is for people aged 30+, or more precisely, people with some work history in their chosen profession who have had time to make meaningful connections with colleagues from say, the last 3 jobs.  Quite a few of my 20-something friends don’t use Twitter and don’t see the point.  But nearly every business owner I know uses Twitter (most of those business owners are too old to be “Millenials”).

A couple of posts from Alfresco personnel about the launch of Activiti hit the wires over the last day or two.

First, John Newton explains why Alfresco was interested in getting involved in the Activiti project:

Activiti emerged from our desire to have an Apache-licensed BPM engine. Although we were quite happy with the jBPM engine, it’s LGPL license was preventing us from OEM’s Alfresco to larger software companies that were concerned about any open source license with the letter G in it. It’s irrelevant that they shouldn’t be concerned about it, we intended to take care of it. It’s understandable that RedHat did not want to change its license, but our business needs dictated that we needed to find an alternative.

[...]

By answering these questions, Activiti is addressing the requirements of business process management for new applications. The Activiti engine as small as a few classes that are embedded in your application or as big as an internet and consumer scale engagement server. Applications that wouldn’t have even considered a large scale, stand alone workflow server because of cost and complexity will now be able to freely embed a business process engine. However, new Cloud applications

So, there was a belief that ECM software needs good workflow, a licensing concern, and an interest in an embeddable engine that scales from smallest to largest installations.  Not a bad business case for someone in the business of opensource ECM.

On another note, Joram Barrez writes an article that captures links to many of the news stories and blogs that covered the launch of Activiti. I was even mentioned in the flurry of responses.  I’ll top my quote just slightly – I was not the only person on my team who downloaded, installed, and played with the demo setup.  I guess it isn’t usual for people to install the product they’re writing about … usually you need a license! And I’m very partial to BPM engines that are written in Java to natively support Mac (or Linux).  (as an aside, I hope IBM / Lombardi will support Mac/Linux fully as well (there are no real technical issues preventing it)).

Max often writes provocatively, and this one is no exception. I think if one reads his work and takes the big ideas without getting hung up on a few of the specifics that might cause debate, there’s a lot to take away and internalize.

As an aside, I find it interesting how often BPM is characterized as being a rigid Tayloristic approach to business – but this is never how we approached BPM at BP3, so I have a hard time relating to this point of view – it sort of assumes that we can’t learn from Taylor and Drucker (and others) at the same time, and benefit from more than one process improvement theology. If I can sum up the criticisms (not from Max’s post, I’m borrowing from many discussions on blogs):

1. BPM is rigid, like a Taylor management-by-science-gone-bad approach.
2. BPM can’t be about managing to objectives, like Drucker would suggest
3. Knowledge workers can’t be managed by a process, or by BPM
4. Creative processes can’t be managed by a process, or by BPM

Of course, those of us who do BPM “right” look at it a bit differently:

1. BPM is about adapting to the change that is happening in and around your business.  It is scientific in that it puts value on real data, but it does not believe in replacing human judgment and decision making and subjective valuations. It is not about automating people out of the process – it is about putting the right information in front of them at the right time so that they can do their job more effectively, and make good decisions.
2. BPM can be about whatever you decide to focus on – managing to objectives or managing a prescribed process – much depends upon the kind of work you’re tackling.  Clearly, handling financial transactions there really shouldn’t be a lot of variance in executing account transfers. But deciding how to handle a customer complaint may leave a lot of room for judgment.  And deciding what the objectives are for a line of business is a process that has much wider latitude.
3. Knowledge workers interact with processes all the time.  If the process is to support knowledge work, it has to be quite different from one that is quite constrained and repetitive – but that isn’t the same thing as saying it can’t be done.  ACM proponents prefer to talk about this as a separate discipline than BPM – which may leverage the same software tools.  That’s fine – but the point is, there are software tools that market themselves as BPMS packages that *do* support knowledge work, and there are BPM professionals (like BP3) who build and support knowledge worker processes day-in and day-out.
4. Creative efforts can absolutely be managed by process.  If anyone thinks Einstein and Edison didn’t have a process to guide their efforts, they haven’t studied these two.  Genentech and Apple both have repeatable processes to guide their innovation and creative efforts.  Do they use a BPMS? Likely not, but I don’t despair about that because the penetration of BPMS packages into the market is still small relative to the potential market size, and just because someone doesn’t use a tool doesn’t mean it can’t be useful to that purpose.

Lest it look like I am writing the above as a disagreement with Max, I don’t believe that’s the case – I just want to set the background for some of the general points made against BPM, and my feelings about those points.  Here are some great points from Max that I think a lot of people could learn from:

There are BPM proponents who say that using structured process should be seen as applying experience. I disagree, because a rigid procedure that may have worked in the past is not goal oriented. Experience is something one gains as a person and is not something one can copy. Applying experience happens by people at each singular activity towards the goal. Experience won’t get encoded into process flowcharts during analysis.

Very true.  BPM proponents *should* be applying experience to their work, but that does not mean that a well-built structured process replaces experience.  Max’s points illustrate why it is so important to have experience in general, and specifically with BPM deployments, in order to understand these finer points.

The higher you go in the management hierarchy, the less predefined processes you will find, need and be able to work with. Otherwise, why would one need management and executives? That’s why I am opposed to best practices that are no more than an average of past approaches now being applied to a specific situation without being sure of its applicability.

Again, great points.  Part of the reason processes higher in the organization don’t get defined as well as because there isn’t economy of scale at that level.  But at organizations like GE, they have very evolved processes around developing their executive management team and the bench for each role.  So processes that *do* have scale continue to get process attention. And yet, the decisions made about each of these individuals involve subjective as well as objective data.

The complexity of current information technology leads consultants and analysts to propose that IT has to be rigidly managed as a business resource only and is ideally outsourced or ‘cloudsourced’. This approach certainly kills inhouse innovation.

This reminds me of how some organizations react to complexity by enforcing rigid gateways between project approval, requirements, design, development, testing, and user acceptance… Instead of adopting an agile development approach.

I propose that if executives chose to manage by orthodox (BPM) process management, they chose to ignore the knowledge between the ears of the people that count — their employees and customers!

Executives and management at all levels have to value the knowledge and experience of the people in their businesses – and use software to help them, rather than hinder them.  Thanks to Max for another really interesting read in the BPM/ACM/Adaptive Process discussion.

With all the hubbub about Activity, I have to admit I found Mark Little’s post about jBPM underwhelming.  After four rambling paragraphs about the historical ties between jBPM and the rest of jBoss (much like the pre-amble you hear right before someone says “…buttttttt…..” ), Mark finally gets to the point.  By this time, I was waiting for the axe to fall.

But of course things don’t always run according to plan and 6 years after joining, Tom decided to leave for pastures new. That left us with a new jBPM lead, Alejandro, who has been a skilled engineer working on the project for many years. It also coincided with the release of SOA-P 5.0 and a need to continue the workflow rethink that had been going on for quite a while. Naturally the departure of any project lead may cause worries in the community and with customers, but where jBPM is concerned they are unfounded: jBPM has been core to all of our BPM and SOA efforts for years and that will remain the case, whoever is the project lead.

Oh wait. That wasn’t the point yet. Ah, here it is, two paragraphs later:

However, it seems that there remain concerns around jBPM 4. Will it be productized? Will it be supported (really the same as the first question)? Will we put any engineering effort into it? It is fair to say that there was expectation that jBPM 4 would appear in a version of the SOA Platform as a replacement for jBPM 3. With the changes to the jBPM project team and the next steps in unifying our efforts in this area across projects, it is not going to happen.

Mark reassures the jBPM faithful that they will continue to invest in jBPM 4 and release new versions.  But RedHat isn’t going to offer paid support for it, and yet they don’t have a plan for jBPM 5 yet.  There’s a pretty tough thread on the discussion forums. You can’t help but feel for people who’ve advocated for jBPM4 who now feel abandoned because they or their customers cannot purchase jBPM4 support contracts.

I think the interesting part is that Mark doesn’t seem to understand what all the fuss is about.  The comment thread on his blog is an interesting read. Mark’s first response to a very tough criticism (from Mark Roy) of the handling of the transition is:

Mark, I’m surprised and disappointed that you feel that this transition has been handled poorly. The team needed to think things through before making many public statements and that’s the right thing to do. I don’t think the community or our customers would thank us for making rash statements that we then retracted only a few days later. And let’s be clear: it’s only been 3 weeks since Tom left and in the software business that’s hardly an eternity. [...]

Well, I think that the open source community expects to be involved in the discussions. They feel an ownership of the project, because they’ve invested in it. They want to be able to make their case *before* a final decision has been made behind closed doors, not after.  Managing communities (open source or otherwise) is tough.  Mark and his team have their work cut out to rebuild trust in the jBPM community.  I’m not an expert on the jBPM community or the politics within open source communities in general, but I thought this kind of support angst only happened with commercial software!

Well, I gave Bruce a hard time in our blog recently, and of course I should expect that if I do that, a fellow blogger and BPM guru like Bruce will return the favor!

Bruce writes an excellent follow-up piece with his recommendations to IBM vis-a-vis BPM. I can hardly find a word to criticize, but it was too good a read for me to ignore, either.  A few choice passages:

Scott also snickers at my statement that WebSphere Business Compass is a better BPMN tool than Lombardi Blueprint, says I’m the only one not employed by IBM to say that.  But I may be one of the only people not employed by IBM to have used both.

Ok, you got me there.  Bruce says Blueprint is dumbed down too much.  I agree – but I think the answer is to layer on the more BPMN-complaint modeling elements in Blueprint, rather than to try to make Compass more accessible.  I agree with Bruce they should merge these two. Versioning and collaborating are so much better in Blueprint that I can’t see throwing that away.

Later Bruce continues with another great insight:

IBM’s mistake was always thinking BPM and SOA were kind of the same thing.  Remember those hexagons in the IBM marketecture?  (Before they went to the layer cake?)  The labels were slightly different in a SOA presentation versus a BPM presentation, but there was always just one hexagon.  There wasn’t a BPM hexagon operating in communication with (but independent of) a SOA hexagon.  Like there is in real life.  [...]

(I kind of thought those layered cakes were coasters… )

[...] The hard part of all this is instant playback.  How do you achieve the immediacy of Lombardi’s model it, play it, tweak it, play it again experience without compromising what Process Server does well?  I have no doubt that if IBM wanted to do this, it could.

Will they go this route?  I doubt it.  But it would be a killer product.

Couldn’t have said it better myself.  Thanks, Bruce!

Most have heard the term “white space” as it refers to business processes. In short, white space are all the things which happen outside the standard process; workarounds effectively. Most of this is un-captured “hidden” work that impacts the overall process capability in a non-favorable way. Identification of this white space is exactly what process analysis is all about because it is within this white space where you often find real root-cause issues that create variation in how well the process is performing. Just one example would be when you have a standard process defined at a given level and use that standard as a point of measure, yet some steps are being done differently to compensate for regulatory changes or system deficits. This is a pretty common pattern we have all seen.  The upside is that finding this white space is more straight forward because you are analyzing a living, breathing business process. Notice I say straight forward, that doesn’t necessarily correlate to easy.

There is another situation however which is far more elusive, and ultimately far more vast than white space. I think of this as delivery ”Dark Matter” in that it really resembles what we have come to learn exists in the universe. Dark Matter is matter that has real effects on everything out there but is not highly visible, the mechanics are relatively unknown in so much as to what effects one might expect by its presence, and measurement is relatively non-existent. However, you can validate its existence quickly by being in the throes of a BPM project. No matter how well-formed a delivery and risk plan are to a particular BPM delivery program you will no doubt experience unexpected, and sometimes violent failures in one form or another while you are in the actual delivery phase of a project. Here is the big difference between the white and dark: you can analyze a process for white space because it is in existence/tangible or more specifically it is running; but unless you are in the real construction situation of a solution, you can’t identify dark matter’s effects on delivery. Everyone can brainstorm all the possible challenges which might arise, work out mitigations and the like but as long as you are rooted in documentation and not the visceral experience of delivery you will not be able to capture all of it with high confidence.

Compounding this problematic situation is when mitigations and controls start being applied liberally into the project before any actual experience is garnered! Consider this, you are increasing the mass of the project with more controls to mitigate risk thereby increasing the energy required to deliver. Eventually, this competition results in pure inertia. Nothing can move, nothing can proceed because the sheer weight which has been built on the project cannot be overcome. In the race for risk aversion of this elusive dark matter a project can be overwhelmed and brought to its knees before it ever has a chance to deliver value to the business in which it was chartered. Good news is that you avoid dark matter failure effects, bad news is that you almost always avoid success.

Up next will be an important notion to help successfully deal with the dark matter, “Value-Added Failure”.  A successful failure sometimes gives you the greatest returns!

Well, its only the second day since the Activiti news hit the wire and we have quite a few reactions.  Kudos to Theo Priestley for an unconventional take:

But there’s something else brewing under the surface. Whilst I could have focused on a review based on a powerpoint presentation, Tom’s direction made it pretty clear that he’s throwing down the gauntlet to the likes of Bonitasoft; we’re going with Apache and we’re going to win.

As Theo points out, there has been, lately, less vocal support of open source BPM – Intalio has been a bit quieter, and to the extent anyone is getting press, it is Bonitasoft – while jBPM went largely unnoticed outside of the developer community.

On our call with Tom and the Alfresco team, we specifically asked about the licensing – why Apache instead of LGPL – (honestly, I thought both were reasonably permissive) – and John Newton expressed the point of view that most software vendors were very comfortable with the Apache license, and not as comfortable with LGPL. So they believe more software vendors will be likely to take up Activiti as an embedded solution.

I think it is a good goal to make Activity embeddable.  But I advise them not to lose sight of having a good, complete, solution as well – which I believe is much of the secret sauce behind Bonita’s rise: they’re attempting to solve the whole problem, not just part of it.

ActiveVos takes a harder line view of the Activiti team throwing BPEL under the bus:

Today, Alfresco announced that it had digested the former developers of the jBPM project from JBoss. jBPM had never really made much of an impact as a BPMS because its real purpose in life was to cater to a core Java developer community. Much as hard-core coders might hate it, BPM is about collaboration among an extended development team that includes business users, analysts, developers and operations staff. jBPM was limited to developers and too proprietary to get much traction across the extended development team.

Let me be clear…we’ve got no issue with the jBPM team moving to greener pastures to try and rescue a moribund open source project. We do, however, have a very strong reaction to the transparently re-thought propaganda surrounding their new strategy. It feels like the jBPM architects have something to get off their chest about BPM in general… something they couldn’t get across inside JBoss and they’ve picked what is a rather run-of-the-mill addition of process capability to a document management system to proclaim a completely new metaphor for BPMSs.

Ouch.  I think Alex has a point: that the Activiti team could have made their announcement with no mention of BPEL at all and I don’t think it would have hurt their announcement.  However, I do think that Activiti is prioritizing correctly on BPMN2 first, and other process engine back-ends as lower priority for the core team.  If the project takes off, no doubt someone will contribute hooks to a commercial BPEL engine, or provide an open source implementation project for BPEL. There’s no reason that Tom and his core team have to provide this – at the beginning they’ll have limited resources and they need to focus on the most important bits first.

My biggest concern is how they build momentum around addressing the end-user concerns, starting from such an engineering-focused point.  It can be done – but only if really good APIs form the boundary between the BPM and the UI, and that good projects are started around the UI software that will expose BPM to the masses.

When I worked for a BPM software vendor, I often told people that I wasn’t too worried about open source software because BPM is a different animal than many other software categories-  user experience is critical;  the problem-space is wide, rather than narrow; and it requires seamless coordination of many different activities, rather than just a few activities.  Add to that, the standards and specifications hadn’t firmed up yet, as they had for databases.

However, the environment is evolving:

• BPMN 2.0 provides what might be the first standard that is complete enough for open source software to use as a basis for competing with the commercial vendors
• User Interface software development tools have improved.  It is easier to produce visually appealing applications that run inside a browser than it ever was before (thanks to HTML 5, AJAX, and several libraries built to leverage both).
• The cloud makes potential deployment of complicated software components easier to manage.

This sets the stage for a new round of open source software projects.  Tom Baeyens and Joram Barrez (formerly of the jBPM team) have joined Alfresco and are building a new BPM solution with a tight integration to ECM (Alfresco) in mind. They’re calling the new effort “Activiti”, just announced yesterday.  The alpha is already up on their website and downloadable.

Sandy Kemsley was briefed last week and has a very good summary written up.

I also had the pleasure of a briefing – quite flattered that Tom and company thought of us as well.  There are a couple of developments with Activiti that I already find refreshing:

1. They’re using a version of Signavio’s modeler.  Gero Decker’s team produces one of the better web-based BPMN 2 compliant modeling tools out there.
2. The installation process was pretty painless – even on my Mac – for a developer.  You need Java and Ant to run the install and build the demo, but clearly it would be a small effort to create a consumer-usable installer if that was warranted.  Since the install is really for the server components, I don’t know if an end-user consumable install is really necessary. Authors would just point their browser at the server.  Did I mention that the whole stack ran just fine, natively, on my Mac as well as a Windows VM?
3. The documentation is already pretty comprehensive, and gets down to no-nonsense details (not true for many commercial products).
4. There’s already a REST API.  I like the early emphasis on interfaces, APIs, and framework – because that effort will be rewarded by making it easier for contributors to be productive.

There’s still a focus on embedding the engine inside other software – and on more liberal licensing terms (Apache license) that should make it easier for software companies to adopt it.  And I think the market is ripe for an open source BPM platform that leverages standard underlying technologies and is built from the beginning to allow for cloud-based deployment.  I think they’re off to a good start to create something that is really developer-friendly.

So what are the concerns?

1. It isn’t clear (to me, yet) what the long-term involvement / direction of Signavio is – after all, Signavio has a for-profit business of hosting modeling in the cloud.  But at some point I think a true open source project will want to be able to improve on the modeler as well as other components at the engine level.
2. There’s a lot of work yet to do. Right now much of the engine isn’t yet implemented.  This is actually apparent from the documentation – and I love that the team had the courage to expose what they have, and what they don’t have ready at this point.
3. Earlier I mentioned developer-friendly… what about user-friendly??

Well, as to the last concern, I’ll give my 2 cents.  I think for a commercial product, user-friendly is one of the out-of-the-gate concerns. For an open source project, developer-friendly has to come first – because if it is developer-friendly, then additional developers can join the team and build the user-friendly layers.  If you start out with something relatively user-friendly but not developer friendly, it is as though you were “charging” your developers more to work on your software – because they have to give up more of their time before they can produce something useful.

Already two of us at bp3 have downloaded the alpha, installed it and run it.  We may end up investing some time in the project ourselves.  Clearly Alfresco and the other companies involved in the project are putting a lot of energy into this effort, and more PR behind it than I felt jBPM ever got as part of RedHat.  They’re off to a good start, with ambitious goals – and as they say, dream no little dreams…

I was fortunate to finally meet Neil Ward-Dutton in person at IBM Impact this year.  We attended different sessions for the most part, so our one meeting was just for a few minutes by the escalators.  And I’ve often found MWD’s analysis of BPM vendors (and other adjacent markets) to be insightful and to the point. So I’ve been looking forward to seeing Neil’s writeup for MWD.

Neil starts with a little history of the IBM Impact event – how it has evolved from Websphere to SOA to BPM – and with a legitimate business track in effect now.  As Neil pointed out – BPM wasn’t the only theme getting traction at IBM Impact (though you might get that impression reading my blog posts, because that’s what I’m focused on) – but it did get its share of attention in they keynotes.

What was more telling here was not the platitudes about the importance of business processes – but the frequency with which technology from recently-acquired Lombardi was placed front and centre in those same keynote sessions (see Bruce Silver’s note). And as Scott Francis from BPM implementation specialist BP3 pointed out the Lombardi-specific breakouts were very heavily attended – this stuff clearly impressed attendees from what I heard and saw.

I agree-  the surprise was how they put Lombardi front-and-center.  It wasn’t the “what’s new” from Lombardi, it was the wholehearted adoption of the new acquisition that was surprising (and if you’re a BPM advocate, encouraging).

Neil identifies twin themes in IBM’s recent acquisitions of Lombardi and Cast Iron:  consumability of the software (ease of use), and consolidating vendor relationships that require smart competitive tactics. I’m going to write more about the first theme-  I think that ease of use will be critical for BPM success going forward.  It may be the most important factor in the end…

He goes on to say that time is of the essence in defining its go-to-market strategy – not because the customers must have an architecturally perfect solution tomorrow, but because the competition has gotten its act together, and BPM is hitting the mainstream – so firing on all cylinders now is critical for success.  I think his analysis is spot-on.

I’ve been a little remiss in reporting in on my own session at IBM Impact.  As part of Lombardi Day, I gave a short presentation on the unconference we put together, in collaboration with Stanford University, in January.

I’m embedding the presentation here – I added a couple of words and images to clarify a few points that I can’t talk to live when you view it online.

If you attended the session and have any comments or feedback, please let me know, I’d love to hear it.  If you’re interested in hosting bpmCamp where you live, let’s talk – maybe we can get one organized!

Neil Ward-Dutton of MWD Advisors has written up Tibco’s ActiveMatrix BPM Announcement:

Now of course the next challenge is the execution challenge. Can TIBCO’s field personnel explain and sell ActiveMatrix BPM effectively? Although the company’s European salesforce has always had success selling iProcess Suite as a “standalone” BPM proposition to customers (thanks in part to the UK heritage of Staffware), the company has found this more difficult to do in North America. Here, BPM has been more likely to be sold as an add-on to a SOA infrastructure deal. This is something that TIBCO is going to have to work on.

I can certainly vouch for the characterization of the North American sales efforts.  Back when I was actually supporting BPM software sales on a regular basis, we loved to compete with Tibco.  ActiveMatrix BPM is getting a decent amount of positive press coverage, so it is at least getting a fair hearing, whereas iProcess had already been essentially defined out of the top tier of BPM solutions.

Neil goes on to say:

As I mentioned upfront, ActiveMatrix BPM is definitely TIBCO’s new strategic BPM technology platform – but isn’t the only process management platform that TIBCO has in play; and in fact, iProcess isn’t the end of the story either. TIBCO also supports two other workflow technologies: InConcert and BusinessWorks Workflow. TIBCO has committed that iProcess will continue to be maintained and supported for the foreseeable future: however it’s likely (in my opinion) that InConcert and BusinessWorks Workflow will soon be end-of-lifed.

Looks like IBM isn’t the only one with a surplus of BPM tools in-house…

Earlier in the piece was something curious, especially given the recent discussions around “Social” BPM…

According to TIBCO’s head of BPM product management, “we’re just not seeing demand for social BPM in our customer base right now”. This is interesting: perhaps TIBCO’s customers have different interests than other enterprises.

Neil, you are too kind!  This makes me think they don’t have many BPM customers, aren’t talking to them, or aren’t asking the right questions and then listening. When I see the adoption numbers from Blueprint and Blueworks, and when I listen to people who run SaaS BPM software (Appian, process maker, Signavio), all the data I get tells me that there is quite a bit of demand for social BPM.

Also, Sandy Kemsley has pretty comprehensive coverage of the event.

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.