"Y'All Bought Too Much Oracle": a review
Date: Thu, 18 Mar 2004 13:51:49 GMT
Message-ID: <VPh6c.36997$Rf1.25165_at_newssvr16.news.prodigy.com>
A posting on comp.databases.object referenced an article by Adrian Jones at http://www.theregister.co.uk/content/53/31613.html, and while the article is memorable, I don't think it's for the reasons intended by the poster. I've embedded my comments below.
> 'Y'all bought too much Oracle'
> By Adrian Jones, Vice President Europe, Versant Ltd
> Posted: 08/07/2003 at 08:45 GMT
> 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.
I would suggest that much of what Jones advocates below is an operational nightmare, independent of such statements about Oracle (which is its own brand of nightmare).
> As a leading influencer of IT strategy and directions, Oracle's IT vision
is
> - Data-Centric
> - 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.
For only the first time?
> 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.
The "age" of a concept has little to do with its value. This is just another sad indicator of how fads drive our industry; I expect this sort of thinking out of, perhaps, the fashion industry or automotive design (as opposed to engineering). I wonder how exactly Jones would define "data". Like it or not, the data under consideration is still centric to service-oriented, component-based, web-based, blah blah blah architectures.
> 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.
This hinges on the definition of "data management", of course. While operational needs can drive distribution, DBMS choice, backups and so forth, most applications and business processes have exactly the same "data management needs." It's predicated on a useful data model, and defining data in terms of that model. Possibly Jones is referring to the need to avoid vendor lock-in, and to have various architectural options for accessing data; however, it's difficult to tell from his words.
> 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.
What he's describing are various business data processing environments. "Over a record based data model" and "over a complex graph based data model" are both vague references to some sort of business data, while "batch oriented" and "ad-hoc" [sic] and "high transaction rate business processes" are so vague as to be useless. A rallying cry, of some sort, to the incoherent, for some sort of flexibility.
> 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.
I agree with him on the need to avoid compromises to both data and applications. However, he doesn't define these compromises anywhere, and I suspect we'd disagree on what they are. One unacceptable compromise is the need to contort business data to fit the needs of a single applications, since it then compromises the long-term value of the data.
> Flexibility and responsiveness are key to business success today, and IT
infrastructures have to be able
> to support this flexibility.
Yes, and a solid data model will support this flexibility. Note how frequently "flexibility" and "responsiveness" are used as justification for lack of design, lack of planning, and a short-term project-focused view of a business's data and processes. You want to know what most inhibits "flexibility" and "responsiveness" by a business's I.T. department? Provincialized designs and implicit (rather than explicit) constraints implemented (multiple times) in procedural logic.
Beware the call for "flexibility" and "responsiveness", as we used to call it "cowboy coding" and the "code-and-fix" cycle.
> New services, new features, higher performance, now. This cannot be
achieved
> if everything is tied together at the data level.
I'd be curious to know why not, if I had any idea what "everything is tied together at the data level" actually meant. He could mean a single place where business data is defined, or a single DBMS, or many other things. Certainly integration (which he hints at repeatedly) is "tying things together", and other than the protocols like HTTP and SOAP, does so at a "data level" (whatever that means)?
I'll invoke Date's Incoherence Principle here, and probably again: It is difficult to treat coherently that which is incoherent.
> This is precisely why component (or service) based
> architectures dominate current strategic thinking.
They dominate current "strategic" thinking because they're written about in a lot of trade journals. Are components and services the same? I think not. Jones, however, lumps them together here.
> Integration is provided at the service level rather than the
> data tier, enabling an organization to achieve the undoubted need for
consolidation of information
So consolidation is needed! Jones says it can't be about data - it has to be about "services", despite their relative lack of definition. Services are certainly one point at which constraints and rules are needed, but it's not the only one - and engineering all of a business's systems around "services", which are also apparently exposed to customers (at least some of them), ignores internal technological heterogeneity, in addition to lacking sound governing principles (they probably exist in academia, but god save us from the perils of theory).
> and business flow,
I have no idea what "business flow" is. I suspect it's something to do with data flow between business systems, but it's hard to tell. Could be more to do with business process engineering.
> but without enforcing data consolidation,
So above he pointed out the need for "consolidation of information", but here says we can't have enforced "data consolidation". More incoherence, unless he's pointing out that that which is needed (consolidation) shouldn't be enforced. I have no idea.
> which would severely compromise responsiveness, and adversely affect
costs.
Certainly we want to keep costs down, and data correct. That's why "consolidation" is good - defining rules in one place, enforcing them in potentially many. Physical distribution, messaging, and all the other techniques to which Jones vaguely refers need to be layered on top of something sound, lest we build a Tower of Babel, which I presume Jones would find more "flexible" and "responsive".
> 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.
Absolutely correct. The first correct statement of the article, if still rather vague.
> 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.
Apart from the rhetorical use of "isolation" here, Jones doesn't say why this argument is flawed. Applications do need to be separated from data, or else the requirements and design decisions for Application X will infiltrate the database and intertwine with those of Application Y. Since what Jones describes seems to be a large business with many applications, the need is even greater.
> So what are the implications for Oracle customers? Oracle appears to be
proposing the database
> equivalent of flared trousers.
More fashion references - oh, and I thought flared trousers were "in" again?
> A single, monolithic enterprise database? No, but seriously.
The alternative is many databases. I suspect by "database" Jones here means a DBMS, which is different. A single relational database, where its rules are defined, is exactly what businesses need. That database can then be distributed according to its needs and the capabilities of its DBMS.
> 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.
More confusion between "database" and "DBMS". According to either, however, the "database" is the most significant commitment an enterprise will make. Jones disagrees, but fails to mention what he thinks is the "first and most significant commitment."
> Customers are questioning the lock-in to any technology, even database.
"Technology" or "product"? Presumably the business wants some stability in its data definition, but also the ability to switch to a new DBMS based on capabilities - better data distribution, for example.
> In the past this lock-in was unavoidable, but now persistence standards,
particularly Java Data Objects
> (JDO) deliver the reality of total database independence.
JDO is a data access technology that "cooks" objects from various data sources (XML files, SQL DBMSs, etc.). So presumably the language lock-in to Java is acceptable, but sooner or later businesses always manage to find a great piece of software written in another language - what then? Keep in mind that a standard relational language would enable exactly this sort of vendor-independence.
Probably "services" will save us, somehow.
> Without fear of lock-in or technical compromise,
> it is inevitable that enterprises will utilise whatever persistence
mechanism best suits the job.
A frightening thought. Apparently Jones believes businesses prefer project teams to develop "their own things" and then cope with the integration issues later (and forever)?
> Process integration does not mean data consolidation.
True. So what? The data still have to mean something, and have that meaning defined somewhere.
> 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.
As opposed to being levered, stuck, glued or hammered into under-engineered, separately-defined databases? I challenge anyone reading this to successfully argue that multiple hetereogenous databases will result in better-engineered applications which cooperate to successfully manage a business's data.
> Even if you could throw enough resources (people, hardware, software) at
the problem to deliver to the
> business, the costs would be totally prohibitive.
As opposed to the maintenance costs incurred by endless rounds of "refactoring" at the enterprise level?
> 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.
How? I've yet to hear a suggestion. And saying that "the solution" is to "find a better way" is the same as saying "the solution is to find a solution." Not very helpful, not even vaguely.
> As Albert Einstein said "The problems that exist in the
> world today cannot be solved by the level of thinking that created them".
I'd be curious what "level of thinking" Jones believes will fix these problems. He seems to enjoy the word "level" very much.
> In summary, the problem is not that "Y'all bought too many databases". The
problem is "Y'all bought too
> much Oracle".
Databases are designed, not bought. How Jones believes that buying many DBMSs (which I assume is what he means here by "databases") will cut a business's costs is beyond me.
> 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.
Architecture? Is he now referring to DBMS architecture, or something else? Incoherence.
> 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.
If by "technology" he means a product, then he's right. And a business should have one database, if only to define what its data mean in relation (pun intended) to one another.
> There are many types of applications for which Oracle is an excellent
choice,
Which ones?
> and Oracle will continue to
> play an important role, but is the choice of relational tupple engine,
Ha. "Relational tupple [sic] engine." That's cute. Is an "engine" the same as a "database"?
> object engine or flat file really the
> fundamental architectural decision needing to be taken by an enterprise?
Yes, in many ways it is. I'm currently working on a project with 2 XML files used to store business data, and the byproducts of just that simple choice has been incredibly poor object design, repetition of rules, unreadable XSDs, and inability to properly state constraints.
> 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.
Our nation has made quite a commitment, however, to 4-wheeled vehicles which fit into a small number of very similar categories. Was that a bad choice as well? Did we failt to properly plan for hovercraft?
> 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 this ignores the costs of "per-job" technology selection. Few business can (or would want to) afford that. Hence the rewriting of legacy applications in newer languages, just to avoid heterogeneity.
> 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.
A bold, groundless, meaningless assertion.
> So use Oracle for data-centric,
What exactly DOES "data-centric" mean?
> 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.
But if I use JDO, what difference does it make whether I've got Oracle on the "back end"? And in what way are the "service-based, middle tier" applications going to differentiate my business? Businesses have been using app servers for years now.
> 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. ®
I.T. strategy is based on one thing: moving data to where it's needed, in the form in which it's needed. If you don't see "data" at the heart of that, then you're missing something. Perhaps DBMSs should be a commodity, but the choice of data model, constraint representation, and consolidation or not are critical. In what way would a database be "driven by your service based IT architecture" - what does that even mean? Presumbly you've been trying to say JDO is database-agnostic, and now our services are determining which DBMS we choose? I'm very confused.
(insert repeat of Date's Principle here)
- Eric