As regular readers know, I am a fan of Clayton Christensen
, author of The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail
. Christensen is the one who first coined the phrase disruptive innovation
, which has become almost a cliche these days for anything "new" in the world of technology.
But when we say a certain innovation, or a certain technology, is disruptive, what does that mean? Disruptive of what? Disruptive to whom? Without a clear explanation, the term is ambiguous.
This became quite clear in a presentation that I gave to a client. At one point, we used the word "disruptive," and several individuals in the room grimaced. One of them spoke up and said something to the effect of, we are a conservative organization--we're not sure we are ready to be disrupted. Ironically, this is a high-tech company, at the forefront of its industry in terms of innovation. Yet, when it came to its own information systems, the word disruption
was not viewed as a good thing.
Should our client have been concerned? I don't think so. Go back and read Christensen's book. In it, he is quite clear that the disruption caused by a new technology is not disruptive to technology buyers
--it is disruptive to technology sellers
, especially the sellers of older technologies that are replaced by the new technologies. In fact, buyers find the new technology anything but disruptive. They find it simpler, easier, and cheaper to use. It is the sellers of the old technology, which is more sophisticated, more feature-rich, and more expensive that are disrupted by the newer, cheaper, simpler technology.
The vendor's responsibility
This thought came back to me last week when I read a post by my friend and associate Vinnie Mirchandani, who attended, as did I, SAP's user conference in Orlando, Florida. In Sapphire Now: Innovation at the Edges,
But if there is plenty of innovation at the edges, the core [SAP's core products, such as ECC and the rest of its Business Suite] still seems fairly static. The lightbulb still has not gone on that if on-demand functionality can be delivered for sub-$100 a user a month, there is little justification for on-premise price points to be 10, 15, 20x that. That if Apple and Google and amazon can build mobile ecosystems of hundreds of thousands of applications and games with a cottage industry of entrepreneurs, SAP cannot continue to magically expect its current SI and outsourcing partners to match that speed or those price points. If small teams can build fairly ambitious HANA applications part-time in a matter of days, SAP’s and its partner’s project time scales need to be similarly compressed. if on-demand benchmarks are showing frequent upgrades and importantly instant propagation throughout the customer base, SAP cannot afford to have old-school and grudging multi-year customer base migrations at the core.
That is SAP’s next big challenge. It has picked up a whole bunch of hammers and sickles as it innovates at the edges. It now needs to use them to bombard the core.
Now, I have no argument with the thought that SAP needs to transform its core products with the same technologies that it is using to develop its new "edge" products, such as its line-of-business applications. In fact, SAP co-founder Hasso Plattner and board member Vishal Sikka emphasized this same point in small group discussions I participated in.
Where I do have a different point of view, however, is with any thought that SAP's existing customers would be well-served by a disruptive transition of SAP's core products. Call it the curse of the installed base or whatever you want. But the fact is that thousands of organizations use SAP's core products to run mission-critical systems that support their businesses. SAP cannot, and should not, disrupt or otherwise undermine the investment that those customers have made. Whatever SAP does in the way of innovation, it should do so in a way that preserves and extends those customer investments.
It's not that SAP doesn't know how to rewrite its core products. It's already developed a full ERP replacement built on a true multi-tenant, in-memory SaaS platform: its Business ByDesign product for small and mid-size businesses. And it is using the same platform to deploy its "edge" products, which Vinnie refers to. Ultimately, it intends to migrate functionality from the core to these new technologies.
Lest anyone think I'm an apologist for SAP, please search this blog for posts I have written about SAP since 2002, the majority of which are critical of SAP. But on this point, I respect what SAP is trying to do.
The customer view
Customers of SAP, Oracle, and other legacy vendors are in a difficult position. Many, such as the client I referred to earlier, see value in new technologies, such as mobile applications, cloud computing, and in-memory analytics. But the value does not justify a complete replacement of their core systems, which may be stable and meeting their basic requirements. Why replace those systems? How can the customer extend the value of those legacy or core systems, while at the same time acquiring and implementing new technologies?
Rather than focus on acquisition and implementation of a new technology just because it is new, I would prefer to focus on business value. If an old technology has value, why replace it? If a new technology is not cost-justified, or not justified for strategic reasons, why implement it? If an existing technology is already implemented, what is the business case for change?
That is the need that SAP (and Oracle, and other vendors with large installed bases of customers) is trying to address. It's not easy. In fact, one might say that if SAP can meet this need, SAP would be quite innovative. It would be like allowing a driver to swap out the engine while the automobile is moving down the highway at 75 miles-per-hour. I'm having a hard time thinking of an example where a legacy enterprise software vendor has made such a transition.
So, what most companies, especially large companies need is incremental innovation: implementation of new technologies for new applications, while at the same time preserving and extending the life of their existing systems, while over the long term incorporating these new technologies into those core systems. The alternative--ripping and replacing those core systems--is painful, expensive, and, yes, too disruptive for most organizations.
SAP innovating with cloud, mobile and in-memory computing
When smartphones disrupt medical devices
The inexorable dominance of cloud computing
The disruptive power of open source