Database applications are the lifeblood of a business. They record our purchases, payments, and credit worthiness. They track the arrival and departures of airline flights. They even appear in advanced research such as the decoding of the human genome. Robert Hillard estimates that roughly 50% of a company’s value derives from its data. This means that a company with a market value of $10 billion has $5 billion in information and knowledge assets. [Robert Hillard. 2010. Information-Driven Business. John Wiley, p22]
The approach to procuring (building or purchasing) database applications is much different than that for other types of applications. Database applications have large quantities of long-lived data. There is a need to coordinate the effects of multiple users and applications. Day-to-day business operations as well as mining for business insights depend on having timely and accurate data.
The following experiences illustrate how the quality of a database can make, or break, an application.
During one consulting engagement, we met with a small group of developers to review their design for an application and to validate their development practices.
They began the review by explaining the motivation and requirements for the application. The firm was a service business, and they were wary of being overtaken by competitors if they did not add capabilities. They presented their application model and database design and they were sound. It was clear that management had assembled a team of skilled developers who understood modeling and databases well.
The developers were in the process of coding their business logic and user interfaces. They were using Java and concerned about how it would work with a relational database. They had devised an architecture for coupling Java code to the database.
The end result was that their application ran well. It was flexible, extensible, and fast. They had a modest number of bugs and met their scheduled delivery dates. The successful application helped maintain the company’s business position and keep competitors at bay.
Another time a client asked us to evaluate a product sold by a Fortune 500 company. The vendor had a great market vision, and the product listed many impressive features. The vendor understood the business requirements well, and our client was enthusiastic.
The first hint of a problem came during installation. The documentation was confusing and it took our client’s support staff several weeks to install the product, only to find that it was buggy and slow. An experienced developer attended the vendor’s training course and found it confusing. We decided to reverse engineer the database to understand the product better.
We were surprised to find that the database had been poorly designed. Even though the vendor was a large, credible company and understood the requirements well, they mishandled the database. The database looked as if it had been designed by a programmer new to databases. In later discussions, the vendor confirmed our suspicions. It had never occurred to them that database design was difficult and that a bad design could cause so much trouble. It was no wonder that the software ran slow and was confusing. Our client rejected the product.
The upshot is that the vendor wasted several million dollars in developing and marketing a flawed product. This could have been readily avoided with careful attention to modeling and database design. A few months of skilled time could have saved them much rework, increased the quality of their product, and boosted sales. The product was temporarily withdrawn from the market, fixed, and is now being sold again.