Sunday, May 29, 2011

In defense of incremental innovation

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, he writes:

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.

Related posts

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

8 comments:

vinnie mirchandani said...

Frank, we may be talking different semantics. See this video I did at Sapphire starting around 20 minutes in when the conversation turns to SAP http://bitly.com/koVtfP

It's more about efficiency or if you will operational innovation around how core SAP modules are being run today.

Vijay Vijayasankar said...

Frank, I agree.

I also question who judges innovation. My rant here http://andvijaysays.wordpress.com/2010/05/07/software-companies-innovation-and-on-premise/

Frank Scavo said...

Vinnie, that's a good interview. I had not seen it previously.

You make the point in your interview that SAP should focus less on new innovations (e.g. mobility) and focus more on helping their customers become more efficient/productive in their back-office systems.

My question is, are those really mutually exclusive objectives?

But your larger point, that SAP should exert greater control and influence over its ecosystem--I couldn't agree with you more.

For those that have not seen it, Vinnie's interview is here:
http://siliconangle.tv/video/vinnie-mirchandani-sap-sapphire-2011

The whole interview is worth watching, but skip down to minute 20 for the part on SAP.

Frank Scavo said...

Vijay, good post as well. Thank you.

Great meeting you at Sapphire.

Vijay said...

Thanks Frank - enjoyed meeting you at SAPPHIRENOW too

Matthew King said...

SAP ECC is holding its ground because it offers comprehensive functionality without all the interface headaches that come with a distributed application landscape. It also accommodates heavy duty customization - in which most SAP customers have invested millions.

If SAP can successfully transplant ECC onto SanssouciDB - it will be a case of migrating functionality from Edge products into the Core rather than the other way around. And all that custom code can live on and be replaced only as business processes change.

The reunification of ERP...

vinnie mirchandani said...

Frank, they are not mutually exclusive but SAP has not shown ability or willingness or both in removing inefficiencies around the core. There's $ 80 bn a year. To me the best innovation it could deliver is to dramatically reduce that. Been saying for a while but they thought I was making it up - now we have benchmarks from amazon, Apple, salesforce etc that in so many operational aspects their partners are not just inefficient but obscenely so

Matthew King said...

Vinnie, I enjoyed watching your interview.

I think SAP's trendy edge products go a long way - for those customers heavily addicted to the core - in making them feel better about their addiction. Still addicted - but to high quality stuff!

Some reasons for this addiction and for operational inefficiencies include:
1. High automation (efficient process but expensive to change).
2. Real uniqueness and superficial uniqueness (resulting in years of elaborate customization, expensive to replace or re-train staff).
3. Lack of risk taking (no one ever got fired for buying from a major vendor).
4. Centralized decision making (standardization placed ahead of best practice, large decision making committees).
5. Tightly coupled design (shared objects - everyone needing to be consulted before a change is made).
6. Excessive use of system as governator (rather than trusting managers to manage).
7. Over-managing risk (not knowing when to transport from test system and when to change in production system directly).
8. Organisational scale (interconnected business processes across multiple business units and geographies).
9. Application complexity (functional differences of each industry imposed on every customer).
10. Isolation of duties (design team isolated from build team isolated from support team).

And each time an organisation moves to reduce a cost burden – it often reduces its ability to be adaptive - which in turn increases its dependency on the status quo.

Note that many of these things are self imposed - rather than imposed by the software vendor.

There are many ways to avoid these issues, but it is hard to dig oneself out of this hole when one is already in the hole.

If SAP can transplant ECC onto their new in-memory database (whether requiring a ground-up rebuild or not) they will have a lot of takers.

In other words if a customer can’t dig their way out of the hole – build them a nice house (or basement) in the hole – upon which subsequent levels can be easily built.

If SAP was to agree, how quickly would they act? How much would it cost them? Why bombard the core if can be transplanted? Why pull it apart if edge functionality can be built into the core?