Oracle 'database everywhere' strategy doesn't fit all

The company's new 9i database version release adds functionality but doesn't appear to provide the technological leap that would put it ahead of lower-priced competition.

3 min read

Oracle's new 9i database version release adds important incremental functionality but does not appear to provide the great technological leap that would put it far ahead of its lower-priced competition--particularly IBM's DB2 and Microsoft's SQL Server 2000.

Wherever customers' existing investment

See news story:
Oracle looks to capitalize on database lead
in Oracle technology and skill sets does not make implementing other software too costly--and an application is available on a non-Oracle platform--users should consider lower-priced alternatives to Oracle.

Oracle's "database everywhere" strategy, which attempts to generalize a single infrastructure pattern to fit all needs, is often a high-priced answer to problems that are better solved with other infrastructure approaches. Customers should work with experts to develop strong infrastructure strategies based on several different repeatable patterns that enable them to apply the most cost-effective solution to each problem instead of trying to make one answer fit all questions.

Oracle certainly is doing well in the marketplace and has momentum. But it is by far the high-priced solution. As the bloom fades off dot-com companies, and customers become more cost-conscious, Oracle is likely to face increasing pressure from DB2 and Microsoft's SQL Server 2000, which is beginning to grow up to handle larger applications. META Group believes that Oracle will either have to cut its premium pricing, which will cut into its huge margins, or lose market share to the competition.

IBM has become particularly aggressive this year in selling DB2 into the marketplace and has achieved some success, although DB2 still lacks an equivalent of the large application library that runs on Oracle. Oracle's strategy of trying to develop its own solutions for customer relationship management (CRM) and other key applications also works against it in some cases.

Software companies have started recommending DB2 to customers in part to lock out potential competition from Oracle sales reps positioning Oracle application solutions. However, hardware vendors continue to promote Oracle, concerned that a DB2 push will give IBM an opportunity to sell hardware. Consequently, Oracle still finds its way into most bids.

Oracle's lack of a credible middleware strategy is probably contributing to its "database everywhere" message. Most application integration requirements do not require database-to-database connectivity, which can be costly and complex, but are instead looking to other middleware tools that provide specific types of interfaces to suit specific forms of integration.

Customers should not use the database first and integration services second. Rather, for most situations they should emphasize integration first and use interdatabase communication capabilities as determined by application requirements.

Extra databases with caching capability do make sense in some e-commerce infrastructure areas. However, often they are a high-priced solution in places where lower-priced file server capability will work equally well, and in some areas, they do not make sense at all. In high-transaction applications, where write activity dominates read activity, for instance, database caching violates the basic principles of database integrity, and implementing Oracle in these situations is a mistake.

In the future, for instance, when the use of caching is widespread on high-speed networks, and live video is being sent through the network, once each segment is delivered, it should not be saved in a database. Instead, it should be "washed out," so network resources can be reused for the next segment.

Meta Group recommends that customers work with experts in infrastructure development to create several repeatable infrastructure patterns and drill their infrastructure staff in them, much as football teams are drilled in sets of specific, repeatable plays. Then they can apply the correct pattern to each new need, and implement it quickly to provide the strongest infrastructure at the best price.

While databases play a role in some of those patterns, customers should avoid trying to make an Oracle or other database package fit all needs. This is the equivalent of a football team focusing only on screen plays and would be equally unsuccessful. Instead, they need to control any Oracle bigots in their organizations and apply the best solution to each problem.

As always, when databases are called for and users have not already made heavy investments in Oracle that would make changing software prohibitively expensive, they should consider all the options.

Meta Group analysts Dale Kutnick, Peter Burris, David Cearley, William Zachmann, and Jack Gold contributed to this article.

Entire contents, Copyright © 2000 Meta Group, Inc. All rights reserved.