Lest there be any doubt that BPM skills are in demand, Tom Baeyens has pointed out that SimplyHired stats claims the average jBPM salary in CA is US$114,000.  Not bad.  Lombardi BPM shows similar numbers.  It supports what we’ve been saying all along – BPM skills are in demand, and it should be a great career for the next decade (or two, or more).  Its just hard to see “process” going away as an important concept in business. So what the SimplyHired stats tell us is that the technical side of BPM is in demand – regardless of the tool set, there is a mismatch between supply and demand right now that is going to take time to fill – and knowing the technical side of the coin is only half of it – the other half being the business process side of things.  I can tell you from experience that not all great technical people have an interest in business process, and not all of them can make the adjustment to focusing on the process over the technology.

In the meantime, your best bet to get up to speed is to get a job that will let you learn on the job, attend training, etc.  There really aren’t any formal education programs at universities that are widely recognized (although there are a small number of universities that have a small number of opportunities to learn about business processes).  There are classes you can take from the software vendors or the likes of Bruce Silver, and there are certification programs-  but no sense paying for certification until you know what you’re doing.  Once you get started, then try to take advantage of the many resources on the net, and resources like bpmCamp.

Continuing on the theme from yesterday, we’ll point out a few more topics here.

• We’ll have a session (or several sessions) on UI frameworks inside and outside of Teamworks, discussing trade-offs of various approaches and benefits of each.
• The relationship between the BPM solution and systems of record.
• Offshore BPM – what is effective / ineffective – discussing real world experiences.
• BPM Requirements Analysis – how much is too much?  How do you know when to say “when”?
• A/B Testing for process improvement

I met with Lee Merrick at Stanford yesterday and we’ll be meeting again today for some final prep for tomorrow’s conference.  We’re excited and looking forward to working with everyone attending to create a great experience.  Thanks to everyone for supporting this idea with your participation and willingness to speak!

Well, as Sandy Kemsley pointed out, this deal closed fast.

Equally quickly, Lombardi shows how a SaaS product can catch up to the news (or at least start to), by releasing Blueprint to Websphere Business Modeler integration today.

Good start to the new relationship – I just wish all the products were as easily rationalized!

I’m excited about the topics taking shape for bpmCamp this week, and I’m going to send out a few teasers before the event starts on Thursday morning.  We’ll do our best to capture as much as we can and share insights with readers of this blog as bpmCamp happens, so keep an eye on this space or bookmark the bpmCamp tag.

Some of the sessions we’re looking forward to:

1. Phil Gilbert is going to stop in to discuss the acquisition by IBM and take questions from customers.
2. We’ll have a few members of the Lombardi product team in attendance to give us some insights into Teamworks 7′s operations, and upgrading to Teamworks 7.
3. We’ll talk about what “Fixed Effort” means as a way to focus on delivering value.
4. A case study discussion of an application of Agile to a project.

There are 20 other topics on the potential list, more to come tomorrow…

MWD Advisors has a post up regarding Running IT as a Business. As they put it, the main objections to this idea seem to be “daft” – that they depend on assuming that IT will run this business in the worst-possible “order-taker” fashion.

As MWD points out, there’s no requirement that IT run their business badly!  However, I will say I can identify with the skepticism that IT can be run like a business, because although “running X like a business” doesn’t have to be interpreted in the most simplistic order-taking terms, I’d be dishonest if I said I hadn’t seen just that happen.  All too often that over-simplification is what the company executives seem to think they want.

So, I think what we have here is a difference between what it should mean to run IT more like a business, and the reality of what people have confronted in their work life.  I think everyone would agree that when IT takes too myopic a view of their role in the success of the business, it is detrimental to everyone.  And if IT provides more business value… that’s good for everyone.

Where IT and Business meet is something that we have had a lot of experience with at BP3 because we’re involved in BPM projects.  You can’t do BPM projects without bridging the gap between IT and Business, and in our experience, the closer aligned IT can get with the business, the better.

I couldn’t agree more with Fabrice Grinda’s post on Why you Need a Partner.  Perhaps I’m biased, since BP3 started with two co-founders.  But I also have a lot of friends who own their own business.  And I’ve worked for people who own their own business.  And it just is true that very few people can be good at everything they need to be good at to run these businesses well.  If their business makes enough money, they can hire the help they need to run their business.  But early in a company’s life, it is really useful to have people on your team who ACT like owners (whether or not they are).

Finding the right partner can be problematic – but my recommendation is to try.  Find someone who is different, but make sure that you appreciate and value the differences, rather than finding them annoying.  And make sure the reverse is also true.  This should be someone you would want to partner with no matter what the startup idea was – not just because this person makes sense for this one idea.

And if the partnership isn’t working, exit stage left and try again- but don’t make each other miserable.  Life is too short to get stuck in an unhealthy business relationship.  Make sure you have a fair separation agreement in place from the moment you form your business.

We’re partners of Lombardi, and we’re avid users of their BPM software, as it is one of our preferred tools.  And we use the coach designer all the time, but I’d like to take a moment to propose a “Top Ten” list for improvements I’d like to see in the coach designer and UI generally.  The coach designer was originally conceived to have the product better support the agile methodology of the professional services team at Lombardi – and it succeeded in that.  It makes building UIs that display, edit, and leverage process data trivial to build.  However, like any good old friend, it also has room for improvement, and as friends, we’d like to put our ideas down on paper (bytes?) for what Lombardi/IBM should consider in their roadmap for the Coach Designer.

1. Either adopt a 3rd party standard UI framework for component-izing UI controls, or add component-building capabilities to the Coach Designer.  Presently, you can build template controls, but they aren’t first order library components (Teamworks authors will know what I’m referring to).
2. Provide controls and control-flow for building mashup UIs.  This is already possible via a html controls in Teamworks, but too much of the code ends up inside the coach, rather than abstracted in the service layer.  Intalio’s mashup editor is one example to look at, but there are lots of others (including inside IBM), which could be leveraged. I think the key is to consider how to make this interact with the service layer in Teamworks, because the end-product to display in the UI may depend on a series of external calls rather than just one client-side javascript call-out.
3. Ajax as a native capability.  Sure, there are a couple of controls that can be populated or pre-populated via Ajax calls to Teamworks services.  But the Ajax calls need to be modeled in a way that can be seen in the Activity/Service modeler.  The way to make really rich Ajax interfaces currently obscures a lot of what is going on in javascript code.
4. If you look at some of the open source solutions out there- they are working to support existing forms development frameworks, rather than developing their own.  This might be the path of the future.
5. Perhaps easy integration of GWT, YUI, etc. so that they can be first class components in the Coach Designer.  After all, GWT is heavily used by blueprint, so we know Lombardi has the in-house talent on the toolkit to put it to work.
6. Access to tasks should be opened up considerably – available via RSS feed, or via twitter. SMS text to my phone.  Give me options.  No more notification-by-email or go-to-the-browser-page.
7. The process instance could be viewed more as a stateful webservice, which I can manipulate through web services calls even more than I can today through the external activity interface.  These external mechanisms of advancing the process should interact seamlessly with internal mechanisms (for example, if I push a close-activity event from a webservice, it shouldn’t require the model to be different than if a user closed that activity from a Teamworks Coach – and I should be able to force the process to soak up the outputs from the active activity rather than ignore them).
8. Break the portal up into component pieces that are accessible as UI fragments or as webservices.  But don’t just replicate the exact portal functionality for each of those pieces – because some of that functionality really doesn’t make sense once you separate from the portal at large.  Really think about the API someone would want, not just the API required to support the portal/coach functionality today – there is a gap there. (technically the portal isn’t a coach… but maybe it should be)
9. Make it easier to skin the Coach Designer with whatever look and feel makes sense.  Currently its easy to change color scheme, but not very easy to change structure and size of elements, etc.
10. Keep investing.  If you make the right investments, you can get a multiplier effect – meaning, the investment will give process authors more power over the UI, at less development and maintenance cost, to the development team.  If you make the wrong investments, coach designer will become a closed system incapable of building the right kinds of UI the processes require.  But no investment could be worst of all – as no investment in the Coach Designer could mean that customers and consultants abandon it altogether as the cost of building UI’s outside of Teamworks continues to decline as the tech improves.  The right investments will let Teamworks ride on the coattails of these outside technologies at minimal cost.

I’m sure other people have their own ideas.  And I could write a similar list for other products.  Maybe at bpmCamp next week other attendees will have better ideas than mine for their top ten!  Welcome your top-ten comments below!

Ok ok, what could possibly be interesting about Hadoop-based systems and Mathematics?

Well, it sounds fancier to say Hadoop-based system… but really this basic math applies to any batch-oriented system and those of us who have been writing batch processing solutions now-and-then for the last 20 years should at least be intuitively aware of the math presented in this article, if not consciously thinking about it at design time.

The key equation:

Runtime = Overhead / (1 – {Time to process one hour of data})

Or, stated differently:

Runtime = Overhead + {Time to process one hour of data} * {Hours of data}

Where hours of data and runtime are equal.  These equations help explain why a perfectly healthy batch processing system can suddenly fall tragically behind – if the time to process an hour’s worth of new information is greater than an hour, you have a problem – and the problem will just keep getting worse until you:

• Improve the runtime of the algorithm
• Apply more resources to your server / cluster.
• Filter the incoming data better (if possible) to improve your signal to noise ratio and thereby eliminate unnecessary data processing

In the BPM and CEP worlds, often that third bullet is a key element to improving performance – it doesn’t require more hardware – it just requires you to move your filter “upstream” from your BPM infrastructure to your EAI infrastructure or your ESB infrastructure… or from your EAI/ESB infrastructure to the source of the noise… Some would say this is squeezing the balloon, moving the bottleneck elsewhere, but actually, filtering better up stream may make those systems more efficient as well (if generating the payload and calling out to a webservice or ESB requires cycles, then not doing it as a result of an efficient filter may well reduce processing cycles… )

At any rate, its a good read.  Andrew Paier, figured you especially would get a kick out of this article, given our experience back in 2003…

bpmCamp 2010 @ Stanford has sold out!  The waiting list is open, however, and we’ll evaluate additional attendees on a first-come-first-serve basis if we get any cancellations.

We’re looking forward to seeing 40 participants from at least 11 companies, plus independent practitioners.  Topics of discussion will likely include:

• Teamworks 7 and upgrading
• Scaling Teamworks 7
• “Process Debt” and BPM programs – creating and removing process debt
• Delivery Challenges: Moving to BPM Software Delivery (Value Driven) from a Waterfall experience base (Plan Driven)
• BPM Requirements Analysis – How much is enough?
• UI frameworks with Teamworks
• Teamworks and Rules
• Teamworks and Systems of Record
• A/B testing and BPM
• Myriad additional technical and project and process-improvement topics

We’ll continue to revise the agenda topics and schedule as we approach the first day of the conference – and we’ll continue to accommodate new ideas even during the conference.  Look for more on the conference as it approaches, and afterward we’ll share some of our impressions and nuggets of wisdom that we’re able to glean.

Tom continues to update the world with jBPM updates – in this case, using jBPM 4 and Drools to blend process and rules. His updates definitely play to the technical audience rather than the business – but I don’t find that too surprising in the open source world.  From a technical perspective, it is certainly interesting.  Proof that these memes seem to emerge on their own : Bruce Silver has also recently posted on rules and BPM (part 2 of a previous effort).

At some point I look forward to digging into jBPM more thoroughly, and now that it supports BPMN 2, I’m more inclined to make the time, its starting to get interesting for the kinds of problems we look at.  However, I still fear that it is just a bit too technical in terms of what it requires of process authors still.

A previous update confirms that jBPM now supports BPMN 2.0, as of version 4.0.  This is a niche I think open source can help fill – potentially fully implementing a spec that probably won’t be fully implemented by any commercial software vendor.  (Filling out the corners is just the kind of academic exercise that seems to get tackled by *someone* within an open source effort)

Chris Dixon recently wrote that the next big thing will start out looking like a toy.  No, he’s not presaging the rise of toys as the next trend in retail or tech (although, with 100,000 Apps on the App store and 3billion downloads, one could be forgiven for assuming that that would be his point).

Chris is pointing out that the next big thing often starts out looking like a toy because one cannot accurately predict how something simple will behave when it achieves network effects due to scale.  And this is why incumbents often don’t identify the next big thing very quickly – because they dismiss it as a toy (at first).  In fact, I’d say they often go through a few stages of denial:

1. It is just a toy, not worth wasting time on
2. It will only work for a certain niche
3. It will never scale
4. It will never work for enterprise customers (or, it will only work for well-heeled consumers)
5. It will never solve the really high end problems
6. Buy a competing product, or buy the original

I’m sure someone could come up with a better list than mine, however.

Time to register for bpmCamp …7 days left to register, and we’re nearly sold out.

Man. Steve Blank writes some great stuff.  Makes me wish I had gone to epiphany back in the 90′s!  He explains that if you’re going to go work for someone, make sure they have big plans, plans to grow the enterprise – because that growth is what you will benefit as a member of the team.

I thought his IMVU example was pretty interesting.  He mentions Will Harvey and Eric Ries (of Lean Startup fame) as being cofounders who wanted to swing for the fences and turned down buyout offers.  So, being me, I click on the link for Will Harvey – and I see he is at “Finale | Fireworks” along with Chris Hondl.  What a blast from the past.  Will was the TA of a Motorola 68040 assembly language class when I was in college (Stanford CS 110 if I recall) and Chris was the star student in the class.  We had a “robot simulation” game where we programmed the strategy for a robot to interact in a maze.  Mine was one of the four finalists, but Chris’ was a class above the rest in terms of the elegance of design and economy of action. Chris went to work with Will at Sandcastle, and most of us in class were fairly in awe of Will for his chops as the writer of music software for the Mac.

There are times when you realize it is a small world.

At bp3, we’re building a business process company, just like the tag line says, making no little plans.

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

Or is it?

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

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

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

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

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

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

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

[ fade to black and then the lights return ]

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

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

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

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

Good article from Connie Moore of Forrester yesterday, on assessing the BPM market the day after the Savvion news broke.

As she points out, these deals are important because of:

• Convergence of BPM types
• Clear signs of expanded interest in BPM by big players
• Closer integration of several business technologies (BPMS, BAI, etc.)
• Better BPMS from IBM
• More acquisitions and consolidation to come

Connie goes on to give her impressions of Pega, Appian, and other pure plays and innovators.

Like Connie, I think there’s still a lot of room for innovation in the market as the creative-destructive capitalistic processes continue.  She also took time to point out that many of the acquirers do not understand that there is more to BPM than software- there is a methodology and discipline of continuous improvement that most software vendors simply don’t have, and don’t appreciate (at least, as it pertains to their customer engagements – they may very well practice continuous improvement inside their own organization). I think this acquisition activity is going to put further demands on service companies to bridge the gap.

It looks like Nexus One may not be the iPhone killer after all (despite all the Google ads running on TechCrunch these days)…

The first quote:

Flurry is estimating the Nexus One only sold 20,000 handsets in its first week. That means the Droid, with an estimated 250,000 units sold in its opening week, outsold the Nexus One by more than 12 times. The myTouch 3G, with 60,000 units outsold it by 3 times.

Ouch. And people were non-plussed with Droid and myTouch numbers… But it gets worse.

The iPhone 3GS sold 1.6 million units in its opening week, according to Flurry, which means it outsold the Nexus One by a “staggering” 80 times.

So, even if these estimates are off by 2x or even 10x, these aren’t stellar out-of-the-blocks numbers… I think it was too much to expect their first couple of efforts to out-do the iPhone. Story embedded below, courtesy of Business Insider.

BP3 will be moving into new digs come February 1.  Doing this move at the beginning of the year feels like good timing too.  A new year with new goals and objectives – and new professional space to go with it – very much a fresh start but with great foundations. Choosing a new office space is important, because it can affect your firm’s personality.  Is it a space people want to come to work in?  Is it a space that promotes collaboration and a professional environment?  We’ve definitely found such a space in the Plaza 7000 building in Austin.  (I should point out that we have a modest space within this fine facility, lest the picture give a different impression)

I’m pretty psyched about the new space as I think it will be a better work environment and offers some better nearby amenities, along with room to grow.  Of course our needs are modest, but most importantly, the new office is still near a local Starbucks…  Some people have asked me in the past – why have office space at all?  After all, we travel a fair amount to client sites, we don’t always get to work out of home base.  And then there is the expense.  But I think the explanation is simple: we’re building a company – a team – and that requires working together, sharing and collaborating.  And sharing workspace is part of building a community and team and having a center of gravity.  The virtual forms of communication are all great, and useful, and keep us connected with our team members who aren’t in Austin, or who are on the road.  But it still helps to have a home base.  The cost is minimal compared to the benefit.

You’ll find us at the corner of Far West and Mopac at the Plaza 7000 building in Austin after February 1st, though mail will continue to forward for some time from our old mailing address. I also want to thank Red Velvet Events, who will be helping us coordinate the move, and will be subletting space from us in the new building.

I think nearly everyone thinks it was a mistake for IBM to position Lombardi as being “Departmental BPM” as a way to explain how it fits within their BPM offerings.  The proof that it is a mistake is the flurry of blog posts from competitors slamming Lombardi’s offering as being “only departmental” and unable to scale (and using the Savvion acquisition as further excuse to return to this argument about Lombardi as well).

Dr. Ketabchi of Savvion is quoted by Jason Stamper’s blog:

Second, we made sure our BPM is enterprise BPM — Lombardi, Metastorm and those others are departmental BPM. Our BPM is event-centric and supports event-centric patterns, decision-centric operations, case management and so on

And there were shots from Appian and Cordys.  And then this from Pega’s Alan Trefler:

Clearly, departmental-focused BPM companies stalled during the recent tough times. Is it okay to finally say that departmental BPM is not able to satisfy growing customer needs for real business change? Frankly, the best evidence comes from the acquiring company itself, which sees only tepid growth from the Savvion buy, forecasting only an additional $20M in revenue and 2 cents of profit…

I understand the positioning going on, for sure.  However, Savvion was bought for considerably less than Lombardi (final #’s will, I’m sure, be revealed in an IBM release or 10Q). And both Lombardi and Savvion were smaller than Pega in terms of revenue, but this ignores Pega’s history as a company before they rebranded themselves as BPM – they were a larger company before they started throwing BPM out there as a market they were in.

Still, I think the down-market positioning of Lombardi (and Savvion) as “Departmental” BPM isn’t really fair.  This is “marketing” positioning by IBM, and not a reflection of what Lombardi has been doing for the last 10 years – and if it is a go-to-market strategy to spread the use of BPM bottom-up, that’s not necessarily a bad thing.  But if you consider major financial institutions running their entire loan process through Lombardi’s BPM “departmental” then so be it.  If you consider running all order-to-cash through Lombardi as departmental, so be it. There is a difference between marketing and technology and product.

Are there departmental solutions abounding? of course.  Are these spreading within the organization?  yes.  Lombardi’s toolset makes it possible for a department to solve problems because Lombardi’s software does not require a team of 20-50 people to get deployed – a small team with a small amount of IT cooperation can get a process up and running very quickly.  However, that isn’t to say that these processes can’t grow and scale – or that enterprise-level processes aren’t addressed – and at BP3 we’ve worked on some of the very biggest of these deployments.

I hope IBM/Lombardi will address this positioning once the acquisition is complete, I think it is hurting the BPM market to have the technology denigrated unnecessarily.  Of course, as a solution provider, we’re happy to use any software package to address our customers’ process problems, including Pega’s (or Savvion/Progress, or Appian, etc.).  But as a firm that isn’t a software vendor, we’d like to see the competition accurately represented and portrayed.  Not all technology is equal, but this department vs. enterprise stuff is really just marketing fluff, with no basis in fact.

Two articles caught my attention recently because there is an interesting synergy between the two.

In the first, Mike Gammage argues that BPM is the best career move for the next decade.  He makes a compelling argument: that BPM is the key to rescuing process management from silo views and project perspectives.  Others would argue that BPM saves the business from IT (or at least, saves its processes).

Mike’s take on why BPM:

• They are owned by the business, and are in the language of the business. They embed ownership of process management and process improvement in the line, where it belongs – not with IT or the Quality team or a Process group.
• They are truly the DNA of the business. They are holistic and integrated models of the organisation, so the impact of any proposed changes are understood and can be properly addressed.
• They deliver for the end user.They combine ‘live’ business processes with real-time KPI metrics, documents and e-Learning. They are personalised and delivered to every desktop across the enterprise in the language of the end user.
• They enable change. They underpin Lean and Six Sigma programmes, and foster a culture of continuous improvement. They provide a common language for collaboration between IT and the business stakeholders.
• They are governance frameworks.They are secure and auditable. They can force acknowledgement of process change, and ensure that every process and document is properly authorised.

Not a bad list at all.  The second article I read, makes the point that we are now a white collar country – more than half of us have white collar jobs now (actually, 60%).  And that manufacturing jobs are declining globally, not just in the US.

Really, it should be no surprise that final assembly is the least valuable, and the design genius of Apple the most valuable, work that go into an iPod, iPhone, or (coming soon!) iTablet. It’s been that way all along.

And this could explain why Dell’s prowess for logistics and final assembly eventually ran its course- once the logistics and final assembly were commodotized by its competitors, they didn’t have the investment in design to retain pricing power.

The interesting thing about this article is that usually, when people opine about the US becoming a “knowledge worker” economy it is with some wistful regret about the jobs and ways of life lost, as well as a concern that we’re ill-prepared to compete in such a world (due to our education system, etc).  But the author takes a more optimistic view – that we will compete well in the new knowledge economy but that we’ll have our work cut out for us.  He may just be right.

Well, as predicted, the news of IBM acquiring Lombardi was quickly followed by more acquisition news:  today Progress Software announced an acquisition of Savvion.

I can’t say that I’m surprised – adding BPM is a logical step for Progress, and has been for some time (in fact, they were a good technology partner for Lombardi when I worked there).  BPM could help progress sell more than one product in one sale -because the sale is more about a solution to the process problem than it is about a specific product.

The price tag is certainly reasonable – $59M essentially.  Feels more like a technology buy than a business buy, but then, Savvion was also considerably smaller than Lombardi at time of sale (when I joined Lombardi, Savvion was much bigger than we were, and Staffware was the “800-pound gorilla”, but Staffware got picked up by Tibco, and Lombardi grew faster than Savvion in the meantime).

Sandy Kemsley’s analysis is that the most likely opportunity is CEP + BPM (since Progress has the Apama CEP offering).

Bruce Silver worries that this is the beginning of the end of BPM:

If we go back just a few years, four vendors on the business-centric end of the BPMS landscape stood out by empowering business to play a direct role in process implementation:  Lombardi, Savvion, Fuego, and Appian.  Their software featured model-driven design based on the BPMN standard.  It encouraged a new agile iterative design style based on business-IT collaboration rather than tossing business requirements over the wall.   Where most BPMS vendor projects operated in a bubble disconnected from their customers’ larger business process modeling and analysis efforts, these four vendors stood out by saying it would be better to unite them, to put business at the center of BPMS, not just at the center of process modeling and analysis.  If Smith and Fingar’s 2002 BPM: The Third Wave was the vision, these four vendors came closest to fulfilling it.

What a great way to sum up the concerns with the string of acquisitions.  In the comments to Bruce’s post, Appian’s CEO does a little grave-dancing, which continues in his own blog posting.  One might argue that he doth protest too much “we are not for sale!”  He tells some stories about how the founders’ work ethic.  I have to tell you, Mr. Calkins, that these stories do not make you unique among the BPM vendors, by any stretch.  I think it is these qualities of determination (and often sacrifice) that allowed the four companies named by Bruce to get to the size they each achieved – but determination and hard work is not a guarantee of any degree of success, just one of the necessary ingredients.  Similar stories are in the lore of these other BPM vendors. Mr. Calkins paints the outcome as being Appian vs. Pega for BPM dominance. It will be interesting to see if he’s right, or if the stack vendors (one or more of them) will double down on their investments.  The key thing that the larger vendors have that has been very hard on the pure play vendors is a much larger sales channel through which to move product – resulting, in many cases, in a customer already having a competing product before you even talk to them.  And then you have to prove your product is enough better that they should buy a second BPM tool.  That requires a sales staff worth their commissions, and an R&D team that is nimble and efficient.

John Pyke, of Cordys (and formerly Staffware), offers his assessment of both the Lombardi and the Savvion buys. Understandably, it isn’t in his interest to look favorably on either one.  He discounts the value of the Lombardi and Savvion offerings to the companies that acquired them. Of course, he discounts the value of Staffware to Tibco too.  Interesting to say the least…

Tony Baer’s take is that pure play executable BPM’s days are numbered.  He may be right.  But some of his explanation doesn’t reflect what we’ve learned at BP3 from deploying BPM in the field.  As he puts it:

Consequently, it is not simply the usual issues of vendor size and viability that are driving IT stack vendors to buy up BPM pure plays. It is that, but more importantly, if you want your BPM tool to become more than documentware or shelfware, you need a solution with a real runtime. And that means you need IT front and center, and the stack people right behind it. Even with emergence of BPMN 2.0, which adds support for executables, the cold hard facts are that anytime, anything executes in software, IT must be front and center. So much for bypassing IT.

Well first, these tools were hardly documentware or shelfware.  And the execution of processes can be achieved with these tools (in fact, it is the whole point of these tools).  Tony infers that execution requires IT to be front and center – but I would argue that this is a straw man that isn’t relevant. If IT is front-and-center and delivering the right value and process to the business, I’m sure everyone would be happy.  The holy grail of BPM is that business and IT can speak the same language with respect to business process requirements.  That even after the requirements become a deployed system, someone from the business could still look at the BPM models (which are actually executing in a model preserving approach), and understand them.  Never was IT going to be out of the picture, but for the first time in a long time, the business could be involved in a meaningful way, rather than a “throw those requirements over the wall” way.  The rest of his analysis I can’t take issue with.

In yet another forum, Jason Stamper has a great article and a few quotes from executives at Savvion and Progress. Dr. K takes shots at Lombardi:

Asked to summarise Savvion’s key differentiators from the BPM competition, Dr Ketabchi said: “The first thing is the extent and scope of our functionality: for example our BPM comes out of the box with a business rules management system, which Lombardi does not. IBM has the Ilog business rules but there is no integration between Ilog and Lombardi.”

“Second, we made sure our BPM is enterprise BPM — Lombardi, Metastorm and those others are departmental BPM. Our BPM is event-centric and supports event-centric patterns, decision-centric operations, case management and so on,” Dr Ketabchi told me.

Well, I just would guess that if Lombardi was only departmental, that Savvion would have sold for a higher price than Lombardi.  I would have been more interested in how Dr. K would see the new combined entity competing with the new terrain of providers, rather than rehashing the old Lombardi-Savvion debate.  I think being part of Progress gives Savvion new life and potential relevance in the BPM space, because Progress’ other offerings are well-respected in the industry.

Finally, Neil Ward-Dutton of MWD Advisors, weighs in with his analysis:  Progress is looking for acquisitions to help grow the business, and organizing around a new principle called “organizational responsiveness”.  A Savvion acquisition fits.  As Neil writes:

The obvious challenge: until now, Progress had a number of assets (Apama, Actional, DataXtend, etc) to help companies capture and analyse intelligence about changing conditions and customer interactions – but it had no direct way to tie this to a system to help customers drive responses in business processes. The Savvion acquisition plugs this gap – and at the same time, it helps Progress more directly engage business executives in conversation.

This reminds me of several years ago when Cognos was partnering with Lombardi to build a new application suite that would combine their existing strong analytics with the ability to actually effect change in the process or organization (what they previously had was rear-view mirror insight, without a direct tie-in to go-forward decisioning).  Unfortunately Cognos was purchased just before that solution saw a General Availability release.  But the story sounds familiar and relevant to me.

As an expert service provider in the BPM space, we just hope that BPM continues to evolve and improve – and hopefully these acquisitions will bring some new capital and resources to bear on the BPM space.  If not we’ll have to wait for another generation of products, or for open source solutions, to carry the torch.