John Reynold’s post on Activity Data, from a process participant’s perspective, is just too comprehensive and good not to devote a short, sweet post that cross-links to his article. If you think about what went wrong with your last activity implementation – it was likely that you weren’t considering the full list of things that John lists here.

Good article by John Reynolds on the age-old question:  is Programming Hard?  We’ve often argued that BPM suites make implementing processes easier by giving the business and technical participants in process implementation a common language for discussing the process.  It doesn’t mean that BPMN is ideal for either party, it just means that it helps bridge the gap in communications between them.

Another key concept is to understand the fundamental entities that the process is interacting with, and to model their lifecycles and attributes, from a business perspective. Modeling both can lead to a fuller understanding of the process problem.

John sums up the point pretty well:

That’s the key to making “business” programming easier… Build more tools that help programmers and their clients “make their maps” and build more software engines that “follow those maps”.  This isn’t a new idea – software modeling tools have been around for decades, but they’ve often lost their way and focused on modeling the software engineering aspects rather than the business requirement aspects of the problem.

That’s the key – because these tools have to be built by software engineers, they often turn introspective and lose sight of the end goal of being more inclusive – because by facilitating communication and consensus on requirements, we’re facilitating “easier” software development…

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.

John Reynolds’ has a good post over on his blog on Programming Language Sociology and he draws connections between his work in the C++, Java, and BPMS communities.

I have slightly different biases… My early experiences with C++ were using standard template libraries to generate “typed” lists of objects for a class on C++ in college.  At the same time, I was taking a class on NextSTEP programming (CS193d) which employed objective-C.  I discovered the elegance of having all objects respond to standard messages, and I experienced first-hand the “problems” that C++ purported to address with heavy-handed solutions.  Many of those “problems” weren’t really high-occurrence defects for me, as a programmer – paying the price for a solution to a problem I didn’t have!  (as an example, take the strongly-typed list container…) So I was never a huge fan of C++, but unfortunately (for me), it won the battle over objective-C.  (The silver lining, of course, is that Apple’s platforms for both the Mac and the iPhone make heavy use of objective-C, so I can at least enjoy a renaissance of objective-C in the mobile world)

I considered Java as a language a step up from C++.  I think it better-addresses modern programming problems – machine portability, connecting to remote objects and services, memory management, etc. It isn’t that there aren’t great applications for C++, there are, but Java better addressed the next set of challenges.

You could consider BPMN a “language” that addresses the current (for John Reynolds and I, and for many in the IT space) problem space of business process definition and implementation.  As John says, part of what makes the BPM tools exciting is that they are good tools for speaking the language that solves business process problems.  The tooling has a long way to go to meet our expectations of what it will do for us in the future, but it has come far enough that there is no longer any excuse for putting off BPM implementations, waiting for a better mousetrap.

A couple of posts on this subject recently, one of them by my good friend John Reynolds (Process Manager Interoperability).  Keith Swenson made a reference to the Wf-XML spec as being relatively little-known and he wasn’t kidding – neither John nor I had heard of it previously and no doubt part of that is because the name says nothing about what it can accomplish for you.  The letters “Wf-XML” just don’t say anything about what this spec will do for you (allow you to start, monitor, and react to the completion of a process run in another system/environment).

As John points out, it seems higher probability that consumers of BPM technologies will benefit more from technologies that help with interoperability between those BPM tools, rather than from the more complicated task of actually migrating those implementations across BPM tools.  Of course, the SOA camp ca well claim that they solve this problem – but it isn’t the service-oriented nature of the interface that is the problem – its having a purpose-built standard for the design pattern of two independent process platforms communicating about the state of a process instance (or subprocess instance).

Jim Sinur of Gartner poses this question in a blog post the other day.

Actually, he phrased it as “Is XPDL 2.1 on the Edge of Becoming a Dominant Process Standard”.  I think the answer is a “no (not yet).”

(this may just be because my definition of where the edge is, or what dominant means, is different than Mr. Sinur’s, or it may be because we disagree on some of the background material – either way, here’s my take)

Some arguments in favor of XPDL are cited by Mr. Sinur, and by others (Keith Swensen in a previous post as well), and by WfMC.  The primary argument in favor is the portability of the activity models.  And, a pretty inclusive vendor list that supports XPDL.

I’m not against XPDL at all.  I won’t even mind if it becomes the dominant process standard. But here are the arguments working against it for now:

1. First, keep in mind that these portable activity models are stripped of their execution attributes/elements – those elements are not, according to Mr. Sinur, part of the portability of XPDL 2.1.
2. Second, the processes that are ported are also devoid of the implementation of human activities (and typically, system activities), which are presumed to be implemented outside the BPMN model.  (See John Reynolds thoughtful post on this subject here)
3. When I look at the “implementations” of XPDL on the list above, I found a few problems with it:  the references aren’t dated (and may, therefore be out of date or obsolete), and several of the implementations are for tiny pieces of the software or companies being mentioned, and don’t represent full support of XPDL.
4. According to Gartner, the two leading BPM vendors are Pega and Lombardi.  I looked through that list and I couldn’t find either of them on the XPDL bandwagon.  If the two leading vendors in the space don’t find it necessary to support the standard, then I’m doubting that it becomes the dominant standard.

All that said, XPDL could still become the preferred format for model exchange if BPMN 2.0 doesn’t fit the bill.  Or Gartner could ratchet up the pressure on the vendors that haven’t supported XPDL so far to begin doing so – by weighting that support higher on evaluation criteria for the next Magic Quadrant (though that is quite a ways off, it probably gives these vendors no excuses if they haven’t delivered it by then).  Currently the vendors not on the XPDL list seem to be waiting on the BPMN 2.0 to be released.  If that spec doesn’t live up to the billing, I can imagine vendors supporting XPDL for model interchange as a backup plan.  But I don’t see those vendors investing in two solutions for interchange if they don’t have to.  And I can’t see calling a format a “dominant” format if the leading vendors aren’t fully supporting it.

I think the portability of XPDL, and the compliance tests they’ve put together, are a big step forward for the BPM community.  But that conclusion is regardless of whether XPDL in fact, dominates over BPMN, or vice versa.  Either way, the BPM community wins.  Because I’m sure some of the enterprising XPDL vendors will come up with a mapping from BPMN2 to XPDL 2.1… (These XML formats do lend themselves to being translated after all…)

I’ve read a couple of articles recently related to business process visualization.  I think this topic is particularly interesting because most people think they have what they need once they buy a BI tool or a good enterprise reporting tool (and there are several that are quite good).

But the thing that makes process visualization so interesting is the context of the process in which the data is generated.  John Reynolds’ Thoughtful Programmer blog has a good post on the topic of Visualization.  In it, he makes a few great points that should resonate with anyone pursuing BPM excellence.  The dream that everyone working in a business will not just understand the activities for which they are responsible, but the role of those activities in the business processes they impact.  It has been shown that feedback loops improve performance by focusing on how individual performance affects overall results.

John also hits on another favorite of mine:  the idea that the same model should support views/layers/aspects that allow different users to understand the model and interact with it ways that are different, but compatible (and enabling).  He also references Phil Gilbert’s dream of BPM on every desk in an enterprise- which makes sense when you think how most processes are executed today – via email/paper/fax – and every single desk in an organization is involved in its business processes… they just don’t have the right tools to support the processes they execute (at least, in many cases!).

So, I think John does a great job of making the case for why visualization matters.  But I think if one hasn’t read his other posts, you might miss some of the context:  that the reason this visibility matters is precisely because of the process context.  It is the lack of context that makes using existing BI and reporting tools challenging.  You can get the data, but does your IT staff know when (in the process) to collect the data? Can the business articulate this need to IT?  Often these decisions are driven as much by convenience as by design because no one has the right answer with respect to the process.

Another issue to discuss with respect to visualization is the lack of standards.  While some vendors use very easily read/used/manipulated data formats for their process information, they are still considered to be “proprietary” formats by customers and the industry (proof that the definition of proprietary continues to evolve.  Once upon a time, just having your data accessible in a published relational database schema was considered being “open” rather than “proprietary”!  Now, if you don’t adhere to some industry standard schema you are closed or proprietary… even if such a schema doesn’t exist yet… )

This brings me to an article on The Business Process Analytics Format (BPAF).  Good read, and a good reminder that there are folks out there trying to put standardized formulations around the Business Process Data that feeds into analytics.  I’m encouraged that the format appears to be consistent/compatible with the tools I’m familiar with, but of course some of the terminology could use a BPMN overhaul (or at least a primer for those who are more familiar with other BPM* standards).

For example, there is a focus on the Business Process Audit Format XML… Which has a defined Business Process Analytics Format Event. In isolation this is a good naming convention, but I think it would help everyone see the relevance if the standard also related this Audit event to where it might occur in a BPMN-defined diagram – is it a standalone event in that diagram, or is it an artifact of other items in the diagrams – and if so, which ones?

Even without this context in terminology, BPAF might turn out to be important.  After all, if you can standardize on what a measurable “event” looks like, then you can actually build analytics that are cross-vendor and consume BPAF compatible events.  Eventually you  could have standard analytic packages… But of course the goal isn’t to have standard packages… the goal is for people who run businesses (and manage processes), to be able to visualize, comprehend, manage, and improve their processes.  That makes visualization central, if not the heart, of what will make BPM relevant to every desktop in the enterprise, even if it is dependent on delivery of executable processes to have full process context in that visualization.