Interesting review from John Reynolds, of the Kindle Fire.  He’s underwhelmed mainly by the form factor, and the lack of access to non-Amazon content.

People often criticize Apple as having a “walled garden” – but if you read the following from John, and you use Apple products, the difference is obvious:

The Kindle Fire experience doesn’t feel like you’re connecting to the web – it feels like you’re looking through a keyhole into one little room of the web… or perhaps you’re trapped in a hallway with many doors and many keyholes.  Many of the keyholes are blocked.

That’s when it hit me… Amazon isn’t giving me access to ‘The Cloud’, they’re giving me access to ‘Their Cloud’.  Everything that I purchase from them resides in ‘Their Cloud’.  The same is true for Apple. The stuff I buy from Apple ends up in the ‘Apple Cloud’…  Flash forward in time and I see myself carrying both an iPad and a Kindle, juggling them from one hand to another in order to access ‘My Content’ in ‘Their Clouds’.

Actually, the same isn’t true for Apple, though I can see why he said that. Apple’s iTunes content seems to be locked to iTunes… but it isn’t.  As much of Apple’s content that they can make DRM-free has been made so – only the studio labels stand in the way of DRM-free content.  From my iPhone and iPad I can access gmail, google docs, netflix, amazon’s store, Kindle content, etc. (In fact, I don’t own a Kindle, but read Kindle books on my iPhone and iPad all the time).  The addition of “iCloud” added features and functionality to my use of Apple’s devices, but didn’t remove any.  My iPhone config can now be backed up to the cloud.  Contacts, email, calendar invites now synchronize better between devices. But I also still synch those items with Google Apps. Having said that, I like John’s vision for “MyCloud” even better than what Apple, Google, Amazon, or anyone else is yet producing:

If the Universe was fair, which it isn’t, whenever I created any content it would be stored in ‘My Cloud’.  Whenever I purchased anything it would be stored in ‘My Cloud’.  Facebook, Google+, Apple, and Amazon would have to pull that content from ‘My Cloud’ to use it in their apps, and I would set the policies regarding access to ‘My Content’.

From what John is observing, it sounds to me like Amazon has produced an “Amazon tablet” not a general purpose tablet.  There’s nothing wrong with that, per se… but I don’t think that that’s what people were expecting when they pre-ordered.

It isn’t hard to think about the analogies applicable to cloud BPM offerings…

John Reynolds writes about the curious case of the disappearing BPM Programmer:

So where does this distinction between Case and Process leave the BPM Programmer?  Are BPM skills irrelevant in the new world of Dynamic Case Management and Social Process?  Are the BPM Programmer’s skills doomed for irrelevance every few years just as the skills of System Programmers (C begat C++ begat Java begat Ruby etc.)?

Will BPM Programmers disappear into the mists of interesting but irrelevant oddities of the past?

The question arises simply because a small but vocal chorus has been calling BPM a subset of Case Management, or predicting the end is near for BPM. Does that mean BPM skills and jobs are thus in decline?

Not to worry.  BPM was always the tool not the goal.  The goal is managing business better.  As the Navy Seals would say, equip the man, don’t man the equipment. BPM is a means to an end.

Processes aren’t going away anytime soon.  Besides, as John says: “Your job has always been about writing software the Manage Business. Process is at the core of Business Management, but you always had to deal with Objects, Rules, and Events.”

Well said.  BPM is here to stay.  It didn’t burn brightly and fade away, it is a slower, steadier progression.  As you would expect it to be, if you understand what it is.  And the momentum is still building, rather than fading.  The name may change, the tools may evolve, but the goal of running businesses better isn’t going away.

John Reynolds wrote a post recently about Interdependent tasks, and the resulting complexity. John takes a simple example, the vacation approval process, and then points out what makes the difference between a cute model and a real implementation:

Sam can’t really (in good conscience) make a Decision about any Vacation Request in isolation.  Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests.  To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

And further:

Examples like these are what makes implementing “real world” processes hard.  Processes seldom execute in a vacuum, and work done within one instance often influences other instances.  Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

He’s right, of course.  This is why a demonstration of a BPM solution can look easy, but the actual implementation actually takes real work and thought.

John purposely held back from suggesting a clever BPMN modeling solution or other trick of the trade to give us something to think about. I’ll give you my thoughts on how to approach the problem.   But in a general sense, this falls back into a general process pattern:

• a process model that does a decent job of representing one process “instance”.
• another process that manages the set of all processes
• yet another process that is the maintenance and improvement of the process definition and the management of process instances collectively.

What John is describing is a variation on the second level of process.  It already goes without saying that we need to manage a set of vacation requests collectively.  The extra wrinkle is that at a step in the approval process, the process should present context to the user, that likely includes:

• All pending and approved vacation requests for other team members
• Possibly other pending and approved vacation requests for people on other teams
• Remaining vacation days for this person
• Remaining days in the year in which to use those days
• Time since last vacation

All of this information gives the Approver context in which to make the decision.  The individual process’ execution flow hasn’t gotten more complicated. But the implementation details of that Approve step got more interesting.  Luckily, the information above will be pretty easy to provide if your BPMS had reasonable tracking and introspection capabilities.  So if we simply invest some trust in our user, and supply them with the information they need to make a decision, we’ll get really good outcomes with minimum implementation headaches.

Sometimes the really interesting bits in a process implementation aren’t in the BPMN.  As John points out, we shouldn’t assume that every detail should be captured in a BPMN model.

John Reynolds, always with a different perspective on BPM, recently addressed builders and business people:

I could have built this fence myself.  I’ve done similar projects in the past, and I’m not “that” old.  It’s hard work, but not more than I can handle…  But I chose to “pay the experts” instead of building it myself.
They do this for a living… I make my living doing other things.

By now you’ve probably figured out that there’s a lesson here that goes beyond home improvement…

I am a huge fan of enabling Business folks to build their own software solutions, but the fact remains that most people prefer to pay others rather than build things for themselves.  No matter how “business friendly” our tools become, most businesses will bring in builders when they need them.

I rephrased the question:  are you the builder or the check-writer?  Like John, I pay experts to do quite a bit of work at our house that I could probably do myself (or at least, learn how to do).  An early experience in my life taught me the value of expertise – not just knowing how to do something, but the value of being someone who does it all the time. My father was going to build a deck in our backyard, to replace a very small balcony that was about to fall apart.  He had staked out the area, and went so far as to calculate how much wood and cement he would need.  He even figured out which tools he would have to buy, or borrow from our neighbor the Fireman.

My father asked a builder to come out and bid on building it.  They said it would take two days. My father wisely decided that having the deck completed all summer was worth more than “saving” money by building it himself.  My first understanding of the time-value of money.  Or in this case, of what that money could buy (a completed deck).

This is among the many reasons we don’t worry about customers – business and technical – learning how to work with BPM.  We want them to learn.  We want the tools to make it more possible and likely  that business and technical users can be successful.  And we still think there will be plenty of work for specialists like BP3.

Because, like my father, I paid a builder to put up the deck at our home – and I have a better deck than I could ever have imagined building for myself.  (Quit laughing John!)

John Reynolds, commenting on Sandy Kemsley’s blog, where she was writing about Shell’s BPM success story:

Note that Sandy’s tale mentions Templates, but it doesn’t say a thing about Frameworks… and to me that’s very significant…

As a Professional Programmer, my life revolved around Frameworks (OWL, MFC, Struts, Spring, etc.)  Each of these Frameworks provided a wonderfully powerful foundation on which I could build my custom applications.  I simply can’t imagine life as a Professional Programmer without programming Frameworks.

Pardon me for over-simplifying, but a Framework is something that “you bolt pieces on to”.  The Framework provides the internal structure of your program, and you can build many diverse and wonderful programs on top of any really good Framework.

If you are an Occasional Business Programmer you’ve probably found that Frameworks aren’t quite what you’re looking for.  Frameworks are really powerful and really flexible – but all that power and flexibility comes at a price – you really have to know what you’re doing to use them.

I think the narrower interpretation of the word Template is useful to the “Occasional Business Programmer”.  Of course from a technical point of view, most of what gets pitched in the BPM industry as “templates” are really Frameworks, using the definitions John uses above.  And Frameworks, as such, are problematic.  They require not only being an expert on underlying BPM technologies, but also on the APIs (programming interfaces) of the Framework itself.  For people that are more than occasional programmers, patterns will help more than frameworks – as they’ll apply to more situations.  Borrowing from a Navy Seals slogan, I think patterns “equip the man”, whereas with Frameworks tempt one to “man the equipment”.

This is a fun post from John Reynolds about the BPM Implementation Dream Team.

Rapid Iteration BPM implementation projects, like the ones that I work on, depend on “Business” to take on building responsibilities and “IT” to take on requirement writing responsibilities.  We don’t structure responsibilities like this just to make everyone feel good, we structure things this way because of the way things are:

• All Business requirements have Technical implications
• All Technical implementations have Business implications

When the business folks hit the technical hurdles, and the technical folks hit the business challenges, there’s great incentive to find “another way” that gets the team to the solution sooner.  Shared misery builds strong bonds.

The core of our ideal BPM implementation team are two individuals; the Business Lead and the Technical Lead.

I recommend reading his blog for the rest of his entertaining post.  John has a great attitude about BPM and it shows in his writing.

John Reynolds gives a beginner’s guide to Process Performance Reports on his blog.  Using Websphere Lombardi Edition, he shows a few diagrams and gives good advice regarding how to build up the tracked data for your process reports.

Of course, if you’re not using Lombardi Edition (or various versions of Teamworks and IBM BPM), you might not be able to relate to these diagrams- they include the tracking point metaphor that Lombardi introduced way back in 2004 to allow for a transparent snapshot of process instance data.  It really makes it trivial to capture snapshots and timing data for use in correlations in reports.

John does say one or two things I’d modify, such as:

Process Performance is all about “How long did it take?”.  If you want to know “How long?” then you have to know when “it” started and when “it” finished.

I’d say, rather, that this is one of the most common kinds of reports – and in IBM BPM, one of the easiest to produce.  There are other quite interesting reports that are similarly trivial to capture:

• How many of X did each person on the team process by month (or by week or by day, etc.)
• How many exceptions (complaints/defects/etc.) did we process by customer or by region (comparing performance)
• How much rework is happening?
• What percentage is going down the happy path versus exceptions?
• What is the typical # of exceptions per item?
• How many exceptions get “fixed the first time” (ie, once known, the issue is fixed correctly).

With some demographic data on each snapshot, we can really do interesting correlations (using the optimizer or your own custom reporting techniques). One of the uses of this data is to fine-tune the process.  A favorite demonstration of this capability was to look at the correlation between the size of a dispute in a dispute resolution process.  If 90+% of disputes under a certain $ amount (possibly in combination with other criteria) are being approved, perhaps it makes sense to insert an auto-approve decision rule in front of the manual activity that requires a person to look at the request and approve or deny.

John Reynolds outlines key user interfaces for BPM:

• Task Notification Interfaces
• To-Do List Interfaces
• Task Completion Interfaces
• Process Status Interfaces
• Participant Workload Interfaces
• Process History Interfaces

We could group these together around a few basic principles:

1. Executing the instance of the process (task notification, task completion)
2. Managing a set of process instances (to-do list, status, workload)
3. Improving the process itself (process history, as well as, obviously, tools provided with the BPMS that are focused on authoring)

If you’re not sure whether you’ve covered your bases for UI for your processes, John’s blog is a good place to start.  Good thoughts and explanation around each interface type.

John Reynolds, of IBM, writes:

These experiences with “Departmental BPM” are what make Irene’s recollections of Notes’ Databases resonate so strongly with me.  The ability for a small team to develop and deploy a focussed solution is a very powerful thing… and immensely valuable for the business.  It’s a fantastic “group experience”.

But just like Notes’ Databases, there comes a time when the ability for “anyone” to develop and deploy a managed business process begins to raise “red flags” for those who have to manage the enterprise as a whole.  As BPM spreads through the enterprise, the natural tendency to want to control that spread takes hold.

I’ve experienced this first hand… Early successes with BPM, run as small agile projects, attract the attention of enterprise level architects and program managers, who react with horror at the anarchy and call a halt until control can be re-imposed.

It is all too easy for IT to kill the golden goose that lays the eggs, while trying to make sure that these departmental efforts don’t get out of control.  There’s a legitimate governance concern – but like most things, if you hold too tightly you suffocate the opportunities.  The IT governance concerns should be mostly about visibility, and less about control.  Sadly, there is often more concern about control.

John Reynolds (of IBM and Lombardi fame) has posted tips for building a task-focused user-interface.  He does a great job of articulating the “iterative-playback” two-step that defines our approach to building out process UI (and process):

With this in mind, you’ll see the logic of the process that we’ve adopted:

1. Build “Just Enough” human interface to give you the ability to “step through” this activity and all of the paths of your process
2. Define “Just Enough” of your interfaces to underlying integrations to give your integration developers the information that they need to start building the “real” integrations
3. Get a fully functional task UI working as soon as your “real” integrations are ready
4. After everything is functional, then (and only then) work on making the task UI “pretty”

On that last point (step 4) – remember that “everything functional” goes beyond a specific human task – All the human tasks should be functional before you worry about making any of them pretty.

This is great articulation of the approach we pushed and developed at Lombardi between 2003 and 2007.  It looks like the team has continued to improve on the definition of this approach (including defining Blueworks process maps for it).  But I think the four-step list is easier to “grok“.

Despite the simplicity of the approach, many people fail to adhere to it. The more technically savvy the person is, the more likely they are to deviate from this process.  For some of these folks, I explain it in Computer Science terms – analogous to iterative deepening to find the right solution for each UI, and for the whole application’s UI in general.  It isn’t quite as simple as breadth-first, but it is closer to breadth first than depth first.

There is a reason for taking this approach to building process UI :

Your biggest risk in the project is that you’re requirements are wrong or misunderstood.  Your best expression of requirements is typically the User Interface.

Because of that, you need to iterate on the UI.  And if you go too deep -either by prettying or over-integrating with back-end systems – you create friction on that iterative process that isn’t required.  That adds cost and slows time-to-market.

The Problem

A good friend, John Reynolds, has eloquently commented on a subject near and dear to my heart: Leadership.  More specifically, Project Leadership vs. Project Management:

My job lets me work with talented programmers and business people all over the world.  These folks all know their jobs – the programmers know how to write good code and the business folks know how to run their business – but when you bring them together they often can’t get a project finished.

The objective of all projects is to deploy Business Solutions. Requirements grow up to be Plans, Plans grow up to be Projects, but many Projects just don’t grow up to be Solutions. Like the Energizer Bunny, these Projects just keep going and going and going… but they never get anywhere.

I blame a lack of leaders.

John has captured the essence of the problem.  The projects that become successful solutions have leadership.  And this is something we’ve written about quite a bit. BPM especially requires leadership because you’re asking different constituencies to play nice together, despite the fact that the changes wrought by BPM will have uneven benefits and consequences.  The leader can coerce, cajole, persuade, confront… and can bring the resources and willpower to the project to get it done.

Leaders: Born or Made?

I fear that leaders are born, not made (although training certainly helps improve them).  When a project is stalled, a hero can’t just “take charge” and get a project back on track.  Leaders aren’t leaders without followers.

There have been many variants of this debate with regard to athletes, entrepreneurs, CEOs, leaders.  I come down on the side of nurture more than nature.  I’ll not deny that we are each born inheriting our own gifts, bestowed by our parents.  But how we develop and hone those gifts and shore up weaknesses it what makes us the adults and professionals we grow to be.

A Solution?
How do we develop leaders?  We might first ask, how do we develop heroes?

Step 1: expose your high potential team members to people you consider to be heroes.  Let them work in the proximity of great contributors to learn what it means to be a great contributor.  Try to awaken in them an awareness of what it is that makes the hero admirable, and an awareness that they, too, could be a “hero”.  Work with them to leverage their strengths.  Let them learn by following the example set by your heroes. Give them opportunities to succeed AND fail.

If I can distinguish between a hero and a leader – a good hero “leads by example” – not by consciously thinking about leading, but by doing all the things that we would want others on the team to do.  They work hard, they are focused on what’s good for the team, the project, the company.  They care about their colleagues and will help them.

The first step in evolving a leader from a hero, is to create self-consciousness (let me explain).  We have to wake in the hero, that self-awareness that they can lead intentionally, rather than unconsciously.  The key difference is intention.  A leader intends to have the effect of leading others.  A hero may lead others but isn’t intending to do so, and may even be alarmed and uncomortable when it happens.  There is a fear of responsibility, fear of failure, fear of letting others down.  If you want to foster that leader, give them the opportunity to succeed and fail.  And invest in teaching what you expect from leaders, and what their team will expect.  It takes a fair bit of coaching or self-awareness, but people can learn to lead.  I’ve seen it happen, and I’ve seen it happen even within our own projects among the customers we work with.  Soon, someone walking the path to becoming a leader, acting with intention, will learn from the feedback loop of consequences.  They’re on the path.

This is important because, for BPM to continue to grow and succeed, we need a lot of leadership.

John has a few more important points to make:

What we need are Project Leads… People who command the respect of both the Business and Technical folks.  We need people who have met both Business and Technical challenges in their careers, and who can show all of us “how to get there”…

That’s why we lack leaders for our projects.  There simply aren’t many Business people in the world who are respected by Techies, and not many Techies in the world who are respected by Business people.

This is not by any means an easy problem to solve – but if we want success for more of our projects, we need to find more of these leaders.

This is why, at BP3, we have tended to focus on developing our technical heroes into leaders who care about business.  But we also try to make sure that they understand the value that business leadership brings to the table, so that we’re ready to embrace it when we find it within our team or within our customers’ and partners’ teams. I agree with John: not an easy problem to solve, but sometimes the ones that are worth solving aren’t easy.

This seems like a great BPM Thought for the Day from John Reynolds:

Just came across this short but sweet posting from David Novick:
BPM consultants should be SME’s in… well BPM

David’s “point” is that it’s our skill at approaching problems from the Process Perspective that provides true value to our clients.  The details of the business problems are known by our clients – Our skill is in knowing how to develop solutions for those problems through process analysis and process management.

Its a great thought.  Be a subject matter expert in BPM.  That is, after all, what our customers are asking from us.

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.