Hint: it wasn’t about tech, or product overlap, or filling product gaps.

Brian proposes that the acquisition is actually about market, channel, and the great unknown (the end game).  The market is big and growing fast, and the companies within this market are small and growing fast (even the laggards).  This inevitably ends in some kind of merger frenzy or pileup (check out what happened to the EAI vendors 10 years ago, or CRM vendors 10-15 years ago).  Brian claims none of the technical issues matter – I’m not sure they don’t matter at all, but he makes a pretty strong claim that they might be irrelevant next to the market and business forces at play.

Second, he points out that the channel strategy is key.  As a Lombardi partner, we can attest that Lombardi was putting a fair number of partners into the field, and doubling down on that strategy in 2009.  We attended a very diverse partner conference in April that was affirmation of the strategy for both Lombardi and the partners.  But the bigger issue is – IBM has a massive channel of sales and partnerships through which to push product and solutions.  In the 90′s I saw IBM acquire Tivoli, which I believe was about $100M in revenue at the time, and in less than two years, it was generating $700M in revenue out of that business unit.  IBM can definitely turn the crank on certain software categories (past performance being no guarantee of future returns).  If Lombardi BPM gains a certain mindshare within that channel, then IBM will reap huge returns off of this acquisition.  Brian argues that this is the key driver of the acquisition.

Third, the end game – Brian argues that because no one knows what it will be, it makes sense to place more than one bet.  Again, he makes a compelling business argument for why investors (and companies) won’t be satisfied with just one offering that touches on the BPM space.

Its a good read, highly recommended, and I’ve also cross-referenced it in my running blog post on the acquisition.

Lombardi just posted a thankyou to their customers on their blog. Kudos to Lombardi for a 10 year run in which they had an out-sized impact on a big, emerging market.  Best of luck to IBM and Lombardi moving forward.

Keith put together a pretty interesting chart reflecting business process technologies over the last few decades, showing how they relate on a spectrum from predictable to unpredictable, as well as how firm the consensus about how to use the technology has become.

Keith Swenson, Thoughts on Collaborative Planning, "4 Process Trends & 1 Gap"

As usual, Keith presents a good thought model.  But of course there’s a gap that may or may not be real – it is Keith’s perception of the gap between manual (email) processes and workflow-based processes.  I think there are actually a range of technologies inbetween these two approaches-  ticketing systems, case management, and wikis are all examples of technologies that address the space described by the gap.  Still, I always find this kind of graph thought-provoking: it organizes your thoughts in support or in contrast to a particular point of  view.

A recent entry from Joshua Baer, a local entrepreneur in Austin, TX, on the subject of turning complainers into champions, struck me as especially appropriate given the season.  We’re many of us experiencing how companies handle customer service issues right now: returns, especially, are an opportunity for companies to turn complainers into champions.  Delayed flights, or bad experiences traveling, likewise.

A hotel executive once told me that every mistake or customer problem was actually an opportunity to build on the brand by fixing it aggressively for the customer and engaging with them – that when customers *don’t* complain, it is actually hard to win them over to being champions. I recently ordered a laptop bag from Ebags and when it wasn’t quite what I was expecting, the return process was painless, and *free*.  I’ll definitely consider ordering from them again.

Josh’s experiences with OtherInbox serve as the examples for his presentation – and I can attest that their customer service is excellent, as I’m a user (and former complainer) of the service myself.  I didn’t quite “get” how it interacted with Gmail at first, but once I did, I became a convert and I’ve recommended it to others, such as Keith Swenson. There are lessons to learn from this approach, even if you don’t run a consumer-facing business.

Merry Christmas from BP3 to our customers, partners, vendors and colleagues.  Hope everyone is having a wonderful holiday season!

What a great post by Steve Blank, yet again, as he reveals a classic cautionary tale from start-up land (“The Elves Leave Middle Earth – Sodas Are No Longer Free”).

It’s about the Sodas no longer being free.  Seriously.  Coke. Diet Coke.  Mountain Dew.  No longer free.  Free drinks are part of start-up culture and lore, and it is just one of the little perks that founders do for their companies when they themselves are interested in free sodas too.

Shouldn’t matter, right? But it does:

But the damage had been done. The most talented and senior engineers looked up from their desks and noticed the company was no longer the one they loved. It had changed. And not in a way they were happy with.

The best engineers quietly put the word out that they were available, and in less than month the best and the brightest began to drift away.

Worse, as he sat there in the board meeting as the free drinks were getting canned, he was amazed that none of the experienced VC’s in the room objected, or pointed out the folly of this change in policy – from free drinks to paying 50 cents.

Steve was amazed that they didn’t speak up.  But I’m not.  Its like Marvin Haggler once said: “It’s hard to get up and do roadwork when you’re wearing silk pajamas.”  The VCs have forgotten why free drinks matter to engineers.  They’ve forgotten what “road work” is like.  Its surprising that Steve Blank still remembers it so clearly (perhaps the academic/historian part of him hangs on to these memories).

As Steve recalls it:

Then the new CFO got up to give her presentation – all kind of expected; Sarbanes Oxley compliance, a new accounting system, beef up IT and security, Section 409A (valuation) compliance, etc. Then she dropped the other shoe.

“Do you know how much our company is spending on free sodas and snacks?”  And to answer her own question she presented the spreadsheet totaling it all up.

There were some experienced VC’s in the room and I was waiting for them to “educate” her about startup culture. But my jaw dropped when the board agreed that the “free stuff” had to go.

I sure hope Steve spoke up and let them know what a mistake they were embarking on.  I know he wasn’t on the board, he was a guest – but all too often I’ve seen bad outcomes come to pass because no one felt comfortable or felt it was their place to speak up for what they thought was right…

I lived through one of these transitions as well, but for our firm, it really was the beginning of the end – not just a sign for people to look around, but a sign that the management of the firm had dramatically changed their priorities to reflect a new, tougher, economic situation, and the layoffs that were about to come.

I’ve long been familiar with server-side Javascript because, while at Lombardi, we used Rhino’s javascript engine on the server for all kinds of server-side computing tasks.

Why would we use server-side javascript?  Well, recently Read-Write Web has produced an article about the “return” of Server-Side Javascript.  As the article proposes, this idea was often derided in years past, but it makes a lot of sense for BPM, and for applications in general:

Point 1: “Given that you’re already using it in the browser, why not stick it in the server too? One language all the way down makes it easier for a single programmer to work on either side of the wire; there’s less of a mental shift.”

Point 2: “There’s also a promising reuse story for this “dual-side Javascript” scenario. Take form validation for example. Right now, it’s common to write the same logic in two different languages. In Javascript, you write a validator to give the user immediate feedback inside the browser, and in a language like PHP, you write a validator to ensure data integrity once the form data has been uploaded to the server. But once you switch to Javascript on the server, you just need to write a single validation routine at both ends.”

Point 3:  “Javascript performance has also moved forward in leaps and bounds, thanks to browser competition.”  Seriously, javascript performance has improved about 40x over the old days.

Point 4:  “Server-side Javascript also dovetails nicely the new breed of NOSQL databases. Being web-native, these databases tend to communicate in HTTP, and in some cases JSON (JavaScript Object Notation) is the message format.”  In other words, you can already do these things with Javascript libraries rather than rolling your own code… HTML 5 just furthers this confluence.

Point 4:  its browser roots make Javascript well-suited for responding to events and manipulating the DOM… We didn’t use this in our BPM solutions but there are interesting implications for the core technology: “With Comet, the server holds on to the connection for a while, and continues to stream out information intermittently to the browser. The typical example is a two-way chat – as soon as one guy says something, the Comet server sends the message to the other guy. This is event-driven programming all over again, and compared to the usual suspects on the server, Javascript is well-placed to support this paradigm.”  Node is another example of this kind of design pattern of keeping a stream open for future events, and writing out new information to the browser.

Finally, Javascript solutions are well-suited for porting to the cloud – they can be generally easily isolated from the OS, hardware, etc., and replicated across identical server instances or virtual instances (or even run in a multi-tenant mode).

Its interesting that a language that was once only deemed suitable for doo-dads in the browser, is now becoming the primary language of interesting web applications (in many cases, thanks to underlying tech like GWT, extJS, YUI, etc.).  In some cases Java is the primary language and the javascript is generated (GWT) but that isn’t always the case.

It is a little known advantage of Lombardi’s approach to BPM that javascript is the server-side scripting language-  the integration to Java is trivial, as is access to XML, and XML-based APIs.  And its convenient that most everyone knows Javascript and there are easy online resources to use to pick up syntactic details (e.g. www.w3schools.com ).

There’s been a lot of coverage of what it means for IBM to buy Lombardi.  Jaisundar proposed that this would upset the balance of power and cause more acquisitions… But perhaps the side effect he (and others) didn’t foresee was the positioning of the remaining BPM vendors (pureplay or otherwise) for the benefit of their suitors.

First we have Appian’s CEO posting here.  I don’t blame him for putting a stake in the ground that Appian is going to win, and positioning that the only two vendors left that matter are Appian and Pega.  Savvion might disagree, as would a few others, but nevermind.  He states that they’re the only ones strong enough to survive (by which, I would suppose he means financial strength, but he leaves that as an exercise for the reader’s imagination.  I don’t blame him for slagging IBM as killing innovation – in any acquisition like this, that is a very real possibility, and will determine whether this is a successful buy or not (at least, for folks who don’t work for IBM).  But methinks he doth protest too much, and may be trying to make sure that potential suitors remember that Appian still exists in case they want to get in the game by buying something.

Next, we have ActionBase, one of my favorite non-traditional BPM offerings.  In a previous post Jacob Ukelson made the argument that Sharepoint should be a better BPM tool than it is.  Now he argues that Sharepoint + Actionbase is that BPM dream team:  unstructured content + unstructured process… If that isn’t a pitch for Microsoft buying a nice Sharepoint add-on I don’t know what is.  Analysts are frothy thinking about how Microsoft or SAP might want to counter IBM’s move, and this is one option.

I’m not sure that unstructured process + unstructured data is the dream of every IT shop, but it is certainly a combination prevalent in many processes and organizations.  And of course those two offerings could work well together.

So it looks like everyone is putting on their finest Holiday Sweaters and looking to make a good impression for their potential sweethearts.  It’ll be interesting to see if there really is a wave of acquisitions or if this is it.

Its the creative destruction process of capitalism at work.  I just hope BPM doesn’t get lost in the woods in the process.

Rashid Khan, formerly of Ultimus, asks the question:  is BPM the jack of all trades and master of none?

It is certainly a fair question.  As he points out, BPM is broad, maybe overly broad.  And he also points out that based on the punditry, you would expect BPM to be a much bigger market than it is today.  Of course, part of the problem is that many companies, wanting to leverage the BPM banner, will relabel what they do as “BPM” and this can help stifle the growth of the real BPM providers.

He then outlines four challenges for vendors:

1. The market, defined as the sum total of all the things BPM can address, is very large.
2. No single vendor or product can address the entire market. And if they try to do so the product becomes bulky, expensive and hard to maintain or upgrade.
3. Customers have a very hard time discerning what BPM solution is best suited for their needs. And if there is one product that will suit their needs, it is unlikely to meet some other needs in the same organization.
4. Vendors are unable to say no to opportunities that potential customers define as BPM but do not fit in the profile of what the vendor can deliver. BPM products always have recourse to customization via programming which theoretically can be made to do anything, albeit at the cost of agility. So vendors pursue opportunities that may not make sense.

Its hard to argue with these points – points 1, 3, and 4 I can agree with without much reservation.  And #2, I would say it is actually a tough choice for the vendors:  either bulk up the product to address these markets, or keep the product more focused but leave a lot of work for the customer to adapt the product to their needs. Either path is risky.

Rashid proposes that vendors focus on horizontal slices of BPM (e.g. modeling, or workflow automation) and interoperability, in order to solve the focus problem, and in order to help customers answer the “what does it do” question…

But this conundrum affecting BPM affects the software business as a whole.  CRM companies wonder if they should also be sales process companies, and vice versa.  MRP companies became ERP companies.  ERP companies became “Stack” vendors.  And before ERP was well-defined, there was a lot of jockeying for what was “in” or “out” of ERP.

The key economic forces compelling software companies to broaden their offerings are:

1. The need to avoid getting flanked by a competitor who does your focused product, but also does other products.
2. The need to flank your competitors in similar fashion.
3. The need to get the most value out of your sales force overhead that you can – more products to sell means that the sales rep has more opportunities to take advantage of their good relationships by selling more software.

These are essentially sales-efficiency arguments-  you have spent a lot of money on your sales force.  So what you can you do to extract more expected revenue from them?  Either:

1. Increase the odds of winning a deal (flanking/positioning)
2. Increase the lifetime revenue per customer (more software products/licenses to sell)
3. Increase average sale per transaction (more software products/licenses to sell)

So these forces are pushing software companies to broaden their offering with either features or products. Simultaneously, the approach of having a narrow focus is risky:  if you can’t create a compelling differentiating advantage for your horizontal slice, then you can get disintermediated quite rapidly and easily.  But if you CAN build this sustainable competitive advantage, and get the market to recognize it, then you can build a nice moat around your product line and really benefit from your focus.

The other trick is – say you only sell the optimization piece – and it is designed to work with various BPM tools – if you are early in a market’s development, you could face the very real risk that the customer isn’t even sold on BPM software yet, let alone your specific tool.  You still have the problem of explaining BPM to them, and getting them to realize that it could be of benefit.

I think as the BPM market gets larger, there will be interesting horizontal and vertical opportunities for software companies to say “look, here is the better mousetrap for optimization” and to then show how it is better than the existing solutions and get it sold as a value-added piece of the puzzle.  This is (roughly) how scheduling software was briefly the darling of enterprise software in the 90′s – before all of the fast-growing scheduling companies hit the wall and were acquired by larger ERP companies.

It looks like BPM may already be big enough for a good horizontal BPM modeler to come along and steal the show – but one wonders if that play will be a commercial or an open source play?  Similarly, a process engine could OEM into other BPM software vendors, if the market gets big enough.  But I think that expecting customers to piecemeal these solutions together is asking too much these days of their lean and mean IT departments.  The integration will still have to happen with the vendors.

What’s really interesting is, if BPM vendors have trouble with the broad scope of BPM… what does that say about the vendors who consider BPM only a checkbox on their list of 1000 products?  They’ve got to compartmentalize if they’re going to realize the focus they need.  Or, I guess you could buy Phil Gilbert and Lombardi to get that “vision and focus” thing you’ve been missing… I’ve always thought the main barrier to stack vendors “getting” BPM was (a) a lack of focus, and (b) lack of believing that such focus was necessary or worth it, and really it isn’t a lack of technical know-how or capability.

So, any BPM vendors out there following Rashid’s advice and getting more focused, more narrow?  or staying narrowly focused?

I’m pleased to announce that Apex Consulting and bp3 will be co-sponsoring a free dinner for attendees of bpmCamp 2010 @ Stanford on Thursday, January 28, 2010. We want to welcome anyone who can attend bpmCamp to also join us for dinner and conversation afterward.  Thanks to Dave Knapp for offering to co-sponsor dinner with us, we’re looking forward to it!

Location and logistics will be announced before the event.

And if you’re reading about the news that IBM acquired Lombardi, not to worry:  bpmCamp is on, and there’s even more reason to be attending now, to keep abreast of the latest developments and make connections with a broader community of practitioners.

The news hit the wire this morning (early for me, as I’m sitting in San Francisco this morning).  I got a phone call at about 5:20am PST to give me the news (thanks, I think?!).

The Lombardi press release touts a shared belief in customer success, a good product and culture fit, as well as good ole market opportunity:

“Any discussion on business improvement inevitably leads to improving the processes that are at the heart of every company,” said Craig Hayman, general manager, IBM Application and Integration Middleware. “Recognizing this, IBM has strengthened its presence and investments in business process and integration software to meet these growing client demands. Lombardi fills out our company’s portfolio in this key area.”

Lombardi already supports Websphere, and  was an early adopter of the app server in the BPM space (I can testify, I was there with Lombardi’s first Websphere clients).  In Austin, we’ve certainly seen a history of IBM successfully acquiring and expanding software companies that were acquired (Tivoli and Webify come to mind).

I’m sure there will be more news as the day(s) go on, I’ll try to just keep this post updated with the latest, unless something comes up that deserves an entire post on the subject.

Congratulations to the Lombardi team, who have been breaking ground in the BPM space for years now, and yet staying focused on making customers successful, not just on the latest bell or whistle on the product road map.  I think there’s a good chance, depending on the structure of the takeover, that some of Lombardi’s DNA will rub off on the BPM-focused parts of IBM.  I can see the effect Webify has had on IBM’s efforts, and I always thought Lombardi’s and Webify’s products would make for an interesting combination. Now we’ll get to find out, I guess!

More to come…

IBM press release here.

UPDATE: 12/16/2009 7:20am PST
Keep up to date with what the analysts (and others) are saying on Twitter:

And then we have a post from Phil Gilbert on “The Second Decade of BPM“. Phil’s take on where BPM is headed, with an interesting look back:

I can’t begin to convey the impact this will have on how and where BPM will be practiced, going forward. In the blurb above on this blog site (which was posted when I started this blog in 2005), I said that by 2010 process will be the primary prism through which large companies view themselves; and that by 2020 the management of process will be “second nature.” The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.

Phil has a pretty good sense of the big picture.

Second, because Lombardi has focused on the business user, we have also focused on how to engage and support the business user. The work we’ve done on culture, change management, governance and BPM methodology is the best in the industry. Lombardi University and its role-based curriculum, along with tiered certifications and advanced mentoring, means that Lombardi can help IBM scale their business customers more quickly into the world of BPM. Lombardi’s On-Demand Assistance program is also built from the ground up to allow fledgling BPM teams built on business-first principles to still have a technical safety net under them.

This quote illustrates for me what I hope Lombardi can bring to IBM. A better understanding of how to support the business and help them achieve success via BPM, and a better sense of what BPM really could mean for the business world.

UPDATE 12/16/2009 8:45am PST
Austin Startup is carrying the standard press release.

And ebizQ has already launched a forum topic on the subject.

UPDATE 11:35am PST: More great coverage and viewpoints:
Dennis Byron discusses the acquisition, and is focused primarily on eliminating one more option from potential customers, and the inexorable force of consolidation.

Redmonk gives props to the Austin software and enterprise scene, as well as to the deal-making by IBM. The big question is how well IBM can incorporate Lombardi without losing its DNA.

Miko Matsumura posits that this might have been a firesale based on the language of the press release. Could be, Miko has more experience with this than I do. Regardless, I think the timing was good for IBM because I expect 2010 to be a big year for BPM software.

Sandy Kemsley chimes in with the best run-down of the analyst call.

Update EOD 12/16/2009:
David Moser of Australia weighs in. He points out which communities might win or lose, based on this deal going through, in particular which customers. But he also points out:

And with what should be a significant boost to their market, some of the biggest winners could be Lombardi service providers. Watch out for skills shortages.

I happen to agree, that service providers (e.g. BP3) could be well positioned to benefit because, no doubt IBM can sell more of the same product with its much larger sales channel. It takes time for people to ramp up on a BPM product. For a time I expect there will be exacerbated shortages of Lombardi BPM skills, but of course we’ll try to help as best we can!

Bruce Silver also comments on the deal. The tone of Bruce’s post (and some others) is a bit somber – I think some of the folks out there were rooting for a Lombardi IPO or for a deal that made it more clear that Lombardi would still be providing leadership in the BPM space from a “vision” perspective. There is an emerging consensus among outsiders that “departmental” is a losing strategy. I think if it is a pricing/marketing strategy it has legs – potentially target lots of smaller installations to service departments, but if it is reflected in technical direction of the product it could be a real problem. There’s no reason the tech can’t scale much bigger than a department, but its still up to IBM-Lombardi to decide what the market positioning and pricing breakpoints are.

Tony Baer’s take on the acquisition titled “Early thoughts on IBM buying Lombardi“. His emphasis on Lombardi’s chief advantage to IBM is its simplicity – making it possible to address the business directly within the enterprise. He’s looking for the integration of Blueprint and Blueworks to be a good indicator of how this purchase is going to work out.

UPDATE 12/17/2009: Well the blogs keep rolling in with new thoughts or analysis.

Jaisundar’s take is that blueprint is a key piece of the puzzle by widening the user base for BPM and creating a demand funnel. So much comes down to how IBM handles it and whether they keep the Lombardi DNA, while adding to it their massive sales channel synergies.

Meanwhile, Richard Watson has a couple of witty posts on the subject of showers (listing the # of bpm products and related products IBM has purchased as an embarrassment of riches and portfolio overlaps – but also, market clout. In a previous post, he makes the best statement about this subject: “If IBM wants to become the leader in BPM, they need to get out of the data center and start thinking like business people.” – This is exactly why people are excited about the merger, and why they’re worried. Lombardi is not stuck in the data center mindset. Will that business-focus be lost in the merger? That’s the real fear.

And Derek Miers, well-respected for his thoughtfulness on business process and business improvement, took a look at this merger and concludes:

While the choice of dance partner was a little surprising, the desire for a liquidity event in the Lombardi management team was there to see long ago. They touted an IPO around this time, but in the current market that was always going to be difficult.

IBM brings the broad base and ability to grow. Lombardi brings market cachet / credibility that is hard to quantify – but everyone in BPM knows Lombardi and they’re well-respected. Derek’s take on Lombardi’s success:

As I have said to many other vendors, when people buy BPM products, they buy the promise of success. And I am sure Lombardi’s success in the market is as much down to that aspect as it is their leading technology stack. They help their customers understand how they will succeed in meeting their business objectives (rather than touting the beauty of their technology stack).

That’s exactly the point – the culture that Lance and I (and execs at Lombardi) tried to create in the services organization was around business objectives and customer success. Something we’ve endeavored to continue at bp3.

Update EOD 12/17/2009:
Clay Richardson of Forrester Research writes up his analysis, which includes:

Ultimately, this deal centers on the need for IBM to develop a more compelling story for the business. In many ways it is further validation of the IT-to-BT transition that we are seeing within the enterprise.

IBM already had their story down for the CIO and needed to develop a more compelling story for the VP of Operations, and the VP of Customer Service, and the VP of Procurement – in other words IBM needed to establish a stronger voice into the business. And this is what Lombardi does best as a leader in the human-centric BPM space.

If he’s right, this is good news for Lombardi and its customer-base (and prospective customers). He follows up his points with Phil Gilbert’s plan to push the envelope with Blueprint even further “to collaborate on scoping and discovery for enterprise process initiatives.” As he says, IBM is weak in that area, and there’s little overlap. His basic take is that this is a capability buy as much as a technical buy. If he’s right, it bodes well for the future of BPM, or at least the future of IBM BPM!

Update EOD 12/18/2009: You thought we were done with the updates? you were wrong!

Dr. Diaz, on the IBM BPM Blueworks Blog, gives another IBM angle on the acquisition – conveying a sense of confidence and positivity in the IBM strategy.

John Reynolds, of Lombardi and soon IBM, writes a pretty good defense of the “Department” positioning – after all, what is “bottom-up” BPM if it isn’t a department level solution that scales up to meet your enterprise strategy, vs. the top-down BPM approaches that IBM has been using so far:

It’s not really a technology issue – Lombardi’s solution scales quite nicely. It’s a methodology issue… Some tools really enhance the “Top Down” (Enterprise) approach, while others really enhance the “Bottom Up” (Departmental) approach. Offering both seems like a pretty good idea when you think about it.

Update 12/21/2009:
Jennifer Dubow (@jennifer_dubow) posts a link to an IBM F.A.Q. on the Lombardi acquisition. Hits all the high points with no muss, no fuss.

Update 12/22/2009
Neil Ward-Dutton of MWD Advisors recaps the responses of vendors, which generally provide for fun reads. Of course, if you read their blogs without, somehow, realizing their corporate affiliation you might fall for their bias without correcting for it. Its only natural for competitors to see this as an opportunity to try to steal a march while IBM / Lombardi are distracted by integrating two companies – but having been on the other side of this – it didn’t often work as well as we would hope – often the buyer was able to keep the momentum going in the 12-18 month timeframe.

Update 12/29/2009 Jim Sinur weighs in with Power Vendors vs. Pure Plays, positing that the Power Vendors are catching up. I don’t see the catch-up that Jim is mentioning, but I do see catch-up-by-aggregration and the question is whether any of the remaining pure-plays have enough heft to out-innovate the big guys. Obviously small vendors with a tight focus can continue to outpace bigger players in their niche, but the wide Pure Play field has been thinned with this acquisition…

Update 12/30/2009In the ProcessMaker Blog, Brian makes one of the most compelling statements about why IBM bought Lombardi (and although he didn’t address why IBM bought other Business* companies – e.g. iLog, FileNet, Cognos, Webify, etc. – the same logic applies quite well). The short version: it is about addressing markets, not technology. And if Lombardi addresses a particular market, and is scaling, then IBM can plug that into their vast sales and partner channel and really wring value out of it. The thesis rests on the assumption that the BPM market is hot – but that’s a safe one.

Update 01/06/2010 The debate spills over into 2010. Neil Ward-Dutton reprises his previous review with a more considered analysis and the summary is that perhaps IBM really is buying Lombardi to get a better “business-facing” solution – but that they just don’t want to admit that blatantly in their external positioning. Its an interesting read.

Update 01/08/2010Gartner’s Janelle Hill and Jim Sinur report on the acquisition for Gartner. Basically they advise getting ready for a move to Websphere if you aren’t on it already, in a timeframe of two years, and tout the BPM DNA acquired in the Lombardi acquisition.

Andrew Chen asks this question in his blog.  Its a good read from several perspectives, but I’ll just pull out the couple of bits that people developing processes should be thinking over well and good (I like to read the work of thought leaders outside the BPM space to see how their ideas might apply to BPM):

Back to Steve Jobs – what does he really do?
Long story short, my hypothesis is that Steve Jobs is one of the rare CEOs who is very focused on product desirability. In battles with the business and technology goals, desirability will almost always win out.

And what is “product desirability”?  It sounds like understanding the “voice of the customer” to me (but broader than typical six sigma definition of that term).  Having an understanding of what will matter to your customers is a key driver for success for your processes.  The definition of customers is a bit vague :  users, primarily, but also people impacted by the process (often, your end-customers)…

• What makes your process desirable to your customers?
• What makes your process desirable to your internal users?
• Who is responsible for representing desirability of the process?

Andrew goes on to define what he surmises are Steve Jobs’ duties:

So his role isn’t that of a designer, but rather Chief Design Advocate. This means:

• he makes it clear that products should be “insanely great”
• he recruits a top design team, and protects them from competing goals
• he is willing to spend money, adjust technology processes, all for the goal of highly desirable products
• he convinces financial analysts, industry pundits, etc. that product design is very important

As Andrew says – is there any reason that any company can’t be doing this?  Or that you can’t be doing this for your processes?  Making sure the processes are great, that you have recruited a top BPM team that is focused on making the processes valuable to your customers?  Spending money, adjusting technology, to support highly desirable products?  Convince the folks that hold the purse strings that processes and process design are important…

Very few companies do this… It could be the differentiator for yours.  And there’s no reason you can’t do it.

Travel logistics have been updated, click here for details.  The short version:  we’ve secured a discount to the Stanford Guest House, which has the advantage of being on shuttle routes and being on campus… and being highly affordable.  But there are lots of other options in the area as well.

We’ve also posted some directions from the airports, and recommendations on trains and shuttle routes.

See you at bpmCamp!

Lombardi just released the December update, and it takes the previous enhancements a bit further:

• More analysis visualization work was done to make this more intuitive.
• Better printing options (print to PDF is actually even more useful than printing to a printer in most cases)
• More user administration options (this will get increasingly important as the number of Blueprint users and collaborators continues to grow.  I wonder at what point it will make sense for Lombardi to look at incorporating something like Conformity into the solution.

Having used blueprint a fair amount lately with some more complicated models (not large, mind you, but more complicated), I can see a need for the process diagramming portion of Blueprint to get some help to make those diagrams more readable.  The models occasionally get to a point where they aren’t readable because of crossing lines or all the interesting points of reference being off-screen.  This is a problem in any modeling environment, but the reason it is so noticeable in Blueprint is because it has all this auto-draw functionality that does the layout for you – so when it doesn’t do what you want, you really notice it. Not sure if smarter layout algorithms or just more user-control is the answer.

Also it would be nice if comments were more obvious (visually) on the map, rather than requiring clicking on an item’s Details to find out if it has any comments.

Also, I recently used a brainstorming tool that a customer was using to model business entities and business entity lifecycles.  Although it is a completely different style of modeling than Blueprint, I believe it would fit in the mission of Blueprint to supply a good modeler for Business Entity Lifecycle.  Why?  Because often a process is working hand-in-hand with entities that have state, lifecycle, etc.  But BPMN and Process Maps are not good at accurately capturing what those states are (not just the states that trigger something in the process, but the whole universe of states).

Pretty interesting update from Joram Barrez on jBPM – looks like it now supports BPMN2.0. (or, more accurately, it will come January 1st).

Its a pretty interesting look under the hood of one of the top open-source solutions in the BPM space.  The BPMN2 implementation uses the jBoss PVM (process virtual machine) to execute the BPMN, rather than transforming BPMN into BPEL  or JPDL or some other XML format.

jBPM also gives the developer a good Java programmatic interface into the BPM engine implementation (and, the processes it runs).

This sort of development effort does make me wonder if, eventually, we’ll have a fairly standardized open-source BPMN engine with commercial products that incorporate it in different ways (picture Apache or jBoss as examples, or the WebKit in the browser world).  Hard to say if jBPM (or key pieces like PVM) will turn out to be that open-source engine of choice, but at least from the blog posts it seems like they’re taking an intelligent and focused approach.

Its hard to keep this argument buried, as Bruce Silver demonstrates in yet another post on this subject, reacting to yet another response from the BPEL crowd.  I was going to respond directly in his post here, but for some reason I couldn’t comment on his site today.

Bruce makes the killer arguments:  only a subset of BPMN is “isomorphic” to BPEL.  Quite simply: BPMN allows the author to represent process flows that BPEL cannot represent accurately in a model-preserving fashion.

There was an argument put forth that wouldn’t these limitations be true of proprietary execution implementations as well?  And the answer is – perhaps – if those execution implementations don’t account for tricky stuff like interleaving (my experience is, that they do).  The difference (mainly) is that these “proprietary” execution implementations speak BPMN natively and were designed from the ground up to support the use cases defined by BPMN. The same cannot be said for BPEL and the engines which implement primarily BPEL. An engine could do both – but I don’t think the right answer is translating BPMN to BPEL to get there.

I’ve been reconnecting with some concepts from the startup world, such as “technical debt” – well-defined in Wikipedia, but also better covered by this article, among others.  Essentially, Technical Debt is the future cost you incur by taking short-cuts (knowingly or unknowingly) today.  Of course, we explicitly choose sub-optimal solutions in the short term in order to have a shot at a better solution later (thus the axiom “Perfect is the Enemy of Good”).  But we also incur technical debt when we inadvertently introduce defects or poor design decisions into production software.

In this The Concept of Product Design Debt is introduced (to me) by Andrew Chen (@andrew_chen).  Although the concepts of Technical Debt and Product Design Debt are not targeted explicitly at BPM projects, the concepts apply particularly well to iterative development projects, and to environments with a lot of change (in requirements and/or technical direction).  As a result, it seems that they apply particularly well to BPM.

Andrew walks through the example of Amazon’s website tabs that would grow seemingly without limit, before being refactored to something more manageable later (paying down the debt).  If you’re truly running an iterative, agile BPM endeavor, the following passage may ring true for you:

The interesting part is when you get a couple months into your product cycle. You often end up with lots of half-done experiments lying around, an infrastructure that isn’t built to scale, and a mishmash of code that needs to be refactored. Most engineers know that in this kind of a case, the best practice is NOT to rewrite your code, but rather refactor it continually and take down the so-called “Technical debt” so that it’s always under control.

However, there’s the other side of the coin, which is the product design. After you’ve added a ton of new features and stuck them all on the homepage, you create Product Design debt. The Amazon tabs at the top are a great example of this – you have a design philosophy built around tabs, you scale it as far as you can, and then you have to refactor your design.

He gives some great examples of how product design debt is introduced into production sites – but it isn’t hard to imagine in the world of process, where we’re often looking to alter our process designs to accommodate changing business requirements.

The analogous question in BPM circles is whether the experiments and changes implemented in your process have created a process debt that needs to be paid down through refactoring.  In large part, I think you could describe the process investments of the last 20 years as having created great improvements in efficiencies, but they’ve also introduced process debt over time – processes have become more complicated than necessary, manual shortcuts have been introduced “temporarily” that became permanent, and IT systems were built to support re-engineering that couldn’t support ongoing change. In each of these cases, BPM can help surface this “process debt” and offer tools for carving it down to size.  The goal isn’t necessarily “zero debt” – but the goal is to keep it from getting out of hand.

Even within BPM projects we can accrue process debt.  This is independent of the technical debt we may have accrued that is purely technical – we’re not talking about running two queries where one would do – we’re talking about the process itself.  Decisions about the process itself may be intentionally short of “right” in the short term, in order to get incremental improvement out the door.  Or the design may have unintended consequences – creating a bottleneck where one wasn’t expected (squeezing the balloon, so to speak) – or fixing errors in one area and introducing errors in another.

I think there is yet another way we accrue process debt – and that is when our organizations fail to adapt to a changing business climate.  If you rolled out a process two years ago and haven’t made any tweaks in the meantime, I believe you have acquired process debt – a steady, growing gap between what your software and processes are designed to handle, and what the reality of current business conditions requires.  After all, new products and services enter the market, new competitors enter, old competitors exit, and customer needs change over time.  In a typical organization, the organization will wait until the process debt becomes quite large, and then address it with a big process improvement project, or a new software roll-out (new CRM system anyone?).  It isn’t that this decision to invest is wrong – in fact without a BPM Suite, this may be the most rational way to deal with process debt.  But an organization focused on process needs to pay down this process debt along the way – and the best way to do it is with a robust BPMS and a team focused on BPM for the long haul, that can manage this process debt and keep it from getting out of reach.

A BPM team that intends to really build capability in their organization for process improvement needs to account for the concept of process debt, and figure out how to manage it over time (and even pay it down from time to time).

Of course, some would probably argue that there’s no such thing as “debt” – that you are simply leaving yourself with additional work to do in a future iteration.  But the argument for applying the concepts of technical debt, product design debt, and perhaps process debt – is that the “iteration” notion doesn’t properly help you capture the cost of decisions you are making now.  We’re not talking about implementing 3/4 of something – we’re talking about implementing something that we know will cause a problem (as described above), and choosing to do it that way because we’ve measured that cost against other benefits which outweigh it.  A classic example is when an integration isn’t available in time for go-live of a process – but we expect it to be in the future.  In the short term we can choose to take on that work with manual intervention (or a suboptimal technical solution).  But we’re incurring a future commitment to switch to that “correct” integration.  It just makes sense to proactively manage these commitments as “debt” to be paid off.

So.  I’ve made the argument in favor of including the Process Debt concept in long-running BPM operations.  Are there good counter-arguments to be made?  Are there problems with managing process debt the way we would manage technical debt?

To join the bpmCamp discussion, just join the Google Group below.

Membership in the Group also gives you full editing access to the bpmCamp wiki – where you can propose topics, volunteer to speak or lead a discussion, etc.

Subscribe to bpmCamp Stanford 2010

Email:

Visit this group

Recently Microsoft took over the BART subway system in San Francisco with a bunch of Windows 7 advertisements.  So far so good. Who can blame them.  Visually the ads even look reasonably good.

But when you READ the ads, they make their customers sound stupid.

Some quotes:

“I suggested they make it less complicated.  Guess what? Now it’s less complicated.  I so rule.”

“I’m a PC.  And windows 7 was my idea.”

“Windows 7:  I wanted simpler, now it’s simpler.  I’m a rock star.”

Each of these quotes has a picture of a person to go with it to lend it credibility.  But look these ads make me crazy.

First, where’s the authenticity in the advertising?  What do I mean by authenticity?

1. Who are these people that are quoted?  Tell me who they really are, if they’re supposed to represent me.
2. Did they even know they were posing for Windows 7 ads or are these just stock photos?
3. Did they have any say on what quotes would be attributed to them via these ads?  I doubt it.
4. Would a real person say these things?  Why?
5. Did Microsoft solicit our opinions on what Windows 7 should be?  I must have missed that memo or survey.
6. Did Microsoft actually get any ideas from the particular people quoted BEFORE they built the product? Again, I doubt it.

First, Windows 7 was not the idea of the gentleman pictured next to the first quote.  He isn’t holding a laptop, but he has a folio in his hand that likely has some paper in it.  He probably could care less about whether a windows 7 was ever produced.

Second, referring to point #6 above: if you watch the ads on tv, combined with the print ads, the point seems to be that there are all these “PC people” running around taking credit for something that they quite literally had nothing to do with – this isn’t normally considered an admirable trait in someone – claiming credit where none is earned.  That kind of behavior is frowned upon in most organizations of any worth.  Why aren’t they saying Microsoft rocks?  or Windows 7 rocks?  The messaging is just wrong at some basic level – painting Windows 7 fans as being some kind of socially inept patronage of low-EQ.

Third, the specific ideas, generally not touted in print, but touted in TV ads, are just plain pathetic.  And when they’re actually demonstrated on screen, they hardly look simpler or better (like the side-by side window option… something that Windows could do in Windows 3.1 by the way, using a menu option instead of drag and drop).

Microsoft, please.  Please communicate with your audience as if it is smart. Please leverage spokespeople who appear to be smart and reasonable people that I might relate to, not credit-hounds who will say whatever the marketer wants them to say.  Create real fans of your products and let them talk about why they’re fans.  Or use actors but let them make points that appeal to a discerning audience.  The current round of ads are just awful.  Cereal ads are smarter than this.  They don’t have Moms claiming that “healthy cereal was my idea! I so rock!” – they have Moms saying “I was looking for a healthier option for my kids’ breakfast, and now I’ve found it with <insert healthy cereal brand here>.”   Is it possible that Microsoft needs to hire a Consumer Packaged Goods expert from P&G and the like to remind them that they shouldn’t talk down to their customers (and worse, they’re prospects)?

Microsoft needs to be aspirational rather than condescending.

Can’t wait for these ads to go away.  Microsoft, if you’re listening, do something about it.

Registration for bpmCamp is now open.

Please Register Here.  All registrations are subject to approval to make sure that we fill our limited space with Lombardi practitioners first.  If you’re a partner or employee of Lombardi, rather than a customer-practitioner, please drop us an email (email address can be found on the bpmCamp wiki) to discuss attending and how you can help.