Enterprises that consolidate their business operations on as few database platforms as possible can reduce IT complexity...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
and improve data quality, but experts say there are several cultural and technical issues to address before beginning a database standardization project.
For starters, organizations need to make sure they have the right skill sets in-house -- and not just the database skills. According to experts, IT workers need to understand how the chosen database standard will interoperate with supporting applications, hardware and the many workflows and business processes that fill a typical day.
“You’re going to run into silos of administrators who are tied to a particular stack, which is the combination of the database with the underlying platform, whether it’s the [operating system] or the hardware,” said Tony Iams, a vice president and analyst with Rye Brook, N.Y.-based technology research firm Ideas International. “The skill set on the back end is going to be critical.”
Pay attention to political and cultural issues
The decision to consolidate applications onto a single database standard can also cause interoffice political turmoil. Even if the business argument for consolidation is strong, Iams said, dealing with individual and group preferences within an organization can be a big challenge.
“The political questions are kind of the thorny ones because they go beyond technology [to] the heart of people’s allegiances and preferences.”
Beware of compatibility problems
Companies turn to database standardization and consolidation to clear up the confusion that results from having multiple database systems supporting multiple applications. End users point out, however, that this confusion often exists for a good reason, and standardizing on one platform can be highly problematic.
Enterprises need to run the right applications to fulfill business requirements, and sometimes those tools were designed with a specific underlying database technology in mind. As a result, more database platforms come into play when business requirements change over time.
That’s why anyone launching a database standardization and consolidation effort needs to stay on top of application migration and compatibility concerns. “If your application that your business depends on doesn’t support the new [database] then the whole idea is essentially a nonstarter,” Iams said.
It’s also a good idea to determine the total cost of the application migration well ahead of time to make sure the project will be worth the time and effort, said Christopher Carter, a data systems architect and the founder of C.L. Carter Co., a Nashville, Tenn.-based independent consulting firm.
“There would be a heavy migration labor cost that you would have to incur, and then you would have to figure what your return on investment will be over the next couple of years,” Carter said. “Usually, you’ll find [after] a year or two years that you’ll catch up and your return on investment will start to appear on the bottom line.”
Database standardization often a matter of semantics
Companies that choose to move source systems from one database platform to another as part of their standardization project should know that many differences exist between the major SQL-based systems, according to experts and technology professionals.
“Tip number one is brace yourself,” said Nathan Allan, a database developer and architect with Orem, Utah-based Database Consulting Group LLC. “There are many very subtle, sometimes semantic differences between the systems, and oftentimes people assume that the differences between the systems are superficial.”
One example of possible difference between SQL-based database management systems centers on the way they handle empty strings. In some systems an empty string is synonymous with a null value, while in others it isn’t. That may seem like a tiny difference, but if gone unchecked, it could lead to unexpected downtime and lost business.
More differences between SQL-based systems can be found in their approaches to time-and-date functions, internationalization and the list goes on, according to Allan. “Despite a couple decades now of attempts at SQL standardization, we’re really not much closer than we’ve ever been.”
The task of identifying and quantifying the systems and applications that will be affected by database consolidation efforts can also present major problems. That’s why it’s important to allot plenty of time to make sure the job gets done properly.
“Oftentimes, you’ll have little fingers into your systems from all the different directions,” Allan said, “so actually determining the impact of moving a system is actually going to be is a project in and of itself.”