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…

Jacob Ukelson of ActionBase once again writes an intriguing post on complex business processes, referencing a Clay Shirky article on the collapse of complex business models.

Ironically, while I share Jacob’s optimism about the future of products like ActionBase, I don’t agree with some of the points he makes in his post even though they are in support of a conclusion we both agree on.  First, in areas of agreement: whether you call it case management or ad-hoc processes or knowledge work – software products are increasingly going to target what Phil Gilbert used to call “the 98% of the business that isn’t in IT”.  Different vendors will tackle this differently.  A few interesting examples:

• ActionBase lets users create a process (and amend it) on the fly using Word, Excel, and Sharepoint to drive that process.  Several other vendors have been pushing “case management” or “adaptive case management”, and it looks like ActionBase is adopting some of this terminology in their positioning as well.
• Lombardi (now part of IBM) created Blueprint to foster more participation in building and understanding process models (and not strictly BPMN process model views). Simultaneously Lombardi released products to integrate ad-hoc subprocesses leveraging Sharepoint (a common example is collecting interview feedback via Sharepoint, but collecting the final decision on follow-up steps in a structured process).  Several other “community” and “social” sites have cropped up since:  Alignspace,  Blueworks, Signavio, to name a few – each with different target audience from formal process modeling to more informal networking and sharing.

However, part of Jacob’s post I don’t find myself agreeing with.  Jacob makes the argument that BPM-targeted products are becoming more complex – by adding rules, simulation, event processing (and by adding to the modeling notation itself).  I’ll agree that the BPMN notation has evolved to become more complicated – and that is a concern – but mitigated by the fact that you aren’t required to use the most complicated elements to get the job done.

As Jacob notes, supporting rules, simulation, and complex (or even simple) event processing is valuable, but I think he overstates how much complexity is added by including these elements in a BPM offering.  For one, processes often leverage rules and events regardless of whether these features are integrated into the BPM offering.  For another, transparently supporting events and the way they interact with your processes actually reduces complexity of the software solution being built.  If you have a simple process that doesn’t require events, you don’t pay a complexity penalty for those features existing – but if you need to deal with events interacting with your process, then having a well-integrated event model actually helps quite a bit.  Finally, simulation is almost a completely separate function – it doesn’t complicate execution or building the executable model, but it does give analysts a way to model behavior before they go live.

An interesting example.  One of the things you often want from a process is to be able to report on what’s happening within the process, or to do analysis on the aggregate data.  If data tracking capabilities aren’t baked into the process software you use, then you’ll have to build the data tracking capabilities (and likely, the reporting capabilities).  But if the data tracking capability is built seamlessly into your process software, then you’re more likely to track the data you need, and at less expense and complexity (as measured by lines of code written, or by just about any other measure you choose).

I guess my point, with regard to complexity is this: a given process is easier to describe and translate to execution today than it was before these features were added to BPM suites, not harder.  Of course, with increased efficiency for previously mundane but time consuming tasks, the difficulty of problems being tackles is growing – but that’s just the way the software business works – the goal posts are always moving. There is an opportunity for BPM solutions to differentiate by providing a better overall experience- making sure the various parts that Jacob describes work together as “one” product rather than feeling like they were bolted on with duct tape and bailing wire.  Some product teams have done a better job than others in this respect… in part leading to the conclusion that BPM is “too hard” or “too complicated” by some, while others think BPM is the best thing since sliced bread (and all points inbetween).  A fair amount of this variance in perspective can be traced to early experiences with specific BPM suites.

I think it is healthy for ACM (adaptive case management) advocates to hash out what ACM truly is in their own discussions and forums (as WfMC has separated it from bPM), but I think ultimately organizations are going to see ACM as a necessary component of their Business Process Management initiatives, rather than something separate from their process initiatives.  Jacob is right – many of the BPM software vendors won’t “get” the unstructured world of ACM, until it has a chance to mature and coalesce around what the key features and benefits are.

A pretty compelling demonstration of Google’s collaborative features in this article about “Gravity”, which is essentially a mashup of the ARIS modeler and Google’s Wave.

Its a great demonstration.  The biggest surprise, I think, was that this was something built by SAP- not exactly known for pioneering things like this.  There was a lot of buzz over twitter and blogs about how cool this is and how impressive it is – and I agree the demonstration is impressive – but maybe not for the reasons people think.  It isn’t, for example, an impressive bit of software engineering.  Mashups are, technically, relatively easy to execute compared to many other software applications – which is why there are so many mashups with Google Maps, for example.   I imagine Google has similar designs for Wave – and this is actually what I find impressive…but more on that in a minute. Right at this moment, Google Wave integration won’t help much – its not even in public Beta yet, so it isn’t something most companies or users could take advantage of.

If I’m not mistaken, what we’re seeing in this demo is that some folks at SAP have added collaborative features to their modeler (ARIS), by mashing with Google Wave.  That’s a great idea, and we can see how simple/straightforward it looks to be.  I can imagine other tools – Blueprint, Signavio, Appian Anywhere, Blueworks – can easily replicate this from a technical perspective.  There are some issues – like security- that these tools would have to consider if Google was going to be the means for collaboration – but at least one of these tools already has collaboration features at least as good as those shown in this demonstration (live chat, invitations, mutual simultaneous editing) – just not using Google Wave to do it.

What impressed me was Google Wave.  If one of the ideas behind Google Wave is to make it easy to add collaboration to enterprise applications – that could really enhance the quality of work going on in many collaborative business applications and processes – and it strikes at the heart of what Microsoft Sharepoint does for organizations, without the infrastructure requirements and “administrative” requirements.  And whereas Sharepoint is difficult to integrate into your business applications, Google Wave has an opportunity to lower the barriers and steal a march.  If anything, watching this demonstration made me hope our beta for Google Wave arrives sooner than later-  can’t wait to try it.

UPDATE 10/4/2009: Well I know I’ve been submitted for “consideration” for getting a Wave account, but I haven’t received an email yet from the Wave team inviting me to join.  There are some interesting early comments from people who have gotten access, however.  In particular Oscar Berg had an interesting and thoughtful take on Google Wave.

Update 10/6/2009: I just saw this article and youtube video. The article’s premise is that SalesForce is here demonstrating the value of Google Wave.  But it also proves the limitations… Good read..

Update 10/13/2009: A few more websites/ pages are up with useful and interesting Google Wave info.  Although, I have to admit, some of it sounds pretty funny like, “11 tools for Google Wave you’ve never heard of”  – well, that would be about any 11 tools for most people, wouldn’t it?

Google Wave 101 – this is a list of shortcuts, etiquette.  Its pretty basic, and a bit premature for my taste.

ActionBase Blog (have to add that to my reader) had a good post about how the BPM community has largely ignored the impact Wave could have on end-users… however, I’d point them to this post for evidence to the contrary… as well as mentioning the needed enterprise features to make this reality for large enterprises. ActionBase takes a different approach to process,  which I think is highly complementary to the traditional structured process approach.  I’d love to see them paired up with other BPMS offerings to really complete the picture.

Tips and Tricks from Techie-buzz.com.

Update 11/8/2009: More thoughts from ActionBase about Google Wave; primarily with regard to Wave potentially being a disruptive BPMS-like force in the BPM market.  I’ll post some more thoughts on that possibility this week, but I don’t see it as likely to disrupt established BPM vendors so much as the unstructured or user-driven vendors, as well as to further fragment the market currently served by Excel, Sharepoint, and Notes.

Update 11/30/2009:  The creator of Gmail chimes in with his view on Google Wave – and his best point is that it just isn’t ubiquitous like email, and therefore is unlikely to displace it.  He also has some good suggestions about preserving linearity or compartmentalizing some of the threads inside a wave.  Read on right here.

Update 1/24/2010: Anatoly comments on Google Wave, concluding that it is useful, and listing pros and cons. The cons he points out are interesting:

• No email/RSS notification of wave changes.
• No permanent address for the wave
• No numbered lists
• The requirement to register for google wave to participate. This last one is a big barrier to adoption because it means that you can’t arbitrarily include people in your waves. If you can’t include them, then you’re not likely to use Google Wave to collaborate with them…

Please feel free to add additional google wave links in the comment section… I’ll try to keep a compilation without working too hard at it.

Over the weekend, Lombardi pushed out their August, 2009 Blueprint update.  This release continues Lombardi’s track record of pushing releases out every 6-12 weeks with significant improvements (and yet, without so many changes that current users get lost).

In the current revision, additional export options were added.  I was able to easily export my processes in an Excel summary format, as XPDL, and as BPMN 2.  The hardest part about doing this was just finding/remembering where the export feature was hidden within Blueprint (hint: instead of just opening your process, open a “project” and then you’ll get a view that lists each of the processes and gives you export options for each).  The help and/or forums will benefit from an update to guide users to this very useful page.

I always assumed that Lombardi would make it easier to import than to export from Blueprint, and admittedly the import features were rolled out first (from Visio and Teamworks for example).  But the export / publication features have caught up – to Powerpoint, Word, Excel, XPDL, BPMN2.  The last two representing the kind of structured export I wasn’t confident that Blueprint would support because those are also opportunities for other BPM tools to pick up the models for execution.  Clearly Lombardi feels confident that their end-to-end user experience and tooling will cause customers to use Blueprint and Teamworks in combination rather than Blueprint and other tools.  Lombardi claims this is the first shipping implementation of the BPMN 2 specification.

Earlier this year, I wondered out loud about the future of BPMN 2.0 as an exchange format given that Lombardi and a couple of other hold-outs had finally adopted XPDL 2.1 as a supported exchange format.  Lombardi reassured me that they still fully intended to support BPMN 2.0, and I recently had a conversation with Signavio (another vendor which supports XPDL -look for more on this in another post), who also stated their preference for BPMN 2.0 as an exchange format.

Full-text search is another feature that was added to Blueprint.  Not sure what technology they use behind the scenes but it seemed to do the trick for my searches.  The what’s new feed has been updated as well, but those and other refinements are a little more subtle – the kind of things you might not explicitly notice as being different, but you’ll appreciate being able to find things just a bit easier, in general (and *thankyou* for the longer process names – mine always seem to be a bit verbose, like my blog posts).

Bruce Silver wrote up a quick, thorough review of Signavio, a new BPM in the cloud offering.  Looks like it is primarily focused on modeling rather than execution, which makes comparisons to Lombardi’s Blueprint perhaps the most relevant comparisons.

As usual, Bruce’s sense of humor is on display (“You have to sign a click-through agreement in German to get started.  Oh well, who reads those things anyway?”).

One really good shot against Lombardi’s Blueprint in his review:  Signavio can export an XML document that represents the model.  There’s no such facility in Blueprint (though it can “publish” to Teamworks, that isn’t the same thing as exposing an XML output).  Bruce also points out that they have full support for BPMN 1.1 (whereas Blueprint only supports a subset), but Lombardi would argue that they’re providing a reasonable subset to keep the diagramming from distracting from the process at that level.  (Still, like Bruce, I’d like to have the full set of diagramming options for power users).

At any rate, its  a good read, and from the comment thread, Signavio is already working on some of the issues.