The database is the engine of business IT. Databases lie at the heart of both custom and off-the-shelf enterprise applications. And whilst databases are sometimes viewed mostly as a tool for storing information, they provide the underlying functionality for tasks from customer relationship management to finance.
But this broad functionality presents a challenge for IT leaders when it comes to streamlining or modernising database infrastructure in order to subserve business agilty. Databases are so critical but also so tightly bound to business applications -- and by extension, business processes -- that changing the database risks disrupting the business.
Nor is it always simple to identify which databases support which applications or to decouple the database and application layers within an application "stack."
As databases are bought as standalone systems or separate components of higher-level applications or embedded in applications or even business services, companies can easily find they are running a plethora of different database platforms, supporting a wide range of applications and processes.
One single database instance might power several applications or application instances; but an application might also draw data from multiple databases. Sometimes these connections are not always clear.
As the chief information officer of one UK government agency explained, when the agency audited its IT infrastructure as part of a wider IT management project, it found applications belonging to other agencies running on top of its databases. These "guest" applications were not affecting database performance, but they had created dependencies and points of failure, unknown to the agency’s IT managers, said the CIO, who cannot be identified for reasons of confidentiality.
Changing database strategy
Nonetheless, pressure is growing for businesses to look again at their database infrastructures in order to promote business agility, especially in cases where the business is a heavy user of data and analytics. A requirement to store larger volumes of data is putting strain on some business database architectures, especially older systems (early versions of SQL Server, for example) that were not designed to handle large data sets. "People may switch ... because they want to move beyond historical analysis and move to predictive analysis or real-time analytics and to high-speed search," said Steve Gallagher, a technology specialist at PA Consulting Group. "Databases need to be faster and to deal with more complex data types."
The CIO of one UK government agency has said that, when it audited its IT infrastructure as part of a wider IT management project, it found applications belonging to other agencies running on top of its databases.
IT leaders are also looking more closely at basic database performance. But where in the past companies might have tackled performance bottlenecks through hardware upgrades, constraints around budgets, data centre space and even available power make that harder.
Often, however, the main motivation for switching databases is neither capacity nor performance, but cost. "Apart from speed, businesses switch because they are looking to do more with less: to have a lower TCO [total cost of ownership]," Gallagher said.
With IT budgets under continued pressure, analysts expect CIOs to look again at their database strategies to see whether it is possible to consolidate to fewer database instances, and perhaps to fewer vendors. In addition, many companies will be looking not only at licence costs and maintenance fees, but also at the staff costs of their database administration teams. "Left unchecked, database costs can become a significant part of the IT budget," cautioned Forrester Research analyst Noel Yuhanna.
Another factor is the shelf life of the database technology itself. Where businesses are running older databases and vendors have either announced the end of support for the software or its future is uncertain, CIOs might prefer to upgrade sooner rather than later. Hardware costs could also be a consideration. "Vendors argue that you need less hardware [with newer databases] because they perform better," said Philip Howard, an analyst at Bloor Research.
A change of database strategy might also be forced on the IT department, through other changes in the business. Mergers, acquisitions and the sale of business units can prompt either the consolidation or splitting up of database resources. But upgrades or changes to business applications can also force a change to their underlying databases, and this can be a trigger to look at other database instances the business is running.
In some cases, hardware changes too can be a reason to change databases -- either because of a move between platforms, typically either to Linux or Windows to take advantage of lower-cost server hardware, or to support server consolidation and virtualisation. And more forward-looking CIOs are, with reference to increased business agility, looking at how cloud computing will affect their business applications, and so their underlying database strategy.
The barriers to database switching
Switching databases is not a risk-free task, though. Because businesses depend so much on their data, a database change is not just a simple software update; it goes to the heart of an organisation's IT strategy. So the reasons for switching must be compelling.
Even database vendors concede that a database platform switch -- rather than a version upgrade with the same vendor -- is still the exception rather than the rule.
"Only a couple of clients have moved databases without upgrading something else, and that has been down to performance," said Ian West, UK information management leader at IBM. "We've seen big bottlenecks in data warehousing environments where there was nothing wrong with the hardware."
Chris Glynn, a senior consultant at IT integrator 2e2, said, in a similar vein: "There's not always a need to change -- look at how you are using what you have got. ... Sometimes clients recognise themselves that the issue is with the database layer. Databases are often designed for transactions, not reporting systems or analysis."
The ability to either switch or consolidate databases is also limited by several factors. Applications running on top of the database, or drawing data from it, may need to be updated in order to continue functioning. And some applications -- including human resources and accounting packages -- use embedded database instances. These databases usually cannot be uncoupled from the application, so database consolidations or conversions could mean switching to a new application as well.
Then there is the business risk. Moving to new databases likely will disrupt business processes, at least in the short term. For that reason alone, CIOs often find it easier to migrate databases at the same time as other technology upgrades. Doing so also spreads the cost of contingency planning. "Businesses today are more dependent on IT than ever; the ability of IT infrastructure to drive and enable the business is intrinsic," noted David Rajan, a technology director for Oracle UK, Ireland and Israel.
In the slightly longer term, however, database migration is on a path to becoming easier. As well as greater compatibility between proprietary SQL extensions and data types and technologies for exchanging data, such as XML, some vendors are developing database compatibility layers (DCLs) that will allow one database to emulate the tool set of another.
Currently, IBM is the main vendor offering a DCL. Forrester predicts, though, that others will follow with their own products.
But IT departments that are planning to move to a new database should test the technology carefully before committing critical systems to it, cautions Bloor Research's Howard.
"Do a pilot or proof of concept before moving mission-critical applications," he said. “Migrating noncritical applications is fine -- for critical apps, I have my doubts."