Database Consolidation as a Strategic Weapon

April 2, 2008

It’s not an obvious fact that databases could be linked to strategy.

In a meeting last week with a local credit union, I asked about their core system performance and imaging systems, and they mentioned that performance was very poor when their tellers were in the Synergy imaging system. As usual, IT was ready to pull their hair out – but it didn’t have to be that way.

A credit union must be intentional with its data. Databases hold data, and your data (including the way you use it) is often the only difference between you and your competitor.

SQL (Structured Query Language) data bases distributed haphazardly across ten, twenty, or even fifty servers are not only hard to manage, hard to recover, and costly to manage for IT personnel, but are also costly from a licensing perspective.

Too much application software has been sold to credit unions. Vendors install their application, including an SQL data base, then walk away. Little if any attention is paid to the SQL data base, since a vendor’s primary concern lies in getting the application up and running properly, rather than optimizing the data base itself. As the predominant type used by my clients, SQL data bases need care and feeding, oil changes if you will, to avoid having them slow down.

A common excuse I hear is: “The vendor won’t support us if we touch the data base.” This just isn’t the case. In reality the vendor won’t provide support if you touch the application, but adjustments to the data base itself can be made without any problem.

So where does IT strategy fit in here?

A database consolidation strategy should encompass the following elements:

1) Has data base recovery been tested? For example from a tape back-up?
2) Has the data base been optimized for performance?
         a. Data base hardware optimization;
         b. O/S optimization;
         c. Application optimization;
3) Have the countless SQL databases been consolidated into 1 or 2 load-balanced servers?
4) Will the consolidation of databases help with DR planning?
5) How would this work with virtualization?
6) How would this work with a SAN (storage area network)?
7) Do you have expanding or contracting back-up windows for your databases?

Reviewing your database planning and approach can be very useful. The following elements should be covered when addressing SQL databases:

1) How many SQL instances do you have?
2) Can you outsource the optimization of SQL? This would work sort of like oil changes and tune-ups for your car.
3) How does one consolidate, and what is the staffing impact to consolidation?
4) What is the back-up plan?
5) What is the recovery plan?
6) Has it been tested?
7) What is the licensing impact?

Finally, ask yourself this: How much would our managing costs drop if we consolidate SQL data bases in our environment?