Ann All spoke with Marcus Collins, a Burton Group analyst and author of a recent report titled “Clash of the Titans: Comparing Enterprise Databases.”
All: Why is it so common for large enterprises to have multiple databases?
Collins: There are a of couple key reasons. First, there are mergers and acquisitions. With those, you end up with multiple large databases, the kind you have when you acquire multiple ERP systems, for instance. Another is what people call “shadow IT.” With that, you typically end up with multiple small databases. It’s usually a response to the perceived slowness of IT. A department might bring in SQL Server. Since the company probably has corporate licenses for Microsoft, they can do it. Departmental users have a problem to solve, and they want it to be quick and easy and to move on.
Another interesting reason is around the cost model. Who bears the cost of additional databases? IT tends to say, “Go with our defined standards.” Business will go ahead with another database because essentially there is no additional cost to them. They productize it and give it back to IT, and say, “You need to run this for us.” The IT costing model tends to be that IT runs everything, so there’s no cost disincentive to the business.
All: Your advice is to reduce the number of databases to reduce costs associated with the complexity of a heterogeneous environment. Is standardizing on a single database a realistic goal for most organizations?
Collins: The simple answer is probably no for established customers who have done mergers and acquisitions. It’s difficult to justify the cost of redevelopment to get to a single database. One of the keys here is it’s easier to develop applications than to retire them. It’s the legacy problem, which gets back again to the costing model. Redevelopment could cost many millions of dollars, where additional licenses may cost many thousands. There are no dynamics in play for organizations to say “We really need to get rid of these.”
Perhaps that isn’t the case for organizations that have grown organically. The key is to get control of your IT portfolio as it grows. You can’t say “Let’s do things fast and not worry about cost” or you will just end up with a legacy problem. It’ll come back to bite you, cost-wise. Before you go ahead and bring something else into an organization, you need to think carefully about it. I think the realistic advice is don’t get to heterogeneity simply because you didn’t think about it. But if the additional benefits (of another database) outweigh the costs, go ahead and do it. You must think about the additional costs and offset them against the business benefits. If you gain real competitive advantage by bringing in an application that’ll only run on SQL Server, then it’s a no-brainer.
The other dynamic is the business imperative. If organizations today in many cases are fighting for survival, the last thing they’re going to worry about is ending up with another database. This occurs on the departmental level as well, where people are measured on achieving business success. It raises the wider question of how organizations make strategic IT decisions. One way to is to get proof of concept in one part of an organization and then use it as a sort of poster child to the broader business. You can say, “Look at what we’ve achieved in marketing, and see what you can achieve in finance.” The idea of a top-down enterprise architecture approach is a very tough sell.
All: How specifically can organizations cut and/or control costs by standardizing on a database or at least reducing the instances of multiple ones?
Collins: Even if you have multiple databases, you can standardize your operational model, the way you do day-to-day operations, and reduce the overall cost. Database vendors are helping. They want to push that it’s cheaper to run database X than database Y, so they are focusing on automation of operation. As interesting as that is, does the business care? Probably not. But if IT becomes more responsive, that does interest the business.
The key for IT is to have standardization to reduce cost but also to become more responsive. You don’t want to invent a bureaucracy. You want to have standards so everything can run smoothly and make IT more responsive to the business. You want to be able to say to the business, “If you want to go outside (the standards), here’s what it will cost.” It’s like having a shopping list, if you will. You should be able to say, “The standard infrastructure costs X per month per gigabyte. Here’s how much it will cost if you want to do it another way.” Transparency is key.
In that respect, IT has to be able to put a cost on standardizing. Then what it has to do, of course, is add value. If you show costs of $10 a gigabyte and you can buy $8 a gigabyte down the road, then you are not showing value. So IT should structure itself so it begins first to add value. And then automate processes to the greatest extent possible to cut costs.
All: What roles should both the business and IT play in evaluating and selecting databases?
Collins: The demarcation is clear, although it’s not necessarily the way it’s done now. The business role is to come with a set of requirements. What business tends to do is say, “I need this and that, and by the way I want Microsoft Sharepoint.” Ideally, the business shouldn’t impose tools on IT. The business should focus on people and processes, not tools.
IT needs to come along, and say, “We can do it and even look at the tools you suggest, but we need to bring in security, scalability and other non-functional areas.” Then the decision should be made jointly. The right tool may fill a business imperative and not fulfill reliability and scalability. IT should be able to say, “Here’s what the additional cost of your tool preference will be.” It must be able to quantify those costs, and in some cases it can’t do that.
All: You emphasize that it’s important to get product roadmaps for databases. This is always a good idea when evaluating enterprise technology. Is it even more so when evaluating databases?
Collins: It’s very difficult to differentiate between the major databases today. They have become to some extent a commodity, in the same way operating systems have become a commodity. Vendors don’t like to hear that, they want you to think they have a technology edge. If you try to make a differentiation on technology, know that it is going to change. The vendors are in a technical arms race. So if you’re looking at a product, and you want some specific niche functionality you are interested in, be careful not to make it the one thing upon which you base your decision. The key is to bring in a number of different factors. It shouldn’t be about who has the coolest technology today. A strategic decision to go with a particular database vendor is a complex decision. You need to consider business, IT and commercial concerns.
All: You also note that it can be difficult to compare costs and performance due to the ways vendors present information. Any tips?
Collins: It is difficult to read marketing literature, look at vendor costing models, and come to a simple decision as to which is cheapest. In general, SQL Server has more smaller database implementations. If you look at the overall costs of management, it’s probably cheaper than Oracle. But that’s because smaller databases are generally easier to manage. So if you look at cost per database, that’s not a valid measure there. It comes down to being a more sophisticated decision.
What is your database organization going to do? Are you going to do lot of in-house development? If so, you’ll need to work with database vendors to tune performance. Organizations need to look at models of how they use a database. Look at the TCO, the licensing, the manpower, the costs to run it.
Because there are so many database implementations out there, you only have to go to user groups to find organizations with similar situations to yours. So seeking advice from members of user groups is a good idea.
Read More.
Posts
