Historically, the choice of database engines within organizations was driven almost entirely by the choice of applications. When a company needed an inventory control or human resources system, the purchasing decision typically was based on the suitability of the application and the people involved didn’t care which transactional database underpinned the chosen software. Databases often proliferated as a result, and they did so even faster if acquisitions or mergers took place.
In what now seems like the distant past, applications were generally run as standalone systems within departments, with no input from or output to other parts of the organization. If the isolated use of applications had persisted, there would be much less of a case to be made for database standardization now. But, of course, it didn’t.
The departmental systems were designed to run transactions, and so they did. Now we are seeing an overwhelming need for information, not just raw transactional data. Uncovering the business intelligence (BI) and analytics findings that companies can use to gain competitive advantages over their rivals requires the cross-correlation of data from multiple transaction processing systems. It makes the task of integrating and correlating data much easier if all of those systems have been migrated (in a well-managed process over a period of time) to run on one database engine.
Extracting information for BI uses is the main business driver for database standardization, and it can be a compelling reason by itself to agree on a database standard enterprisewide. There are also other potential advantages, the most significant of which -- even more so in these economically challenging times -- is a reduction in database maintenance and integration costs. Your database management team can concentrate on the surviving engine, and you may even be able to reduce the size of the team (but read to the end of the article before starting to fire people).
Software licensing costs often can be reduced, too. If your company is running six applications on different database platforms, you’ll be paying six separate database license fees. Database costs don’t magically disappear if you standardize on a single platform, but you might be able to negotiate a bulk licensing deal that provides larger discounts than your company gets now.
In the early days of the database market, there were many transactional database engines available, and users often were limited to running applications on specific databases for which they had been developed. That effectively rendered database standardization impossible. Fast forward to today: The number of mainstream relational databases has shrunk to a handful, and most mainstream applications will run on any of them. As a result, application support in most cases can no longer be used as a valid argument against standardizing databases. In fact, a lack of availability on multiple databases could be a good reason to decide not to buy a desired application; it’s questionable whether one that doesn’t run on all of the leading database platforms is likely to survive long-term.
Database standardization: How far is too far?
However, any standardization policy should be based on the business needs of an organization and shouldn’t necessarily be applied on a one-size-fits-all basis encompassing both business operations and BI processes. So far, the focus of this article has been on transactional database engines. Choosing one of the mainstream relational database management systems for running transactional applications makes perfect sense.
More info and advice on managing databases
Get more tips from article author Mark Whitehorn on creating a successful data management strategy
Read about the pros and cons of using cloud database technologies in corporate applications
Learn about columnar databases and other technologies that can boost analytics performance
But forcing analytical systems into the RDBMS mold makes little sense for many organizations. Also, many businesses use lightweight databases such as Microsoft Access for application development or to support a few end users -- for example, to manage a phone list used only by the six people in a small manufacturer’s purchasing department. Such applications are also a bad fit for a full-fledged relational database.
Overall, it’s best to keep an open mind and avoid trying to force an entire company’s database requirements onto a single platform. You might, for example, think about standardizing on one relational database engine for your main transactional systems, one multidimensional product or other specialized analytical database for your BI and data warehouse systems, and one desktop database engine for small-scale applications.
The different technologies will, of course, all require support and maintenance from your database team. But if you have managed to reduce the number of database platforms from, say, six transactional, two analytical and three desktop technologies to a mere three in total, efficiency gains -- cost and otherwise -- are almost bound to accrue.
ABOUT THE AUTHOR
Mark Whitehorn is a professor of analytics at the University of Dundee’s School of Computing in Scotland, where he teaches a master’s degree course in business intelligence. He is also a research associate at the University of Cambridge in England, and through PenguinSoft Consulting he works with companies on database design and data warehousing.
This was first published in April 2012