Days of reckoning for relational databases
Geoffrey Moore's must-read new book reveals high-tech survival strategies
August 1996
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Days of reckoning for relational databasesGeoffrey Moore's must-read new book reveals high-tech survival strategies
|
August 1996
|
Sybase's recent financial troubles and Informix's acquisition of Illustra are watershed events that mark the relational database industry's transition to a new, potentially difficult market phase. Geoffrey Moore, the greatest sage of technology marketing, has a new book whose model of technology market growth contains important lessons for relational database vendors. How do they apply during these days of reckoning? (3,200 words)
 Mail this article to a friend |
First, the book. Run, fly, bike, rollerblade, whatever it takes, to buy it. Anyone in information technology -- or any industry that is being increasingly influenced by information technology -- should be intrigued by the model of growth and change Moore presents. Just as importantly, Moore writes with a clarity that is extremely rare in this business.
Moore, a former consultant with technology marketing experts Regis McKenna Inc., is now out on his own and has seen so many different technology-based products wax and wane that he has been able to adduce patterns that are not apparent to the many of us who labor eyeball-deep in specific technologies. Inside the Tornado is Moore's second book. His first, Crossing the Chasm, is already a classic.
The other bell curve
In Crossing the Chasm, Moore defines the Technology Adoption
Life Cycle, which is a bell curve depicting different classes of users
according to their eagerness to embrace a given technology. At the
front end of the bell curve are the "innovators" or
"technology enthusiasts" who like playing with the newest
gizmos. Then come the "early adopters" or "visionaries,"
a small number of people who see an untested technology and, by
making a conceptual "leap of faith," figure out for
themselves how it applies to their businesses and take the plunge. Next
are the "early majority" or "pragmatists" who wait
until they can buy a complete, reliable, off-the-shelf business
application built around the new technology. At this point, the bell
curve peaks. The "late majority" or "conservatives"
want complete business solutions, but only as commodity technology at
commodity prices. Finally, the far end of the bell curve has
"laggards" or "skeptics" who actively resist technology
adoption.
The "chasm" from which the book takes its name is the gap between the visionaries and the pragmatists. It represents the amount of time and effort necessary to identify a killer business application (killer app) for the new technology, develop it, market it to the right customers, and deploy it successfully--with the promised business gains delivered. The point of the book is that it takes much effort to cross the chasm; but if you do, the rewards are enormous. Another important point is that the killer app necessary to cross the chasm may not be an obvious application of the new technology, but it solves a very specific business problem for a well-defined group of customers, and it does so without requiring anything else to be built. Moore refers to the combination of basic technology and whatever else is necessary to solve the business problem as the "total product."
The difference between the core technology and the total product is crucial and instructive. Here's one example drawn from my personal experience and, not coincidentally, mentioned in Moore's new book. Documentum Inc makes a system for managing documents throughout an enterprise (see my November 1995 column in SunWorld Online). Although Documentum does not really contain any radically new technologies, it has a combination of features that are new, including a client/server architecture, relational database (Oracle or Sybase) with a GUI query interface, a user interface building tool, version control and configuration management, full-text search (Verity TOPIC), formatted text viewing (Adobe Acrobat), and an object-oriented API.
|
|
|
|
|
Documentum's chasm
If you look at this set of technologies without a business purpose in
mind, you may think of Documentum as a super-deluxe, glorified text
filesystem--something that's nice to have but difficult to explain
to end users and, in general, not worth the considerable investment in
any obvious way. Documentum hired Moore to help it find the
killer app that could sell itself. They found it, but let
that rest for a moment.
Meanwhile, I led a project in which we were looking to build an enterprise-wide repository for publishable content at a media company. There was no obvious, off-the-shelf product that would do it all. We understood what components we needed, but we didn't have the resources to integrate them ourselves. Hire an outside firm to build a system? Far too expensive. Our solution was to find an off-the-shelf system that had most of the pieces we needed, if not all of them, and build the rest. In other words (to use Moore's taxonomy), we attempted to be "visionaries." We identified Documentum as the system we could augment to meet our business needs.
Documentum did not have the key piece that related to the special requirements of storing and processing digital images, which take various forms during publishing processes and can take up too much space to send around an Ethernet-class network. We thought we would have this built on top of Documentum's basic functionality, but it turned out to be the "900-pound gorilla" that put the project in jeopardy. In other words, Documentum was not a total product for us.
As it turns out, Documentum's killer app was in the pharmaceutical industry: managing documentation for drug approval applications. Faster production and assembly of these documents -- truckloads of paperwork--means faster regulatory approval of the drugs. This translates to millions of dollars in revenue per week, or even better, victory over a competitor in a race to win a patent on a similar drug. Documentum developed a total product for solving this problem, one whose business case was an offer the pharmaceutical firms couldn't refuse. And they didn't; virtually all major pharmaceutical companies have installed Documentum.
As a result of this chasm-crossing, Documentum is now public (DCTM) and doing well. Its technology is still best-of-breed, and it has used its completely dominant position in pharmaceutical as a beachhead for establishing territory in other areas, such as manufacturing documentation and other pharmaceutical applications. This isn't the case in publishing, however--an industry where the dominant attitude towards technology is (in Moore's terms) "conservative." The differences between the core technology Documentum provided and a total product for publishing content archiving were significant: custom development costs which were several times that of the basic Documentum system, months added to the development schedule, discontinuities between out-of-the-box and custom parts of the system. These are differences that make users as well as management unhappy. That's the chasm.
Inside the tornado
Moore's second book, Inside the Tornado, zooms in on what
happens after a technology vendor crosses the chasm.
The first step in growing the business from the small
early-adopter phase to the potential gold mine of the mainstream is, as
he calls it, the "bowling alley." His metaphor is apt: the alley
itself represents the distance you need to go with your technology to
make it into a complete product that solves a business problem. The
head pin is the first killer app (e.g., new drug application
management), on which you must spend a lot of effort. If you knock
down the head pin, others (e.g., manufacturing documentation) will fall
with little or no effort. But after a few pins, that's it: you're done
in the bowling alley.
The phase that comes after the bowling alley is one of very steep growth--the high rise in the bell curve. Moore calls this the "tornado." You enter this phase if you can make the case that your technology applies to a much broader range of customers than those in the bowling alley. (Documentum is trying to do this now, having all but exhausted the pins in its bowling alley.) The tornado, as the name suggests, is a wild time. Your focus during this phase, instead of identifying and solving a few targeted customers' business problems, is simply on shipping as much product out of the door as you can without doing anything outrageously wrong--widespread quality control problems, fraud, etc. Your customers may not like doing business with you, but since they can't live without your products, so you don't care how they feel. Many vendors are arrogant, if not customer-hostile, during their tornadoes.
But customers' attitudes change dramatically once your technology goes from the tornado phase to what Moore calls "Main Street"--the top of the bell curve, where the conservatives become interested. On Main Street, you now have competition, which drives your profit margins down and thus forces you to look elsewhere for major revenue. You can do this through consulting services, add-on products, "deluxe" versions, and so on. Any user of standard PC productivity apps, such as word processors and spreadsheets, should immediately understand what happens here.
Moore did not discover this life cycle anew. If you look at any major product category, you will see how it fits. To give the most canonical example, the automobile industry has come a long way from cars being luxury curiosities for the rich (the early adopter phase), to Henry Ford's "You can have a Model T in any color you want, as long as it's black" (tornado: everybody's gotta have it), to the latest auto technology from Japan that enables you to pick exactly the features and colors you want and have a car delivered to you in a couple of weeks (Main Street and beyond).
The difference is that with today's technology products, the entire life cycle plays itself out in just a few years, which means we will participate in several technologies' births, aging, and deaths throughout our careers. This, in turn, means we can use the model to predict what can happen to a vendor. If we're a customer, we will understand where that vendor is headed. If it's our employer, we can help forestall the inevitable by changing the way we do business, and we can be better prepared to make career changes that preserve our viability.
It's important to watch a technology carefully throughout its life cycle. Even if it's already in the high-growth phase, the changes in business style a vendor undergoes in order to survive the transition from one phase to another can be devastating. As Moore points out, many vendors do not make it. And the most gut-wrenching changes are necessary when moving from tornado to Main Street phases.
Relational databases on Main Street
Relational database vendors must now deal with this treacherous
transition, because their tornado is coming to an end. Let's look at
that market and understand why.
The bowling alley for the relational database market in the late 1980s included applications like trading systems on Wall Street, where banks and brokerages had undeniable incentives to spend the millions necessary to build the new infrastructures and applications. Subsequently, relational databases entered a tornado by becoming prominent parts of client/server architectures that enabled many other kinds of businesses to downsize from their mainframes and realize significant operational savings as well as explosive growth in computational power and flexibility.
Client/server relational database deployment has become widespread, but it is nowhere near commoditization. Many system integration firms have developed significant client/server implementation practices, but prices for software and services have remained high, professional service fees still consitute the vast bulk of expenses for such projects, and market-leading vendors have been customer-arrogant. Yet many customers so far have been willing to spend the money and take what vendors dish out. That's the power of the tornado.
The pool of potential customers who are willing to foot that kind of bill (and take the concomitant risks) is shrinking. Companies now are looking for no-fuss, commodity-level solutions--e.g., attempting to make do with Microsoft Access on an Intel/NT workgroup server instead of investing in Sybase, Oracle, or Informix on an enterprise-class Unix box. The latter vendors, and their system integration partners, need to respond to this type of conservative Main Street customer. This means commoditization (lower margins from core product sales), customer-targeted applications and services, and the other elements noted above, instead of high prices and indifference toward customers. As Moore illustrates, this is a tough transition.
Actually, one of Moore's prime examples of a vendor that should succeed in navigating these treacherous waters is Oracle. As anyone who has done business with Oracle for a while knows, there was a period when Oracle was reviled by even its largest customers. The company also got in trouble with the SEC for falsifying earnings statements by doing the equivalent of reporting fourth quarter earnings booked on "December 34th."
Moore claims that Oracle had to make violent, tumultuous changes in order not to go down in flames. But did it? Certainly a new CFO cleaned up the company's finances, the company beefed up its customer service organization, and it got rid of several, err, "overzealous" salespeople. But, as Moore describes it, Oracle practically had to become a totally different organization.
There's where I don't entirely agree. Moore's essential point about making the transition from bowling alley to tornado to Main Street phases is that you must go from being a customer-focused organization (creating narrowly-targeted business solutions) to being customer-indifferent (ship the product, or else) and back to being customer-focused again (creating value-added solutions and services). Moore's implication about Oracle is that it was completely un-customer-focused during its tornado phase. I don't think so--I think Oracle had threads of customer-focused attitude throughout.
I recall being given technology briefings by both Sybase and Oracle at roughly the same time a few years ago. Both vendors wanted to tell us, among other things, about how they were going to upgrade their core database engines to object-oriented technology. You already know the punchline: neither vendor has done it. But the two vendors were suggesting completely different approaches. Oracle's approach was to listen to its customers, find out what they want, and incorporate those features into a backward-compatible release. Sybase, on the other hand, showed us completely new technology. It was beautiful stuff, but proprietary and totally different from anything it (or anyone else) had done. I wonder what customers counseled them.
On another occasion, marketing representatives from Oracle and Sybase were on a panel at a large conference. The topic was related to data distribution. The Oracle person simply explained the advantages of the Oracle approach, while the Sybase person was in "attack mode." Very uncool behavior at a major conference.
Marketing that lashes out at competitors rather than reaching out to customers doesn't benefit anyone. I'm not suggesting that Sybase does only these kinds of things, but they aren't examples of appropriate behavior for a vendor whose market is moving from tornado to Main Street--especially for a vendor that is not the market share leader. (To use Moore's terms, Sybase is a "chimpanzee," while Oracle is the "gorilla.")
Oracle is out of trouble now, and it is offering the kind of value-added products and services that are necessary to ensure its success in the Main Street of the relational database market. It seems as though Sybase and others have real jobs ahead trying to do the same thing, but they are significantly behind.
Perhaps this isn't true: there are alternatives to marching in lockstep with the gorilla. The most viable alternative is to shift emphasis to a new (or newer) market and attempt to get in on tornado-phase growth there, offsetting the downturn in the existing market. This requires Sybase to develop technology that's new (yet related to its original core competence), cross new chasms, and whip up new tornadoes.
Object-oriented databases: The next chasm?
The most obvious new area of opportunity for Sybase is in
object-oriented databases. OODBs have been floating around for a decade
now. Yet no OODB vendor has crossed the chasm, meaning that there
has been no "must-have" application for OODBs of sufficient
size and impact to start a tornado. One reason for this is that OODBs
are perceived--with some justification--not to be robust enough for
large scale mission-critical applications. Another is that application
development tools and techniques for OODBs have not become as
standardized as they are for relational databases, making it more
difficult to create those killer apps.
Yet there is an obvious killer app lying in wait for the vendor that does eventually deliver an industrial-strength, enterprise-able OODB. I've already mentioned it in this article: content storage in the media business. As the content industries go digital, they will need places to put the petabytes--thousands of terabytes--of data that they generate. Relational databases are not well suited to dealing with this complex, multifarious type of data, but OODBs are ideal. The first vendor to deliver an industrial-strength OODB, together with the right application strategy (through working extensively with customers), could become the "gorilla" in this potentially enormous market.
Sybase has an opportunity to do this now. Meanwhile, we know Informix is on the right track. As we saw in my June column in SunWorld Online, Informix has acquired Illustra, whose "object/relational" database was designed almost from the ground up to handle media data types. Illustra has embarked on a strategy for signing up the right application-space software vendors to deliver the " DataBlades," or object-oriented APIs, as a step towards developing total solutions for the media market. Informix, meanwhile, intends to create an industrial-strength OODB that combines its distributed architecture with Illustra's object-oriented engine. Yet Informix's strategy is not without risk; specifically, the risk of difficulty in integrating the two technologies, and the risk that customers and third-party software vendors will resist developing with Illustra's proprietary object model. Compounding these technological risks is market risk: true visionaries--with the resources to back them up--are rare in the media business. It is a conservative industry that demands proven, commoditized solutions.
But there's a more fundamental question: is OODB really a completely new market for relational database vendors, or is it simply the kind of "line extension" product Moore claims is necessary for vendors to flourish on Main Street? (That kind of question is one Moore doesn't answer in his book. Its principal shortcoming, in fact, is that when concepts get hairy towards the end, he gives few supporting examples and doesn't address the ambiguities of real world situations as crisply as he should).
Because of that uncertainty, all of the major relational database
vendors are hedging their bets by investing in other new technologies,
such as full-text search and the Web. They will all need to find one or
more "next things" to embrace, so that they avoid disaster
during the coming 12 to 24 months. Moore's book ends with a short
assessment of the cultural and organizational skills necessary for a
vendor to make the transition from tornado to Main Street. The
relational database vendors will want to heed these pieces of advice as
well; they will need all the help they can get.
|
|
Resources
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright96.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-08-1996/swol-08-cs.html
Last modified: