Oracle's Stack Is Engineered For Investors, Not Customers
Applications strategy is the antithesis of integrated, a hairball of products born of a mergers-and-acquisitions strategy.
I spent much of last week sorting through the absolutely overwhelming communications disaster called Oracle OpenWorld in search of some clarity on Oracle's vision for its customers. I have come to the following conclusion: Oracle's applications customer strategy just isn't about making things better for its customers.
The problem with the Oracle of today is that some of the best technology minds in the industry have been hijacked to fulfill a vision that is skewed more towards fulfilling the promise of a decade-old merger and acquisition strategy rather than making customers both successful and happy. And the vision comes with a built-in irony that has me convinced that the customer comes second at Oracle, second to the shareholders whose addiction to Oracle's margins has driven the executive team at Oracle to consider investors, not actual companies that consume its software, as the real customers.
Let's start with the irony: Oracle is selling a vision of an integrated hardware stack that is magnificent in its simplicity: everything from the silicon to storage to networking are all "engineered" to work together. I wouldn't be surprised if the electrons inside their boxes are also engineered by Oracle. If they could gain some sort of system-level efficiency by altering the laws of physics, they probably would do that, too.
Contrast that with the software side of Oracle's product line. Oracle's applications strategy is the antithesis of integrated: In reality it is a hairball of products and underlying technologies, data models, and deployment models that could have only been "engineered" by an M&A strategist. Any real engineer would be crucified for pretending this software strategy makes sense for a customer looking for an integrated applications environment.
Four (or five, depending on how you count it) main product lines, each with its own code base. And literally dozens of other products, acquired with the goal of improving shareholder value, most of which also came with their own proprietary software or data models. Hundreds of business processes, many overlapping and redundant from one product to the next. And a big, hairy-chested middleware "suite"--Fusion Middleware--that is itself a conglomeration of technologies--a little Java here, some BEA and BPEL there, some MDM, some analytics, some DBMS technology, the more the merrier, all jammed into a one-size-fits-no-one morass of integration options. To simplify things, they also have an integration system called AIA that is used infrequently for the very reason that it's an expensive, complex, technically challenging, and hard to cost-justify Tower of Babel.
Despite Larry Ellison's insistence--could he be that out of touch with his customers that he believes this?--that integrating his software stack is easy, the reality is that integration is hard, expense, and the responsibility of the customer, not Oracle. There is no magic bullet, no easy-to-configure wizard, for the majority of the integration that Oracle customers require to run their businesses on Oracle software. Nope, it's all about custom development, using expensive development resources. Sure, there are more "integrations" being built by Oracle all the time. And as long as time is not of the essence, one day Oracle will have filled out the massive matrix of integrations required to link hundreds of key business processes across dozens of often overlapping applications. One day.
In the meantime, the customer has to wire this hairball up. And, having talked to many customers about this issue, the conclusion I came to is that Oracle's investors are missing a big part of the problem they have helped to create. Because, in the long term, as long as customers are not using AIA to solve this problem systematically, the total cost of ownership of the investor-driven software model Oracle has foisted on the market will remain excessive, and render Oracle vulnerable to a lot of smarter, and more agile, and better rationalized competitors.
The irony of the roll-your-own integration conundrum on the software side is how much of a non-starter it would be on the hardware side. Imagine having to solder the connections in your rack systems, splice the cables to your storage systems, write your own network protocols--kind of reminds me of the state of the art when I started in this business in the 1980s. And here we are, 30 years later, and Oracle's customers have been pulling out the soldering irons and user manuals in order to realize their vendor's integrated software stack vision.
It's amazing how pervasive the problem is, and how out of touch Oracle seems to be about it. Even customers who were hand-picked by the Oracle communications team to talk to the influencers at Open World had war stories about this problem. One customer I spoke with was told by Oracle that Agile PLM would plug right into a process manufacturing instance of eBusiness Suite. Two years later, this happy customer (Stockholm Syndrome, anyone?) was still fighting Oracle's integration battle inside his company, at his expense. Another customer shared a similar story about Siebel CRM and eBusiness Suite, another about PeopleSoft and Siebel. And so it goes in the engineered-for-investors Oracle stack.
How Enterprises Are Attacking the IT Security EnterpriseTo learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Digital Transformation Myths & TruthsTransformation is on every IT organization's to-do list, but effectively transforming IT means a major shift in technology as well as business models and culture. In this IT Trend Report, we examine some of the misconceptions of digital transformation and look at steps you can take to succeed technically and culturally.