If I know Tom Baeyens, he’s pretty happy with this blog post announcing the collaboration of Activiti and Camunda on “Activiti Cycle”.  Previously, Camunda had announced Camunda Fox, a set of tools to help accelerate using open source software for BPM, while pursuing business-IT alignment.  Cycle has been proposed as the name for the collaborative authoring of Activiti processes, and Camunda has now become the lead developer on that feature set.  This sounds like a win-win for both organizations.

Austin Startup has just run a piece on the 2nd Annual Capital Factory Demo Day:

The 2nd Capital Factory Demo Day is coming on September 8th. We will have 300 investors, press, and technology entrepreneurs in attendance to watch the launch of the 5 companies from our 2010 program. This is an invitation-only event, and we’re keeping the quality of the content and the networking as high as possible.

I went last year, and I found it interesting to witness, essentially, part of a process for bringing new companies to market.  The event was surprisingly good, the startups were surprisingly good, and the discussions were pretty interesting.  It sets a high bar for the second event.  I think there’s no doubt that Capital Factory and the Demo Day event have been good for the Austin startup scene, though the organizers will be the first to admit that this approach isn’t for every startup, or every entrepreneur.

I plan to be there again this year, schedule willing.

A few weeks ago I had a call with Intalio’s Ishmael Ghalimi.  It was right before vacation, and the unfortunate side-effect is that I’m only now catching up with writing the post I meant to write when I got off the phone with him.

For the last couple of years, many of us in the BPM world have wondered what exactly Ishmael and his crew at Intalio were up to.  They made a series of acquisitions and investments, the purpose of which wasn’t quite clear to much of the BPM community, because it included a CRM solution and a focus on cloud computing.  But when we finished talking, it was clear to me that Ishmael has simply made a different bet than most of the rest of the BPM community.  While the mainstream of BPM innovation has been focused on BPMN2, modeling and collaborating in the cloud, and tweaks to the method and thought process like ACM… Intalio has gone a contrarian route-  retooling and refocusing on BPM in the cloud – but not by dabbling, by jumping with both feet, so to speak.  This is the long game rather than the dink-and-dunk short game.

It is a bold move, and Ishmael makes the argument that if you really want to play with the big boys, you need to make the investments that Intalio has made in a vertically integrated stack for cloud computing.  Rather than writing all the code from scratch, of course, Intalio is relying on a bevy of open source software.  A quick look at this page reveals just how many open source projects are involved in Intalio’s offering (and that’s just on the application engines side).

A heavy focus on open source software might cause you to wonder how Intalio makes money.  Intalio contributes to some of these projects, and just leverages some others.  the distinction that Ishmael made is that while the open source project for, say, the process engine (Apache ODE and Drools Flow), is free and open source… The entire integrated solution that Intalio is offering is commercial.  You are, essentially, buying a professionally prepared 10 course meal, instead of just getting all of the ingredients for free, so to speak. As Ishmael points out, customers do not mind paying for commercial software today that includes open source parts (nearly all of the commercial BPMS offerings today include at least some significant open source project code).

Ishmael went into great detail about the investment required to make Intalio’s PAAS offering virtualization- ready – the upfront investment to natively leverage SpringSource and the like is significant. But once there, it is much easier to scale application deployments.

We walked through a pretty compelling demonstration of the authoring tooling – which was browser-based, and he scored bonus points with me by running the whole stack on a Mac (attention commercial BPM vendors: your users and developers want Mac, iPad, and iPhone support).  The ability to model data, leverage it in user interface and process diagrams, and deploy it quickly, is compelling.  It doesn’t *feel* like a BPM tool, it feels like an IDE for building apps in the cloud.  Perhaps that is the intent.  To make BPM a feature of the environment, so to speak, rather than the centerpiece of the environment.

I asked Ishmael, given that this seems like both a horizontal and global strategy and a great number of component projects that make up their product offering, how does Intalio decide what NOT to do?  We had discussed why he had made the investments he’d made, but how do they decide what not to do?  Ishmael’s take is that they are throwing the long ball – seeing themselves as a much smaller version of a Microsoft of the 90′s, where:

• The operating system is the cloud instead of Windows
• The “development studio” is Intalio Studio instead of Visual Studio
• The productivity suite is Intalio Docs instead of or in addition to Microsoft Office

Another analogy he gave is RedHat – providing the glue to pull together open source projects into coherent commercial offerings.  There are many execution challenges, but if you pull it off and execute, you’re in very good shape because most competition is either too small to deliver, or too big to abandon their existing commercial software business (or not nimble enough). His example of too large:  he argues it would be very hard for IBM to come to market with an integrated product that is also virtualized for the cloud, because there are different P&Ls within IBM’s software group, who aren’t going to work together on one seamless offering. Others might argue these points differently, but given Ishmael’s thinking, the strategy he’s pursuing makes sense in that context.

The pricing model is free up to 5 users, and then scales up in price as you expand the solution.  This makes it easy to prototype solutions, and scale cost relative to the benefit achieved.

In some respects, what Ishmael and Intalio are trying to do is offer a compelling software stack for process applications in the cloud, but also removing many of the barriers to entry companies would normally face.  One could argue that they are trying to make BPM in the cloud simple enough that mere mortals can attempt it.  And Ishmael claims it isn’t just a superficial attempt to band-aide these projects together – that they’ve thought and worked hard on every level of the stack – from hardware, to virtualization, to Infiniband networking, to the more obvious software layers that developers interact with.  The conversation with Ishmael about these topics reminded me of my conversations with Phil Gilbert of Lombardi about making versioning relevant to BPM authoring (that it isn’t enough just to check things into subversion, that real versioning requires a much deeper understanding of process authoring).  Versioning was Lombardi’s long pass in the last couple of years leading up to the acquisition by IBM. And the point of this kind of deep investment in both cases is to create simplicity out of complexity – to provide truly useful abstractions to the customers of your software.

Three is risk that Ishmael and Intalio may have made this investment “too early”.  I recall in the 90′s a firm that made a bet on server-side Java runtime environments a bit too early – betting on JRun, which was a pretty immature platform.  A year later, when the product suite was ready, the whole thing could have been accomplished in 3 months on top of newer commercial application servers (e.g. Weblogic).

Time will tell if Ishmael’s long pass pays off – he’s either stolen a march on the competition, by getting “fully cloud-enabled” early, or he’s made the march too early and paid too heavy a price to get there.  If he’s too early, we’ll know because other “mainstream” BPM vendors will quickly follow with fully cloud-ready BPM stacks.  If he’s stolen a march, then Intalio will use its technical advantages (perceived and real) to drive more business at the expense of others.

The Death of Google Wave is interesting.  We’ve written about Wave before, several times, but in particular when SAP put out its “Gravity” demonstration.

The official Google Blog blames the closure of Wave on a lack of user adoption:

But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects. The central parts of the code, as well as the protocols that have driven many of Wave’s innovations, like drag-and-drop and character-by-character live typing, are already available as open source, so customers and partners can continue the innovation we began. In addition, we will work on tools so that users can easily “liberate” their content from Wave.

So, there’s a bunch of open source code, it looks like, that partners and customers might leverage.  But most of us, I think, would prefer to just use a finished product.  There are many other unofficial takes, here and here are two examples.  I had a few others linked, but no need – you can find such commentary easily!

When Wave was announced last year, I spent some time discussing with others what it meant for BPM.  Some thought it was a game-changer, some thought it was a non-event.  The thing that became clear to me: collaboration tools like this are going to tend toward being free, or extremely inexpensive.

Starting last fall, the discussion in BPM circles had often turned to “ACM” (A variant on Case Management).  Some in BPM circles would call this unstructured process. Some would call it “chaotic” or unpredictable processes/work.  Keith Swenson and colleagues even penned a book about managing such unpredictable work.  Google Wave was, to this crowd, a great example of where “knowledge work” is headed – into collaboration spaces, not into BPM software.  To me, it was just proof that email and lightweight project management tools were not going away.   If Google Wave accomplished anything, it showed:

1. Separating yourself from email divorces you from a knowledge worker’s daily routine (some might say, process).
2. If it isn’t trivial to involve the right people in a collaboration, then users give up
3. Collaboration is going to be free or nearly free.  Even if it has pretty amazing features.
4. It is really hard to do a “big bang launch” successfully.  It makes me even more impressed that Apple seems to pull this off with such regularity.

So what does it mean for BPM?  Not much.  Wave was never really about structured interaction, it was about ad-hoc interaction.  Although ad-hoc interaction is important to a good BPM strategy, no one (maybe except for SAP) was really leveraging Wave for this.  If they were, they can probably leverage the open source bits to get a jump on the development effort.  For the ACM crowd, its both good news and bad news.

First, the good news:

1. A free competitor to your products, supported by a major software company, has gone away.
2. Hm. I think that’s it.

The bad news:

1. If you were counting on convincing users to leave email to use your product for knowledge work, it is time to change gears.
2. If you were expecting that being good and free was good enough… Maybe it isn’t.  Although Wave was panned in the press, it really was pretty good at what it did, though perhaps it tried to do too much.
3. If you were expecting to charge a lot of money for general-purpose collaboration software… I think those days are over.
4. If Wave was your favorite example of how ACM was really relevant to what people are doing… time to find a new example.

Silver lining:

1. Collaboration software for very specific purposes will live on (aka process modeling, or services like tripIt).
2. Some of Wave’s features will likely get absorbed by Gmail.
3. Some of Wave’s features will likely show up in other products.

I think Keith Swenson summed it up best for the ACM folks on Twitter:

“nooooo. It can’t beeeee. :-( RT @jpmorgenthal: Google waves goodbye to Wave: http://bit.ly/bg3ixC”

Well, fans of Wave and its approach were bound to be disappointed.  I saw quite a few more comments on twitter with a more positive spin on Wave being shut down.  Google found Wave squeezed inbetween email and all the other things we do in life.  It apparently couldn’t live on its own.  I’m not sure the future of ACM, per se, is anything different.  Yes, the ACM proponents will have their analogies, and they sound compelling.  And we could even agree that a large percentage of work is not addressed by BPM today, or by, more specifically, structured process.  But what ACM proponents fail to mention is that even less work is currently addressed by purpose-built ACM software.  It *could* be, but isn’t.  It is still likely to be addressed by email, project management tools, telephone, hallway conversation, and more email.

Note, I’m not arguing against ACM as a description of work, I’m just looking at the software market and not seeing it as an independent market, yet.  Willing to be proven wrong.  And I think there are a couple vendors that have the right strategy or tactics, but we’ll see if they can execute.

Working on a longer collaborative post on ACM and the marketplace.  Watch this space.

Recently Bern Ruecker’s article on “A Collaborative Approach for Real-World BPM” appeared in InfoQ. It is a good read, with much I agree with and just a few things I don’t.

We have been working in the business process management (BPM) space for years already, and it is very interesting to see the recently growing attention for it. Catalysts for this interest may be the growing maturity of the tools, the new 2.0 version of the BPMN standard, better understanding caused by more publications or improved preconditions for BPM approaches, to name only a few of the most important developments within BPM.

Couldn’t have said it better myself. Bern goes on to criticize tools that they’ve worked with:

Vendors offer more and more high-sophisticated graphical tools, which promise automation of business processes without any coding or even developers; however, we see a problem with these “traditional” vendor centric approaches: They don’t deliver on these promises!

Agreed.  But of course, most vendors don’t promise “no code” – but they do often claim that someone less than a true “developer” can deliver the solution.  In my experience, while these tools do enable personnel with less technical training to participate in the process development effort, there is no such thing as someone “too technical” for a BPM project.  Good technical help is important in any project involving information technology.  He goes on:

Without naming the concrete tool, which wouldn’t be fair since most of them share the same basic problems, a colleague had to implement an easy process with a small web GUI. The tool introduced an own magic Drag and Drop GUI designer, which seemed to be handy in the beginning, but when we almost finished the project, there were some small data validation requirements in the form, which the magic tool wasn’t designed for. In an attempt to get around these limitations, we spent more time futzing with the designer than we needed to implement the entire GUI in plain JSF, which we did in the end anyway.

I can understand his feeling here.  However, I have worked with at least one tool that has such a drag-and-drop GUI designer.  It is great for prototyping UI, as it requires no code to marshal data into and out of the the process context on the server.  There is also a validation framework that does just about everything imaginable for validation (but, admittedly, this validation framework is something only experts on the platform would know about).  There’s also an option to validate forms after submitting (in the event that validation can only be accomplished with server-side checks or more complicated business rule evaluation).   My concern with the statement above is, though it may be true for a single tool – a good understanding of the BPM software being employed, combined with good understanding of requirements, and with healthy value-based prioritization of work – should allow one to avoid rewriting the entire GUI in something like JSF.  Of course, in Bern’s specific situation it may have been necessary, but I believe that on the whole we’re better of leveraging the baked in capabilities of a BPM suite rather than writing custom interfaces in JSF (or other UI tech).  The exception being, if the customer is already an expert in the custom interface technology (already using JSF in their organization? great).

We, as BPM practitioners, have to keep in mind that it is not about the technology we’re most comfortable with, it is about technology our customers can consume, maintain, nourish, and build on.

Bern goes on with another anecdote:

For another customer, one developer told me, “It took more than two days to try to model some special requirements, which he could have written in Java directly in half an hour!”

I’ve heard this thousands of times.  9 out of 10 times, the developer is wrong, or missing the point.  Once in a while, they’re right.  But the point isn’t to bury the business model in Java code (wrong), or to put what should be Java code into the business model (missing the point), it is to use the model to represent what is significant to the business process, and to use code to represent (primarily) what isn’t.

Another customer tried to get transactions and stateful services running, which unfortunately required calling services as Web services. After experimenting with WS-Addressing, WS-AtomicTransaction and trying to patch several frameworks, he basically gave up and dumped the whole BPM tool.

I wish I knew which tool so that I can avoid it!  A decent BPM tool should include good coverage of web services scenarios.  And a Java API.  Bern’s article is a cautionary tale of products that don’t live up to the promise of BPM.

Bern goes on to argue that a BPM tool should be making the developer’s job easier, not harder.  While that may be true, I think the framing is wrong. The framing we would use is that a BPM tool should allow a model that accurately portrays the process to the business and also accurately represents the execution context required to run the process.  If it is harder for the developer to provide visibility to the business, that’s secondary to producing something that has high-fidelity between business model and IT reality.

Bern goes on to describe a solution that he calls “Camunda Fox” – which pulls together various other technology, including JBoss, jBPM, Signavio, and a glue layer created by Camunda.  It seems like a reasonable approach for a very technically competent team to tackle – especially a team that is intimately familiar with the technologies in question.  But it is a model-transforming approach with several inputs and outputs.  And this approach isn’t going to address the needs of a smaller business or smaller team that doesn’t have these technical skills, nor the budget to pay outside consultants to build and leverage this glue – I think Bern might argue that the “simpler” BPM tools won’t address these customers well either.  As Bern says, Camunda Fox isn’t a silver bullet, but it addresses projects that are pretty Java development focused.

I prefer to use BPM tools with a model-preserving approach (as described by Keith Swenson) because it is a higher fidelity mapping of business process to running software.

Sandy has a good review of Metastorm’s M3 offering on her blog, posted on 7/30/2010. From her review, it sounds like Metastorm is focused on a Microsoft-platform strategy (Azure), which at this point is mostly collaborative business modeling, but as Azure matures, they plan to move the BPM engine to Azure as well.  Sandy compares the model types favorably to IBM’s BPM Blueworks.

I’m not sure that basing strategy on the Microsoft stack is ideal, but someone has to win the BPM space on their platform.  I think the more interesting integration with the Microsoft stack is actually on the desktop (an approach some other BPM vendors take).  The review is another sign that collaborative BPM modeling is becoming common – some might say commoditized.

We had a great success with the original bpmCamp @ Stanford in January, this year.  We’re now ready to start the ball rolling for a bpmCamp in Austin.  We’re just at the formative stages, but we are targeting dates in October, and currently scouting locations in Austin.  We’ve also had tentative discussions with Stanford about having another bpmCamp at Stanford, but a bit later in the year 2011 (maybe even in the summer of 2011). Our goals and thought process are much the same as last time:

1. BPM Conferences are good, but BPM Conferences are (usually) too general, too big, too expensive, and stuck on platitudes because of the above.
2. bpmCamp is intimate. It was 40 people (max capacity) at Stanford.  We’ll figure out our max capacity for Austin, it might be just a tad bigger.
3. bpmCamp is specific.  We will be focused on the Lombardi Software products acquired by IBM earlier this year, and now known as IBM BPM Blueprint (aka Blueprint), and Websphere Lombardi Edition (aka Lombardi Edition aka Teamworks).  (We would welcome the chance to organize a bpmCamp for another product offering – but we need a partner to help)
4. bpmCamp is affordable.  Exact price is TBD, but it won’t break your budget.
5. bpmCamp is focused on what attendees care about.  Topics are crowd-sourced, so anyone attending can help shape the agenda.

If you’re interested in attending, watch this space, or keep an eye on posts with the tag bpmCamp. If you’re interested in sponsoring bpmCamp, we’ll have more details about that soon.

If you have any questions in the meantime, contact us at:
bpmCamp Email:

(editor’s note: bpmCamp is not affiliated with or sponsored by IBM.  bp3 is not acting on IBM’s behalf, nor is bp3 an affiliate nor subsidiary of IBM. )

Congratulations to local Austin Software company Zilliant, which just raised $13M in a Series G financing round.  Zilliant was founded in 1999 by a group of people that includes a few former colleagues.  And I still have some friends working there. Thanks to Austin Startup for breaking the story (for me at least).

Zilliant’s software helps companies optimize their pricing.  If there is a process for pricing – and I’m confident there is – it is folks like Zilliant and Mimiran that will figure it out in specialized software. At the very least, they’ll figure out the hard part (optimum price).  It looks like the surrounding process of signaling, proposing, refining, approving, and rolling out pricing changes is also being targeted by these packages.  You might call it BPM for Pricing…

IBM’s BPM Blueprint folks recently posted a short video that shows how to create a “join” in a process.  Its a painless video to watch because it is in double-time, but it definitely exposes an opportunity for improvement in how one goes about modeling joins.

It relates to our previous post on process patterns. This video simply shows how to leverage a basic BPMN construct (the join) in a specific collaboration and modeling tool (blueprint). But this is also one of the van der Aalst “patterns”, that, as I mentioned previously, I’d rather call construct than pattern. And I think everyone would benefit if we start to discuss patterns with more useful abstractions embedded.

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

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

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

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

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

Chris Adams, VP of Product and Technology at Ultimus:

Despite all of the recent recognition of processes being dynamic in the Business Process Management (BPM) / Adaptive Case Management (ACM) spaces, the majority of processes in business have ALWAYS been unstructured.  [...]

Thinking back to the inception of automated processes, the reason why workflow technology came first, arguably, is that it is “low hanging fruit”.  Like with any large project across the enterprise, the concept of starting small and growing from initial successes is a well understood strategy to achieve large scale success.

Chris depicts workflow as the lowest hanging fruit, structured processes as the middle fruit, and unstructured as the highest fruit to attain.

From reading his post, it sounds as if he’s saying that unstructured is harder, technically, to implement than workflow or structured processes.  However, unstructured is actually easier, technically speaking.  Businesses have been performing their unstructured processes for years – using email, for example.  Or Lotus Notes applications.  Or SharePoint.  We can argue whether any  of these were good solutions – but my point is just that even the ways in which these products fall short are not hard technical issues to resolve (if only the folks who write email software and the like actually cared about processes as a target).

Unstructured processes are “not low hanging fruit” due to organizational barriers, not technical barriers.  Processes that cross organizational boundaries run into resistance.  There will be users who worry that software will over-constrain their free-wheeling unstructured process – like the Borg assimilation routine. No one wants to feel like a Borg automaton.  But there are times when process *should* cross organizational boundaries – whether structured or unstructured.

A while back, Bruce Silver wrote up another thorough review of a BPM vendor’s offering, and this time it was TIBCO’s ActiveMatrix BPM.  There were a couple of nuggets that jumped out at me:

1. TIBCO is pushing task distribution as being separate from process (or orthogonal, you might say).  It is an interesting wrinkle to their product.  I’ve run into a few cases where the “process” presented to me was really a “how to distribute work to the people on this team” problem, rather than how to manage the process or lifecycle of the stuff their working on (which might extend into groups that aren’t part of the same team).  But there have been only a few, relative to the total number of processes I’ve seen.
2. Apparently they borrowed one of the best features of Lombardi Teamworks (now Websphere Lombardi Edition): “The inline preview function allows playback of running forms from within TIBCO Business Studio.   This Lombardi-ish approach is carried forward in page flow modeling as well, using BPMN to describe each step in the page flow… an advantage (in my view) over the programmer-oriented approach of most ‘enterprise-class’ BPMSs.”
3. It sounds like they’ve added performance data tracking that approaches what Lombardi does.  I’ve been surprised that this early differentiator at Lombardi (circa 2004) hasn’t been more widely copied 6 years later.
4. There was another TIBCO BPM product, but I think that’s on the way out based on TUCON coverage.  BPM vendors need to take a page from Neil Ward-Dutton’s blog.  Bring your customers with you.

Thanks again to Bruce for covering all the product releases of note.

As with several previous posts from Mr. Ukelson, I really like this one, about Process Simplicity.  Simplifying and Simplicity have been themes of late- because what software needs, and specifically what BPM needs – is deeper thinking into how it is surfaced to those of us who use it.

I also like how Mr. Ukelson focuses on what his product can do for the business, and not about whether it is BPM or ACM or something else.  He offers a definition of BPM as the “discipline of making work processes simpler”, which leads to interesting conclusions and points of comparison.

I agree with the philosophy of making work processes simpler, though you could say “making work simpler” because not every participant of a process will perceive it to be a process – to that person it may look like a single action or reaction, or a case.

Finally Law 10 – This is an interesting law from a BPM perspective – isn’t BPM about exposing and codifying the routine (which is version of the obvious)? So maybe BPM’s job is to lay the groundwork so we can get to Law 10 in business processes, and something else will need to come along enabling the next step towards Law 10.

(law 10 was “Simplicity is about subtracting the obvious, and adding the meaningful.”)

I think Mr. Ukelson may be on to something.  And I think his characterization of the BPM/ACM debate is one of the better “framings” of the discussion that I’ve seen.  Not that that won’t stop anyone from disagreeing with me… please comment!

Neil Ward-Dutton of MWD Advisors recently put this quite well, when discussing how two major customers of Oracle and Tibco’s respective BPM solutions feel about the impressive new releases from these firms:

Nevertheless it’s not necessarily the case that TIBCO and Oracle customers are punching the air with excitement about the new stuff. Both companies I spoke to have made very significant investments in earlier versions of these technologies and now see their investments as important to protect. Their investments haven’t only been in software licenses but also in skills – and protecting these sunk investments is at least as important for them as finding out what the new stuff can do.

In both cases there are question marks about how easy it will be to migrate existing investments from the ‘old’ platform to the new offering. Of course all enterprise software vendors say they’ll support previous versions of tools for existing customers, but there’s a difference between continuing to fix bugs and actually helping a customer protect the value of an existing investment into the future.

I think it is high time that commercial software vendors do a better job supporting transitions from old-to-new.  At the very least, sponsor (and invest in) an open-source project to help customers make the transition.  At best, build the right bridges to get customers from version 2 to version 3 in a meaningful way that protects their investment in software.  And if you release a new “BPM” product with different DNA than the original product, you still owe it to your customers to figure out how to bring them along with you.  They shouldn’t have to scrap their original investment to use the new tooling.

Software vendors, in general, require too much of customers when they roll out new software, and especially when they do a major refactoring of their software offering.  It is especially noticeable in the BPM space at the moment as stack vendors incorporate and digest the pure-play vendors they’ve purchased.  I’ll be interested to see if IBM can release the upgrade package promised to Lombardi customers that brings Teamworks 6 customers into the world of Websphere Lombardi Edition (previously known as Teamworks 7).

As Neil asks: is there a process for that?  There should be…

Surprised to run across this post the other day on the BlueWorks blog.  Not sure exactly what prompted the timing of it, but it is a good introduction to BPMN and why it exists.

Meanwhile, Tom Baeyens has his first Activiti presentation available via slideshare and on his blog.  Activiti is the new BPMN 2 open source project he is working on at Alfresco.

Recently at IBM Impact I said that “process data wants to be free” – available in more places, more accessible to users and managers, and more sensible in form and structure.

Jacob Ukelson makes the case (paraphrasing) that process just wants to be free:

From my perspective the simplest answer is that we focus on unstructured, unpredictable, ad-hoc human processes that knowledge workers do, while BPM suites focus on structured, predictable processes – and the two approaches are complementary.

In other words, make it easier for the everyman/everywoman to execute their processes.  He focuses on three key themes that differentiate ActionBase from other approaches to knowledge work:

1. Familiarity – ActionBase leverages email and documents in a way that is immediately famliar, rather than asking users to learn a new tool or URL.

2. Collaboration – This is as much a benefit of leveraging email as anything, but the point is that users can dynamically bring others into a process to help, at runtime.

3. Managed – applying “enough structure to make the process manageable, but not so much as to strangle it.” And so the focus is on visibility rather than constraining or controlling the flow.

These are good tenets for anyone to build software around.  Philosophically, I think ActionBase has it about right.

Tom Baeyens writes:

We’re very committed to BPMN 2.0. In fact, we’re aiming to build the #1 BPMN 2.0 process engine and deliver the full BPM Suite components, all available as open source.

Glad to hear it – I’m sure the world of BPMN and Open Source BPM will be the better for it.

Bruce Silver gets the scoop on most product updates in the BPM space, and this time is no different.  He received an update from Pega, and his writeup gives a little bit of market positioning and background, followed by a quick run-through of their product offering, screen shots included.

Two of the UI-design elements jumped out at me – the “chiclet style” process mapping diagram (Bruce’s phrasing) that is so similar to Blueprint, and the tab-centric interface so common to CRM platforms (even dating back to the early 1990′s).

Bruce also summarizes their Case Management offering, and calls Pega “clearly a major player in Case Management”.

We had a brief hiatus while I was out for a few much-needed vacation days.  At my highschool reunion this past weekend, I took note of the phones in evidence – almost every one I saw was a blackberry or an iPhone (noteworthy: everyone who had a blackberry said it was company issued, or they’d have an iPhone).  I didn’t see any Android phones – but maybe I did and just didn’t recognize them as such.  Apparently, however, there are 160,000 getting activated every day (I’m wondering where they are… I still don’t see them yet, but I don’t doubt Google is reporting accurate numbers). I also had a great brunch with my parents and a number of their friends near their home in Florida.  It turns out that of the 9 people there, 7 had iPhones.  Not the demographic I would have expected to adopt iPhones, but last year my parents got each other iPhones for Christmas.

Tomorrow, a significant percentage of BP3 is heading to an Apple Store of their choosing to pick up an iPhone 4.  My friends are a little surprised – although I’m somewhat of an early adopter on technology, I detest standing in line today for what I could buy easily another day with no wait.  I also hate to buy things the moment they come out because if there are any hitches, you don’t know what they are yet.  Finally, I hate to pay the early adopter premium.  But tomorrow I’m breaking these rules for a few reasons… First, I’m standing in line because I didn’t see the home-delivery option when I pre-ordered (maybe I didn’t see it or maybe I ordered too late on Day 1 to see that option?).  I’m buying early because Apple has earned my trust with the iPhone 3G (and 3GS, and iPod Touch… and several MacBook Pros).  Finally, the pricing doesn’t penalize the buyer for early adopter status.  So I’ll be there bright and early in the morning for my iPhone 4 pickup, and I’m looking forward to the Retina Display and other fun new bells and whistles.

Interesting article and followup discussion on the nature of Open vs. Closed, by Chris Dixon.  It would be interesting thought experiment to characterize BPM in a similar fashion into dimensions and open/closed plotted against product offerings.  You could imagine this chart from Chris:

OS vs. platform (originally from Tom Elsenmann, et al)

We could list on the left column, database, appserver, etc.  But perhaps the most relevant items would be:

End User (browser-based, likely)

Authoring User (BPMN visualization)

Authoring User (BPMN data)

Engine (BPM engine)

Solution Provider (SIs, value added software resellers)

Platform Sponsor (BPM suite supplier)

…

At least, its interesting to think about the BPM space and what open means- each vendor is open and “closed” in different ways, which has an impact depending on the consumers of that solution.