Acquiring Lombardi's Priorities

  • September 11, 2013
  • Scott

Horace Dediu wrote this for the Asymco blog, about Microsoft’s acquisition of Nokia:

When a prosperous company buys a struggling company you have to wonder what they’re really buying.

Here’s how to think about it. A company is defined as the sum of three values: resources, processes and priorities (RPP). Everything of value can be classified into these three categories.

When one company buys another it’s the equivalent of one set of RPPs trying to engulf or swallow another set of RPPs. The simplest (naïve) interpretation is that an acquisition is the purchase of Resources in terms of customers, sales, profits, etc. It might be of assets like employees, intellectual properties, brand etc. I say this is naïve because Resources are the easiest to value because they can be measured and valuing only what can be measured while ignoring what can’t be measured is deeply mis-pricing.

This is a really interesting analysis that ensues in his post.  I highly recommend reading it in its entirety, because through the lens of this merger you will see some insights into other mergers.  As a result, I couldn’t help but think about the IBM purchase of Lombardi in 2010.

Clearly IBM was buying Lombardi partly for the Resources- the measurable numbers of revenue, employees, etc that came along with Lombardi.  But with regard to Processes and Priorities, let’s take a deeper look.

Dediu points out the value of processes is sharply discounted by the market, which doesn’t perceive their value:

When buying a set of Processes, a buyer may see a bargain because their costs for building a similar process could be enormous, even infinite. In the case of Nokia, the process of building hardware may be infinitely valuable to Microsoft as they have had dreadful luck doing it themselves. But they’re seen as value free to the market because it seems that there are many others who are building hardware.

I don’t believe IBM thought it needed Lombardi’s processes, nor valued them much.  IBM has its own software development processes, its own services processes.  For a time, IBM gave the Lombardi folks the opportunity to run professional services more like Lombardi ran services.  And there was some evidence of success with the approach, but it has been gradually re-integrated with IBM’s larger services approach, and the march of generalizing the skills of the consulting force apparently must carry on.

However, I think IBM discovered a process that was working well within Lombardi’s team… but I have a hard time separating it from the priorities discussion so we’ll come back to it.

With regard to priorities, Asymco’s analysis seems to apply to the Lombardi acquisition:

Priorities are the answers to the “Why” question as much as Resources are the answers to the “What” and processes are to the “How.” If you were to think in terms of software engineering Priorities are the “Specifications” where the Resources are the data and Processes are the algorithms. They determine the direction and reasoning of why a company even exists. If you have bad specs, it never matters whether the algorithm is efficient and you have all the data: you are building the wrong thing.

IBM wasn’t buying Lombardi to change IBM’s priorities – but I believe it was looking to change the priorities of the BPM product group. To import the priorities of a company that was winning in the market and competing well against IBM at customer sites.

Acquiring Priorities is also fundamental in that they are usually exclusive. […]  So if you’re acquiring a set of Priorities, it’s likely that you’ll have to discard your own. It makes most sense when a company which might otherwise be prosperous needs to change direction.

This almost perfectly describes the situation IBM’s BPM offering was in.  Over the next two years, IBM’s BPM offering looked more and more like Lombardi’s BPM offering.  IBM successfully combined its product development process and human resources with Lombardi’s priorities for product design and market fit.

So, in a way, an acquisition of Priorities is almost a reverse acquisition. The acquired is actually “buying” the acquirer. The acquired company’s Priorities (and hence Processes and Resources) become the guiding principles in the acquirer. It’s what happened when Apple bought NeXT and may have happened when Disney bought Pixar.

If you look at IBM BPM today – or indeed the entire Smarter Process offering – the stamp of Lombardi DNA is all over it.  And that’s not a bad thing.  Lombardi’s priorities – simplicity, excellent design, and focus on the business – have led to a great improvement in IBM’s offering and competitive position.  Spiritually the Lombardi priorities have carries forward in BPM, even when the personnel have changed.

But there’s also a sign that IBM discovered that Lombardi had some element of process that they adopted as well – as in the design process itself.  The products continued to follow Lombardi’s approach to design (not just the output, but the process to produce that output)…  The priorities and the process were in alignment, if that makes sense.

Meanwhile, IBM has now put that together in the IBM Design Group that Lombardi alum Phil Gilbert is running.  The intent is to impact priorities across a much broader swath of IBM product development – and at a corporate level to elevate the importance of design across the board.  And the other goal is to impact processes – to create, sustain and impact product design processes that will produce great design work for many years to come.

In a very real sense, IBM might have gotten a better deal than they realized when they bought Lombardi (including getting BP3 as a partner!)…



Related Posts
  • October 18, 2017
  • Scott

The Institute For Robotic Automation defines RPA as: Robotic Process Automation (RPA) refers to automation wh...

  • October 18, 2017
  • Ariana

Headless BPM from BP3 on Vimeo. In this video, Carmen Galicia walks through using external user interface...

  • October 10, 2017
  • Ariana

Planning Your Project Roadmap from BP3 on Vimeo. In this video, Andrew Paier talks through getting started ...

  • DavidChassels

    An Interesting perspective but at core is fact that likes of IBM do not initiate real innovation they rely on “acquisition”. It suits the presentation to financial markets on both sides but and it is a big but it leaves them vulnerable for a “disruptive” technology to wipe out such huge investment. IBM were right to have stayed out of ERP and right that “BPM” linked to MDM will be next generation Enterprise Software. You guys at Lombardi did a good job and as you highlight it was a a good move.

    However the BPM market in supporting technology needs to change to greater flexibility quicker delivery supporting adaptive capabilities removing coders from building custom solutions. BPMN will slide into history as will “standardised processes” and “declarative” will move in building custom applications v quickly which will leave that painful write off and catch up. Its all now coming out here in lively forums

    If BP3 interested get in touch our model is different those with domain knowledge will build IPR v quickly in next generation “Adaptive Applications”…..?

    • I think it is too simple to say that IBM relies only on acquisition. They do a ton of innovation in software and hardware (chip) areas and in basic research
      (a lot of which happens right here in Austin, so I have a front-row seat). But they are not a startup. In the same way that Microsoft has a “strategy tax” on their projects, IBM has a “globalization tax” – localization, internationalization, security – that startups don’t have to the same degree. There’s also an “integration tax” as they cobble together disparate companies they’ve purchased.

      Hardly a unique problem for IBM, but if you compare to HP, or Oracle, I think you would say IBM is pretty innovative 😉 Just not always in the areas we want them to be.

      There’s still lots of room for innovation in BPM , no doubt about it. The question is whether IBM becomes one platform among several, with the innovation “above/around” it, or whether the platforms themselves continue to evolve quickly

  • David Ogren

    After reading Horace’s post, I was struck by a lot of the same ideas. Obviously Lombardi didn’t change all of IBM, but it certainly made a deep mark on the Websphere brand.

    Lombardi was beating IBM in the BPM market not only because of the technology, but also because of Lombardi’s approach to BPM. And while, at first glance, this might sound like a “process” issue, it was really a matter of priorities. Lombardi just had much different values than IBM, and those values showed up in both the sales process and the product design process. In the beginning, IBMers just dismissed this as “having good demo guys” and “better demos”, but it really was much more about understanding business value.

    • David – couldn’t agree more. to the extent that the process was different, it was different because the priorities were different. Values inform action. One of the challenges for BP3 has been to distill the best of what we liked about Lombardi, and then improve upon it where we can. In one sense you could say, we’re the warm face for our customers- smoothing out the rough spots, adding value, and making it vastly easier to be an IBM customer.

      More to come on that front… we’re close to inking a deal that will make it even easier to do business with BP3 (and IBM).

    • Noe Banda

      “After reading Horace’s post, I was struck by a lot of the same ideas. Obviously Lombardi didn’t change all of IBM, but it certainly made a deep mark on the Websphere brand.”

      Truer words have not been spoken about what happened and what continues to happen in terms of the acquisition of Lombardi by IBM. While Lombardi did have an impact (not really disruptive as much as strategic in my mind), if taken holistically, IBM’s WebSphere world was transformed only in terms of the places where the win needed to happen. Product design and engineering to be exact, while the other peripheral entities within WebSphere were left largely ignored or at minimum were not given as hard a push as other areas were. What that meant was the proverbial “new wine/old wineskin” approach from those periphery IBM WebSphere groups.

      Because it was strategic to pick where to influence IBM WebSphere, it led to a success at this point where success needs to be measured. A great BPM product from a research and development giant.

      • Thx Noe- and good assessment of where the “win” needed to happen and happened. I see evidence all the time that IBMers have picked up the torch to some degree in terms of priorities for the product and the goals. The lead time from idea->prototype->dev plan->product release may be longer than in Lombardi days but there is a lot of stuff in flight.