Re: "Y'All Bought Too Much Oracle": a review

Your post should be entitled 'Y'all bought too much Date & Pascal'. Your obsession with Date's silly 'Incoherence Principle' is downright pathological.

At least Oracle has a physical implementation of something. Meanwhile, Date & Pascal try to leech their way on to the

'Transrelational' bandwagon.  Why don't they plug the Dataphor
'product' if its supposed to be a faithful implementation of their
'third manifesto'?

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:<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
Received on Sun Mar 21 2004 - 01:06:06 CET