The task of crafting and implementing a new database strategy or updating an existing one involves much more than simply calling in vendors or popping online to choose from the latest technologies, according to IT analysts and professionals.
IT industry veterans say that getting a database strategy right means teaming with business users to determine the computing requirements of individual applications, taking stock of available skill sets and ensuring that your database environment is flexible enough to handle changing business needs. Then you can use the internal intelligence acquired during the planning phases to seek out the right database technologies for your organization.
It’s also important to remember the difference between a “database standard” and a “database strategy,” analysts say. The former simply refers to the database management system (DBMS) technology or technologies that an organization plans to use. A full-blown database strategy goes deeper by documenting how individual technologies fit into the organization’s IT architecture and business plans.
“The strategy has to go beyond just choosing the DBMSs that you’re going to use,” said Donald Feinberg, a database software analyst at Gartner Inc. “It has to define where you are going to use them and how you are going to use them.”
Feinberg cited three reasons why an enterprise might want to consider updating or completely revamping its database strategy. The sluggish economy has organizations everywhere looking at ways to reduce costs and increase efficiency. The increased speed of business could be making some existing database system software installations outdated. And emerging high-performance information management technologies – such as NoSQL and column-oriented databases – are serving as a reminder to CIOs that it could be time to make a break from the traditional way of doing things in IT.
“You have to ask yourself if your strategy is flexible enough so that you can accept something new or different when it comes along and makes sense,” Feinberg said. “If it happens to run on a DBMS that is different from the one that is your standard, then that’s too bad. You have to use the different one because that is what the business needs.”
Key database strategy questions to consider
There’s no one-size-fits-all approach to creating a database strategy that can adapt to changing business needs. However, Feinberg and others said there are some key questions to keep in mind that can help simplify the decision-making process.
A good place to start, Feinberg said, is by taking a look at your organization’s portfolio of business applications and gaining a solid understanding of what they require from the database layer. And not just now: IT managers should be mindful of future needs when looking at current application parameters, he cautioned.
Questions to consider include: Is an application mission-critical? Does it need to be available 24/7? Does the application need a massive amount of data now, or will it eventually scale to that level? Does it require specialized or complex data? Will it be used only by one business unit or on an enterprise-wide basis?
The answers to those questions will determine the types of database technologies that are needed and can help enterprises avoid the tendency to “overbuy” and end up with expensive but unnecessary DBMS features and functionality, Feinberg said. Getting business users involved in the process also is important, particularly when an organization is purchasing new applications, he added.
Another way to avoid buying the wrong products is to evaluate your existing skill sets as part of the database planning process and then make sure you choose technologies that fit the skills you have in-house or ones you’re prepared to add, according to Chris Sorensen, manager of business intelligence at Calgary, Alberta-based WestJet Airlines Ltd.
That means asking questions such as who is going to support a DBMS and do the required database design and development work before finalizing plans for database projects. “Support and development are really huge things,” Sorensen said. “If you don’t get [a database strategy] off the ground properly, you’ll have very expensive tools sitting on the shelf because you never considered the people side of the equation.”
Building flexibility into a database strategy
Steve Florek, managing director of offender insights and knowledge management at Sandy, Utah-based SecureAlert Inc., said one way to build flexibility into a database strategy is to consider investing in a clustered database environment that can easily be scaled up to meet the needs of a growing business.
Florek essentially serves as CIO at SecureAlert, which sells Global Positioning System (GPS) technology designed to help courts and law enforcement agencies track the whereabouts of criminal offenders. He noted that companies frequently buy database servers or other systems that meet their current capacity requirements but then find themselves having to install new machines as performance needs ramp up. “In a clustered architecture, you can just keep adding nodes to get increased performance,” he said.
Florek also said that a database strategy should be clear about who controls the organization’s enterprise data model, which defines how data flows through the organization and how different data sources relate to one another. And preferably, control should be centralized, he added – otherwise, individual application developers may “start doing things to [data] without any sort of global thought, and you wind up with stovepipes and incompatible data designs.”
Standardizing on one DBMS vendor is another possible database strategy move. Feinberg said many small and medium-sized organizations can get away with that, but the situation typically is different for large companies with various business units. Standardization can also give vendors an edge on negotiating license fees, support contracts and service-level agreements, according to Feinberg. “They’re going to be less apt to negotiate with you if they know that there’s no competition,” he said.