'Y'all bought too much Oracle'
Database must not dictate your IT strategy
Opinion The recent article on The Register, entitled Oracle; spend less, know more, was a fascinating insight into the vision that Oracle proposes for its customers, and I feel compelled to write a response. What is being proposed by Oracle is possibly a CIO's dream, but definitely an operational nightmare.
As a leading influencer of IT strategy and directions, Oracle's IT vision is
- We're all heading towards one single enterprise database, and
- We are spending too much on hardware
For the first time Oracle appears to be seriously out of touch with the reality of IT architectural thinking. Most people would only agree with one of those three goals, and there is an alternative vision.
Firstly, the concept of data-centric architectural thinking is out by at least 10 years. Different applications and business processes have very different data management needs. One size does not fit all, however much it would suit Oracle to have everyone believe this. Data management requirements vary from batch oriented processing over a record based data model, through ad-hoc and decision support systems, to high transaction rate business processes oriented over a complex graph based data model. This variety of data management requirements cannot be supported by a single database technology without unacceptable and practically irreconcilable compromises to both data and applications.
Flexibility and responsiveness are key to business success today, and IT infrastructures have to be able to support this flexibility. New services, new features, higher performance, now. This cannot be achieved if everything is tied together at the data level. This is precisely why component (or service) based architectures dominate current strategic thinking. Integration is provided at the service level rather than the data tier, enabling an organization to achieve the undoubted need for consolidation of information and business flow, but without enforcing data consolidation, which would severely compromise responsiveness, and adversely affect costs.
Modern systems development is driven by business need. The data does not dictate the business processes, the data is there to enable business process, and needs to be offered and managed in an appropriate way, when and where it is needed across the globe. As the Oracle article asserts, "Databases and applications are more closely related", but the conclusion that the answer is to separate and consolidate the data, in isolation from the applications, is surely flawed.
So what are the implications for Oracle customers? Oracle appears to be proposing the database equivalent of flared trousers. A single, monolithic enterprise database? No, but seriously. This vision is valid for maintenance of legacy systems (in the same way that the COBOL, hierarchical database concept is still in use in the previous generation of legacy systems), but as much as Oracle would like to turn back the clock 20 years to when the database was the first and most significant commitment an enterprise would make, the world has changed. Customers are questioning the lock-in to any technology, even database.
In the past this lock-in was unavoidable, but now persistence standards, particularly Java Data Objects (JDO) deliver the reality of total database independence. Without fear of lock-in or technical compromise, it is inevitable that enterprises will utilise whatever persistence mechanism best suits the job. Process integration does not mean data consolidation.
In fact, data consolidation imposes such catastrophic operational compromises as to render it practically impossible and commercially inadvisable to follow as a direction. Rather like the doomed enterprise modelling initiatives of the 1980's, the pace of change required by the business would far exceed the rate at which new functionality could be levered, stuck, glued or hammered into already over-engineered monolithic databases. Even if you could throw enough resources (people, hardware, software) at the problem to deliver to the business, the costs would be totally prohibitive.
The solution therefore, is to find a better way. And we are not talking about incremental change. We are talking about orders of magnitude improvement. As Albert Einstein said "The problems that exist in the world today cannot be solved by the level of thinking that created them".
In summary, the problem is not that "Y'all bought too many databases". The problem is "Y'all bought too much Oracle". Continuing to buy into this vision of a data-centric, monolithic, one-size-fits-all architecture will render an enterprise unable to respond to the business challenges facing it. The assumption that an enterprise will function best when straight-jacketed by a commitment to a single database technology (and maybe even a single database) is crazy.
There are many types of applications for which Oracle is an excellent choice, and Oracle will continue to play an important role, but is the choice of relational tupple engine, object engine or flat file really the fundamental architectural decision needing to be taken by an enterprise? In the same sense that it would be unlikely for Ford to commit its strategy exclusively on one engine type (petrol, diesel, electric, hydrogen or whatever) to be used in all its vehicles (cars, vans, trucks), so the assertion by Oracle is out of touch. More and more organisations recognise they can use the right technology for the job, giving the flexibility and commercial payback required by the business, but without needing to select a single database, with its inevitable compromises.
And the idea of reducing hardware costs? Absolutely right, Larry. Using the right technology for the right applications will dramatically reduce hardware and other IT costs. So use Oracle for data-centric, decision support and legacy systems where it works well, but choose alternatives, based on JDO to deliver the types of service-based, middle tier applications that are going to differentiate your business over the next ten years. Database was the last great lock-in. But no longer with the likes of JDO. Database is now a commodity, and needs to be driven by your service based IT architecture. Database must not dictate your IT strategy. ®
Sponsored: DevOps and continuous delivery