 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / March 2004"Y'All Bought Too Much Oracle": a review
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 > A posting on comp.databases.object referenced an article by Adrian Jones at > http://www.theregister.co.uk/content/53/31613.html, Executives. Vice Presidents. What do they know about programming? Technical progress is defined by inventors, not by rants about application integration and business strategies. > Executives. Vice Presidents. What do they know about programming? "There is no executive way to programming" Leonhard Euler? > > Executives. Vice Presidents. What do they know about programming? > > "There is no executive way to programming" > Leonhard Euler? And as we all know, everything in mathematics is named after the person who discovered it next after Euler. > > Executives. Vice Presidents. What do they know about programming? > > "There is no executive way to programming" > Leonhard Euler? The quote you are paraphrasing was by Euclid. See e.g. http://www.vermontgop.org/royal_road.shtml. regards, Lauri Pietarinen ekaun@yahoo.com says... > 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. What do you expect from somebody who offers alternative technology? I think this is one for Fabian Pascal's "Quote of the week" on www.dbdebunk.com. I'll send it to him over the weekend. Paul...  Signatureplinehan y_a_h_o_o and d_o_t com C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04 W2K Pro Please do not top-post. "XML avoids the fundamental question of what we should do, by focusing entirely on how we should do it." quote from http://www.metatorial.com > ekaun@yahoo.com says... > "XML avoids the fundamental question of what we should do, > by focusing entirely on how we should do it." > > quote from http://www.metatorial.com so stunned was i that anyone would actually say something like this, i went to the site to find the quote. it's there. Einstein is quoted as saying either of: "the universe is finite but unbounded" or "the universe is infinite but bounded". my memory says the former. in any case these folks display stupidity that is infinite and unbounded. young-uns really don't know sh.t. robert > > ekaun@yahoo.com says... > [quoted text clipped - 8 lines] > "the universe is infinite but bounded". my memory says the former. in > any case these folks display stupidity that is infinite and unbounded. I was really puzzled: are those guys serious indeed? The suggestion that somebody generates ideas on a weekly basics is hillarious, unless these are management concepts, of course. On the other hand, I can't imagine that those guys put some much stuff on the web (plus a book!) to merely mimic Dilbert site. Should I cry or laugh? > On the other hand, I can't imagine that those guys put some much > stuff on the web (plus a book!) to merely mimic Dilbert site. I guess they are serious, *and* seriously misguided. As nearly all of our culture indeed. SignatureLeandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SP BRASIL http://br.geocities.com./lgcdutra/ gnuoytr@rcn.com says... > > "XML avoids the fundamental question of what we should do, > > by focusing entirely on how we should do it." > > quote from http://www.metatorial.com > so stunned was i that anyone would actually say something like this, > i went to the site to find the quote. it's there. Einstein is > quoted as saying either of: "the universe is finite but unbounded" or > "the universe is infinite but bounded". my memory says the former. in > any case these folks display stupidity that is infinite and unbounded. If you go to www.dbdebunk.com you will see other horrible examples of trendy jargobabble being bandied about with not a care in the world as to what the words actually mean. I lifted that quote from there, because I think it's brilliant, in that it perfectly exposes the complete ignorance of the speaker. > young-uns really don't know sh.t. Reading between the lines from Mr Pascal's site, I think that you will come to realise that many-uns (old, young and middle) don't know shite. Paul... > robert Signatureplinehan y_a_h_o_o and d_o_t com C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04 W2K Pro Please do not top-post. "XML avoids the fundamental question of what we should do, by focusing entirely on how we should do it." quote from http://www.metatorial.com 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'? > 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 [quoted text clipped - 368 lines] > > - Eric > 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. You thought this thread was an attack on Oracle? You weren't concentrating, Mr Lion! Read again... > Your post should be entitled 'Y'all bought too much Date & Pascal'. > Your obsession with Date's silly 'Incoherence Principle' is downright > pathological. Probably I reference it too much - it's just so useful and applicable. It really is extremely difficult to address articles like this one. > At least Oracle has a physical implementation of something. Did I say they didn't? I wasn't knocking Oracle in this, at least not very much. > Meanwhile, Date & Pascal try to leech their way on to the > 'Transrelational' bandwagon. Transrelational is an implementation technology which can be used for many things other than relational - it's not a replacement for relational. I don't see them leeching. > Why don't they plug the Dataphor > 'product' if its supposed to be a faithful implementation of their > 'third manifesto'? I don't know. Why don't you ask them? Incidentally, the Third Manifesto is primarily about types (domains), and Dataphor also covers relational ground (e.g. An Introduction to Database Systems). Pascal didn't have any direct participation in either book. - erk > Why don't they plug the Dataphor 'product' if its supposed to > be a faithful implementation of their 'third manifesto'? Several reasons: 1. DBDebunk is mainly Pascal stuff, and he's not really interested in products. He feels the TransRelational (ReqTech) stuff is fundamentally different because it should solve some fundamental implementation performance issues that could eventually make RDBMSs, even such as Dataphor, much faster than anything else. 2. They do plug it, but small scale. Date and Darwen even form, I think together with some other few, an informal conceptual advisory board for Alphora. 3. Alphora Dataphor is still not finished. It can be used in modest production loads, your data is safe. But it won't quite scale up because it gets its reliability from the underlying SQL DBMSs, it ain't still a full DBMS. This will probably take years to fix, and the TransRelational guys ain't helping by being too secretive. If you go over http://www.thethirdmanifesto.com/ you will see they also plug some free software relational libraries. Also not yet full DBMSs, but taking the other end of the problem as compared to Alphora Dataphor. SignatureLeandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219 Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607 04.674-000 São Paulo, SP BRASIL http://br.geocities.com./lgcdutra/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.