Databases are costly both on and off the mainframe. My past Total Cost of Ownership (TCO) studies suggest that database administration costs are typically a significant source of overhead in the smallest and largest of enterprises. The right choice of database in a mid-size firm can make a 10-times difference in three-year application TCO—not to mention its effects on speed to upgrade and develop new apps on the same database. An IBM study last year suggested that database administration costs can be as much as 20 percent of overall three-year, large-enterprise TCO.
However, ways to cut these costs aren’t always obvious. Not so long ago, Oracle announced its second- quarter results. Database license revenues were down by 22 percent, and user interviews suggested that the chief cause was high prices in a recessionary environment. Yet, user interviewees indicated that no one was thinking of migrating existing mainframe or Linux server apps from Oracle to, say, DB2. The reason, I have found, is that databases are uniquely hard to migrate.
Some of the problem stems from the way migration is performed—basically either “once the new database is up and running, turn off the old” or “keep both running forever.” I like to think of it in terms of catching the Martha’s Vineyard ferry at the last minute. This ferry has a deck flush with the dock, so you have three choices of getting on: 1) take an all-or-nothing running jump, in which case if you miss, you’re in the drink; 2) straddle the shore and the ferry, in which case your legs get stretched further and further until you fall in the water; and 3) stride forward as the ferry starts, so you’re smoothly shifting weight from the shore to the ferry. In the same way, database migration should be (but often isn’t) an ongoing process in which workloads are steadily but incrementally being transferred from the old database to the new one.
Still, some of the problem results from the incredible accumulation of proprietary “best practices” and unique features embedded in implementations of the most open of databases. There are metadata in the data dictionary, stored procedures, cost-optimizer settings, hard-coded app interfaces to the database, data-warehouse indexing, and undocumented “tweaks.” In one short span in the late ’90s, Informix offered a migration program from Sybase’s database as customers worried about Sybase’s long-term viability; IBM offered a migration program from both, and Oracle offered a migration program from all three—yet most of the databases involved are still operating. Customers have typically found that converting all those unique features is too risky and takes too long.
All is not lost. On the contrary, the last five years have seen a wealth of new opportunities to reduce the costs of existing databases: new ways to move the apps and database as a whole to a new platform, such as Windows-to-mainframe or mainframe-to-Linux/ Windows workload shifting; improvements in the automation of existing database vendors’ administration; or “data virtualization” and master data management, so that by querying in real-time across multiple databases users can reduce their dependence on one. All these approaches start from the premise that database-vendor migration isn’t the answer; the key prerequisite for improving database costs is to improve the database and its use.
However, the real key to success for IT strategists is to understand that fewer databases from fewer vendors isn’t always better. Integration of databases from multiple vendors has improved to the point where a properly planned strategy can achieve major cost savings by using an administrator-light database such as DB2 Everyplace on Linux for new department-level, mainframe- using database applications. Abstractly, standardizing on one vendor makes sense; however, in an area as vulnerable to vendor lock-in as databases, migrating to reduce the number of vendors is just as likely to result in higher database administration costs, additional migration costs, and new risks of migration failure. Folks, when you contemplate moving from IMS, VSAM, or even ISAM in hopes of saving money, it typically turns out not to be migrate or perish; sometimes, it might even be migrate and perish. ME