“Disruption” in the software industry
I lampoon the word “disruptive” for being badly overused. On the other hand, I often refer to the concept myself. Perhaps I should clarify. 🙂
You probably know that the modern concept of disruption comes from Clayton Christensen, specifically in The Innovator’s Dilemma and its sequel, The Innovator’s Solution. The basic ideas are:
- Market leaders serve high-end customers with complex, high-end products and services, often distributed through a costly sales channel.
- Upstarts serve a different market segment, often cheaply and/or simply, perhaps with a different business model (e.g. a different sales channel).
- Upstarts expand their offerings, and eventually attack the leaders in their core markets.
In response (this is the Innovator’s Solution part):
- Leaders expand their product lines, increasing the value of their offerings in their core markets.
- In particular, leaders expand into adjacent market segments, capturing margins and value even if their historical core businesses are commoditized.
- Leaders may also diversify into direct competition with the upstarts, but that generally works only if it’s via a separate division, perhaps acquired, that has permission to compete hard with the main business.
But not all cleverness is “disruption”.
- Routine product advancement by leaders — even when it’s admirably clever — is “sustaining” innovation, as opposed to the disruptive stuff.
- Innovative new technology from small companies is not, in itself, disruption either.
Here are some of the examples that make me think of the whole subject.
1. The best example of DBMS industry disruption is Microsoft SQL Server in the 1990s. Every time I talked with Microsoft, they asserted that Oracle would have great difficulty competing with SQL Server, because SQL Server was much cheaper than Oracle, and was offered to businesses and departments who would be satisfied with its features, in many cases through sales channels that Microsoft dominated. Microsoft also had a massive advantage over Oracle in ease-of-administration. Dan Rosenberg and Andy Mendelsohn eventually led Oracle to narrow that gap, but for years Microsoft’s administrability edge fit perfectly into the “simpler/cheaper” part of the disruption story.
Microsoft turned out to be correct in its optimism, and is now a formidable competitor to Oracle in enterprises much larger than it once appeared able to serve.
2. Oracle executed an awesome “Innovator’s Solution” response (to Microsoft and other threats). Oracle has gone bonkers expanding its stack, with massive acquisitions in applications, hardware, middleware and more. And while upstart DBMS vendors certainly get some projects Oracle would want, on the whole Oracle has done an excellent job of maintaining both margins and account control.
All good things come to an end, and I think the finish to Oracle’s glory days is closer than the beginning. But the length of Oracle’s run at the top is a testimony, in large part, to its excellent record of strategic decision-making.
That said, the end of my nicely lucrative consulting relationship with Oracle came in the late 1990s, when I sent over dire and in retrospect accurate warnings that Oracle was blowing the internet opportunity. Even Oracle’s strategies aren’t always correct.
3. MySQL wasn’t a huge success at disruption. MySQL had a textbook disruption strategy — cheap, simple, pursuing markets Oracle wasn’t strong in. But MySQL never accomplished much in Oracle’s core or semi-core markets.
Even so, Oracle went well out of its way to buy up MySQL, limiting future threats from that source.
4. BI isn’t really undergoing disruption. QlikTech and now Tableau have gained business intelligence market share by offering good-looking, easy-to-deploy systems to departments. But that’s exactly what the current market leaders did in the 1990s, and they haven’t entirely forgotten the land-and-expand model. Yes, I’ve predicted a much-needed reinvention of/revolution in BI — but better technology alone rarely a disruption makes.
5. SaaS can be a vector of disruption. Salesforce.com rode software-as-a-service to disruption of the sales force automation and customer relationship management (CRM) markets. SaaS was easy to deploy in the distributed way that field sales forces needed, and just plain easy to deploy as marketing departments took control of their IT.
I also think SaaS is going to dominate the market at small enterprises, specifically ones too small to have a lot of domain specialists on their IT staffs, on the strength of what are new business models for sellers and buyers alike. But it’s not yet clear whether SaaS vendors will disrupt many more large-enterprise software markets.
6. Netezza was disruptive:
- Much cheaper than alternatives.
- Much easier to deploy and administer.
- A smart purchase even for “departments” of 3 analysts or less.
But like MySQL, Netezza didn’t grow up to take over the world.
7. Hadoop is disruptive. For reasons of price, scale, and capabilities, Hadoop doesn’t compete much with analytic (or other) RDBMS. But it aspires to. It also aspires to compete with object storage, predictive modeling tools, and various other categories of software as well.
Hadoop’s disruptive success has already surpassed Netezza’s, and probably MySQL’s as well. How far it goes will be one of the big stories of IT’s next 7-10 years.
8. NoSQL, taken together, is disruptive, for similar reasons to why MySQL was. But that doesn’t mean that any one particular NoSQL product should be viewed as particularly disruptive. Even MongoDB has accomplished less to date than MySQL eventually did.*
*But also in less time, as my friends at 10gen would surely hasten to point out.
9. There isn’t much disruption in NewSQL. Mainly, NewSQL is a collection of efforts to win with better technology than what came before.
Comments
13 Responses to ““Disruption” in the software industry”
Leave a Reply
“But MySQL never accomplished much in Oracle’s core or semi-core markets.”
I heard that many times when I worked at Oracle. But I think that ignores the potentially serious problem that MySQL prevented Oracle from growing into new markets. So maintenance was fine but new license revenue suffered.
The dotcom web business was great for Sun & Oracle. The post-dotcom web business was not.
Mark,
I agree that it’s a close call as to whether the business Oracle lost to MySQL was “core”. But if you look at where that class of applications is going, some of it is leaving MySQL for NoSQL. I.e., it’s looking ever less like a natural market for the Oracle DBMS.
With respect to “some of it is leaving MySQL for NoSQL” do you have anything more than anecdotes? At least with Oracle you can measure new license growth or lack thereof.
For MongoDB, one of the MySQL alternatives, the only metric I know of is dollars raised from VCs. $81 million is a lot of money. I don’t know how much MySQL raised. That money amplifies their presence thanks to money spent on marketing, but eventually those investors want an exit.
Anecdotes.
And customer counts. A large fraction of internet NoSQL usage would, in the absence of NoSQL, be served by MySQL or a close competitor.
Consider, for example, at your own work at Google and Facebook. “Should we be using MySQL or X?” considerations seem to lean more in a NoSQL direction than an Oracle one. Right?
I assume you mean customer counts from companies you advise. I am not sure what that implies about the greater MySQL market. The NoSQL/NewSQL products would do better if their efforts weren’t so diluted. Lots of products with good features but they would do better if more of the money went to a few of them.
With respect to MySQL for web companies FB, Google, LinkedIn and Twitter are all looking to hire people who can make MySQL better. But people good with MySQL internals are hard to find here in the US.
Google is staying close to the relational model with Megastore, Spanner & F1 and Spanner/F1 didn’t replace all of the MySQL usage that I used to support when I was there. AFAIK most of the other big MySQL customers expect to remain big MySQL customers. MySQL 5.6 is an impressive release with features that make it much easier to scale MySQL and take advantage of modern hardware.
I continue to be surprised that you and so many other people are so willing to tell me what technology I should be using. I am rarely asked what I think and why MySQL might be one of the best choices today.
Mark,
I ask you every time I see you. You give brief, vague answers and — when those are done — evade the questions. 😉
As for companies I advise — make that companies I interview, whether or not I advise them. I know somewhat more about the customer bases of my clients than of non-clients, but the gap isn’t as wide as it is for other kinds of subjects (e.g. product futures, other kinds of futures, or personnel).
I can tell you why companies use MySQL. Questions specific to one employer are harder to answer. While your job might be to ask the questions, my job isn’t to answer most of them.
In my part of the world (web companies) MySQL is used for 2 reasons — InnoDB and replication. Many aggregate workload numbers have been shared for MySQL at FB. Alas some of the per-node numbers won’t be shared and those are equally impressive.
InnoDB was, is and will continue to be a remarkable database engine started by Heikki Tuuri, continued by the InnoDB team and enhanced by Percona, Google, Facebook and now one or more companies in China. Most of the NoSQL/NewSQL entrants would have been in much better shape had they started with embedded InnoDB. If you want to do OLTP on IO-bound databases and you are open-source then you need a great reason for not using InnoDB. TokuDB and VoltDB have reasons, some of the other vendors do not. And the early comparison between MongoDB and TokuMX show the benefit from having proper support for disk-bound databases.
Replication in MySQL has been the other must-have feature. Prior to 5.6 it has also been a high-maintenance feature. But with crash-safety for slave state, global transaction IDs and parallel replication apply many of the problems my teams have solved with patches and talent can now be handled by official MySQL (or MariaDB).
I think proper support for a document data model is the next thing to add to MySQL and/or MariaDB.
Wow, DataStax also crossed the $80 million mark in funding — http://gigaom.com/2013/07/23/nosql-startup-datastax-raises-45m-to-ride-cassandras-wave. Do you have an estimate for the total amount of money invested in NoSQL/NewSQL companies?
I don’t track VC funding. I’m happy to leave that to GigaOm, who love the subject. 😉
Mark,
I’d think that replication would be a historical advantage for NoSQL over MySQL, except that MySQL has been trying to play catch-up, and apparently in your opinion has largely or entirely succeeded.
I emphatically agree that the document data model has its place, or more precisely that dynamic schemas do.
To me, the relational/non-relational choice comes down to a couple of things in the systems you’re talking about.
1. How big is the benefit from being able to do joins?
2. How great is the harm from having to specify schemas before writing queries?
Plus of course, how mature and desirable various specific products generally are judged to be.
If you can’t do joins then the document model must support the outlier documents. For example, if there is one document for Justin Bieber and that doc includes IDs for his fans then that doc will be huge. With SQL a relation table makes that easy to manage. I have no experience with MongoDB to understand how it supports that case other than that the max document size has been growing over time.
It will be interesting to see how schema-less apps age. For me schema-mostly with good support for online schema change is where things will settle.
Hi Curt – There is disruption to be had in “Integrated internet system design” http://www.dbms2.com/2012/09/07/integrated-internet-system-design/ — virtualize silos with generic data structures and dynamic schemas / rich modeling. It’d be great to connect at some point.
Best,
Dave
[…] has hugely thickened its stack, as part of an Innovator’s Solution strategy — hardware, middleware, applications, business intelligence, and […]