In a number of columns, I refer to the large Fortune 100 company I worked for a few years ago. It was actually a pretty good place to work. Every day brought challenges. If you didn’t like what you were doing, you could usually wait a few weeks and new stuff would pop up. One of the challenges large companies face is the proliferation of different technologies over time. At our company, we always had a standard development architecture. The problem was that the architecture changed every three to five years. From a database perspective, we had applications that were flat-file oriented (I know, not a database), VSAM (I know, not a true database), IMS, Adabas, Datacom, DB2, Oracle, Sybase, and I’m sure a few others. We no sooner converted the few remaining applications out of Adabas when SQL Server entered the picture.

Obviously, the employees did not sit down in 1975 and map out a plan to have 10 file systems in the shop within 25 years. Decisions about standard technology are made incrementally and for what seems to be good reasons at the time. IMS was a lot better than VSAM. Datacom was better than IMS. DB2 came in later and was seen as the relational database of the future. However, none of them was a fit for the client server world, and so entered Oracle. More recently, who could ignore Microsoft and SQL Server any longer?

Another reason for database redundancy is mergers and acquisitions. Two companies might have very simple technical environments. However, when they merge, you start to get a mess. Throw in a third company, and you start to have problems. A company’s technical environment is never usually a cause for an acquisition, and it is rarely an impediment either. It’s just something that has to be reconciled after the fact.

Regardless of how you get there, you end up with a big mess. There are problems associated with two or three database technologies; the problems are compounded with five or six, or even 10!

Inefficiencies due to multiple database technologies
The problems with having multiple database technologies are familiar to anyone who has worked in or managed an application support environment.

  • License costs. It is typically more expensive to continue maintenance on multiple databases. Your company does not get to take full advantage of license discounts. You may be a large database user in general, but you are a small user of many of the individual databases.
  • Upgrade costs. With multiple databases, it seems that one or more of them always needs to be upgraded. Sometimes you’ve just finished upgrading one when another one needs upgrading as well. Unless there is a major advance in capabilities, upgrading databases is a necessary evil that usually only provides marginal business value (if any).
  • Training and cross-training. In an organization with many databases, it seems as though everyone needs to know two or three. For instance, if you are working in the client-server or Web development area, you might need to know Oracle and SQL Server. This is why you sometimes see job descriptions for open positions that ask for prior knowledge in two or three databases. Many of the concepts associated with databases are consistent from one to the other. However, all of them have unique features that make it harder to be an expert.
  • DBA skills. The database administrators are the real experts in the databases, and it is very difficult for them to gain and maintain expert-level knowledge in multiple technologies. In fact, you are probably carrying more DBAs than you need to if it were not for the breadth of skills required to support all of the database technologies.

What is the solution?
If you had your choice, you would probably not want to be in the situation of having to maintain multiple database technologies to begin with. However, in many cases, the causes are outside your control.

The best solution for this problem is to adopt an architecture mindset with the planning horizon of at least three years into the future. You need a longer perspective because the short-term conversion pain and cost will almost always be more than the short-term benefit. However, if you look out far enough, the long-term benefits and cost savings start to look more attractive. Here are steps you can take:

  • Determine what technology or technologies make the most sense to standardize on, and which ones make the most sense to drop. This decision can be made from a cost, technology, or features perspective.
  • Look at the nonstandard database technologies and see if there are opportunities for conversion. For example, many vendor packages support multiple databases. During your next upgrade, perhaps you can also convert from a nonstandard database to a standard one.
  • Many older applications will be retired or replaced. In this transition, you may be able to make a database switch as well.
  • Check the business plans for applications that may require substantial changes or enhancements. There may be an opportunity to convert and retire a nonstandard database while substantial changes are being made to the application for another business reason.
  • Monitor the extent that nonstandard databases are being used. For one thing, no new applications should be developed using nonstandard databases. Second, as the application environment is upgraded over time, you may find that a nonstandard database is being used only by a handful of applications—perhaps only one. At that time, the license savings associated with totally removing a database may pay for the cost of proactively migrating these last few applications.

Most medium to large IT development environments contain a mishmash of database technologies. Your organization needs to understand and quantify the pain associated with supporting this type of environment—from licensing costs to the difficulty finding and retaining people with the right skills. From a strict cost/benefit perspective, the business value associated with migrating to a common technology platform rarely makes sense in the short term. However, if you take a longer-term architecture mentality, you may find a number of opportunities for retiring the older database technologies. Your vision should be to standardize—not today or tomorrow—but with an eye to at least a three-year horizon to implement that vision.