A month ago, Gartner surprised many with their 2015 ODBMS Magic Quadrant publication in which Microsoft displaced Oracle for the top spot. As an outside, but nonetheless professionally invested observer, it didn't surprise me, and I'm really happy to see Microsoft getting the recognition they deserve in this space. It is possible to make too much of individual moves within quadrants, and frankly this was overall a pretty small move – Microsoft was very credible in this space before. But still, there is plenty of market intelligence to be derived from looking at trends over time, and even more from observing how the evaluation criteria have changed.
A Diverse ODBMS Ecosystem
In 2013, there were four vendors in the top right quadrant. 2014 saw the addition of four more, for a total of eight vendors. This year, there are eleven. Notably, Amazon Web Services entered the top right quadrant for the first time. Right away we see that the ODBMS market is rapidly diversifying. Even the name is telling - "Operational Database Management System", omitting the word "relational", is indicative of the redefinition of the data platforms market. This is no longer about the extent to which Microsoft can replicate Oracle RAC functionality – it's about which vendor can deliver the breadth of platforms in demand by developers.
There is a secular shift toward non-relational data stores for certain workloads, and to understand how that shift affects Microsoft, it's helpful to understand some of the history behind it. For decades, if you were writing a Windows-based application that needed a commercially supported, reliable data store at a reasonable price, you stored your data in SQL Server. That's a double edged sword, though. Because of its place in the market as the "reasonably priced, commercially supported" data platform, Microsoft found it difficult to raise prices for what were undeniably premium features like AlwaysOn Availability Groups. Oracle was unabashedly priced at a premium, willingly ceding the low end of the Windows and Linux RDBMS markets to SQL Server, MySQL, and PostgreSQL.
What this means to Oracle and Microsoft
Microsoft has two types of customers for its RDBMS: folks who leverage the "relational" part of the SQL platform, and those who just use it as a reliable place to reference data. Microsoft never made much money from the latter group to begin with, so a shift toward non-relational platforms is actually a financial opportunity for them. They can position Azure Tables and DocumentDB and actually increase revenue. And because they have a diverse set of data platform offerings, it leaves them free to raise prices on SQL Enterprise Edition for those premium features that allow them to functionally compete with Oracle.
Oracle does not have the same luxury – when an application developer migrates her app to noSQL from Oracle EE, not only does Oracle have to compete with the likes of MongoDB, but even if Oracle wins, they've lost 80% of their revenue. This is not a conversation an Oracle sales executive is going to want to have.
It's about the suite
There are plenty of folks who will claim that RDBMS is dead, and plenty of others who believe that non-relational data stores are a fad. Both of these stances are likely wrong. For a long time, you used a relational database management system to store structured data, whether you needed to declare relationships between those data or not. Those days are over – developers use the tools that are most appropriate to the needs of the application they're developing. It's ironic that Gartner – the organization that introduced the notion of "bi-modal IT" – is now rewarding Microsoft for its decidedly single-mode approach to the data platforms space.
It's always tempting and sometimes useful to put tech into "buckets", like "Application vs infrastructure resilient" or "pets vs cattle" or "platform 2 vs platform 3" or "cloud native vs …". These allow you to understand the needs of the application, and apply the right infrastructure technologies to support it.
Dividing your IT organization is probably a mistake
Although these terms may help you understand an applications and its needs, it's probably a bad way to organize an IT outfit. Beyond stifling innovation, dividing your IT organization into silos will sacrifice what most organizations need the most – agility. The ability for people to move, work across lines, and leverage appropriate technologies is critical. Organizations with multiple silos can be incredibly difficult for business units to work with.
As an example, let's take a business intelligence initiative. These are broad projects that touch all sorts of IT. They'll pull operational data from legacy line of business applications, they may leverage data warehouses, they may pull third party data via APIs, they might need semi-structured data that resides in one of your Hadoop clusters. In a bi-modal organization that data scientist, or business analyst, or sponsoring executive is now navigating the likely troubled waters of competing internal IT organizations who have differing ideas of how and where certain functions should be performed. Even simple problems with established fixes, like leveraging Hadoop to ease ETL workloads on data warehouses, become laden with political overtones.
This is probably not "face of IT" that most CIOs would like to present to the business.
The technology is collapsing anyway
For the better part of a decade, legacy application developers have been working furiously (and successfully) to modify their platforms to leverage non-resilient commodity infrastructure. There are about ten different ways to leverage Hadoop with SQL, some of which allow operational joins between RDBMS and Hadoop stores. Expertise in a function (such as messaging) does not lose its value when the underlying architecture of the messaging platform changes. The promises of hybrid cloud computing are coming to fruition. Organizations that have silos of "fast" and "slow" mode IT will be ill-equipped to make use of these developments.