How to select technologies to manage database engine diversity

Database systems are usually wedded to specific applications, generating database diversity. How best to reduce it?

Many companies run a rich diversity of database engines (for rich, read “painfully difficult to manage”). Database systems are complex and are generally purchased and implemented as a precursor to installing a specific application: For instance, the chosen CRM system runs on a particular database engine and that engine therefore becomes part of the company’s IT infrastructure. However, many application vendors now offer applications that run on a range of engines, which introduces much more flexibility and might make it possible to consolidate your systems on a smaller number of database platforms.

Clearly, reducing database engine diversity is likely to yield significant savings in licensing costs, maintenance costs (both for support contracts and in-house personnel), support and training. How can we achieve this?

The first task is to select a technology upon which to standardise. It makes sense to choose a well-known, well-established name that isn’t likely to disappear overnight. Consider existing on-site expertise, but don’t be too swayed by zealots for whom Manufacturer X’s software represents the spawn of the devil and who would buy anything else to avoid it.

Also, consider your existing investments in hardware and whether it can be redeployed. For example, suppose you are running some of your current application on RS/6000 hardware. If you need to keep that hardware (for cost reasons), then your choice of engine is severely restricted; if you can replace it, then you have a free choice. You may still end up with several vendors on a short list, and that’s the time to start the hard bargaining. It is probable that any of the main database platforms will be fit for your purpose, so see what incentives the short-listed suppliers will offer and pick the best deal for your company.

Active vs. passive approaches to reducing database diversity

Diminishing database engine diversity can be approached passively or actively.

The passive route is to wait until the licence renewal time for an application comes around and, if it will also run on the chosen database engine, negotiate a platform swop. When a new application is purchased, part of the requirements specification should bethat it runs on the chosen engine.

The active approach means identifying applications used within the organisation that also are available in versions that run on the chosen engine. Replace these and take the opportunity to renegotiating both the licence fees and the maintenance contracts. One advantage here is that standardisation means that you are ‘bulk buying’, so use that fact to drive a good bargain.

Secondly, any application that won’t run on the chosen engine should be replaced with one that will. Note that both of these are active approaches, but there is still a world of difference between them. For example, in the second case, you may have to force the finance department to change its financial applications just to suit a database standardisation programme. This suggestion is likely to meet significant opposition and may well not be sensible.

It’s important to remember that we’re trying to work for the good of the company, not simply for our own convenience. As you follow an active policy, you may come across applications that are critical for your company and that viable alternatives that run on the chosen database engine simply don’t exist.  In that case, you may have to allow exceptions to the standardisation policy.

Whichever approach you take, factor in a communications and training budget for keeping all your personnel informed about the standardisation strategy and for training in the new systems.

BI systems and database standardisation

For a company that has a business intelligence (BI) system or is considering implementing one, there are other implications for standardisation. Most BI systems have a central data repository called a data warehouse, and data from the database systems that run the day-to-day business (often termed source systems) is fed into the warehouse at intervals. If all the source systems run on the same database platform, the process of managing the flow of data into the warehouse is made very much easier. The flow is managed using extract, transform and load (ETL) tools: Data is extracted from the sources, transformed into the required form and loaded into the warehouse. If there is a need to pull data from a range of source systems, make sure that the ETL tools you’ll be using have the hooks necessary to “talk” to the various sources.

Database engine diversity isn’t all bad

Database standardisation is a highly worthwhile goal, but it’s not practical to force every database into the same pint pot.

Many BI systems require a different type of database engine in order to delivery rapid analytical querying performance. These multidimensional engines differ significantly from those used to run operational databases, and your IT infrastructure may also need to support an engine of this type.

Finally, remember that small, standalone databases used by one user or a few people are unlikely to benefit from being converted to a full-blown client/server database engine; so consider adding a single PC-based engine to your standardisation plan.

Finally, remember that small, standalone databases used by one user or a few people are unlikely to benefit from being converted to a full-blown client/server database engine; so consider adding a single PC-based engine to your standardisation plan.

Read more on Database management