A Surprising Thought Experiment in Cloud BI TCO

Updated: November 01, 2010

I have found in my past TCO analyses that there are two areas where it is frequently possible to take a huge chunk out of application TCO: (1) database administration, and (2) storage software and hardware. The best way to lower storage costs dramatically today is to compress the data - new technologies offer the possibility of cutting needed storage by ½ or ¾. Certainly the cloud provider is more likely than the SMB to have that technology up and running, right now. Still, mature columnar databases with excellent data compression are already available from the likes of Sybase, and I anticipate that in the next 2 years, data compression will expand to all database and storage providers. So, if cloud BI providers have a big TCO advantage over SMBs' in-house solutions, I think it's not likely to be because of storage.

However, consider database administration. One way of thinking about it is to classify database vendors into tiers, based on their scalability. Roughly, the more scalable the database, the more the database needs fine-tuning and is designed for that, and the more administrators are required. To give you an idea of the effect, an old TCO study of mine showed that a simple app with 50 20-user local-office copies and a central "mart" required perhaps 250 administrators when it used the most scalable database, and perhaps 10 untrained office workers to do periodic backup for the least scalable - but quite sufficient - database. The result was that the 3-year app TCO for the "near-lights-out" database was almost 70% less than that for the highly scalable database, ignoring storage. If we add on, say, 25 terabytes of storage, then the TCO for the "near-lights-out" database might be 50% less than for the highly scalable database.

All right, so what makes the cloud BI provider better at picking such a database than the SMB itself? Well, a lot of SMBs came of age in the 1990s and 2000s. That means that a lot of them were from the era when "no one ever got fired for buying Oracle"; others are from the dot-com era, when every startup was buying "an Oracle and a Sun"; others still are from the mom-and-pop "Microsoft SQL Server comes with the PC for free" era. Oracle, it need not be said, is as scalable as they get. Microsoft has at times in the past been much cheaper to administer than Oracle, but its recent focus on data-warehousing scalability has raised questions about whether that's still true in BI.

What kind of databases do well at SMB querying where the data stores aren't of enormous size and low-cost administration is what matters? I call them the "no name" databases. They include vendors like Progress Software, which has made a living providing a database well tuned for the needs of ISVs and SaaS providers, or Pervasive. They also include, for larger data stores, products like Sybase IQ, which adds a surprising amount of columnar scalability to the Sybase database's ability to provide (in one major US financial institution) one administrator for every 250 database instances, or IBM/Informix, whose administrators swear it "just runs." They don't necessarily include products like MySQL, which has taken a long time to add administrative features, or Vertica, which may be still a bit immature in administrative features.

So here's surprise number 1: for many SMBs, it is indeed possible that cloud BI can deliver major TCO savings - if the provider uses a "no name" database. That "no name" database is often just as secure, robust, and performant for SMB needs as Oracle or DB2, but it's a lot cheaper to run.

Surprise number 2: although the cost savings are there, many SMBs won't be able to take full advantage of them. That's because it's not always easy to migrate existing BI data to the cloud provider; and that's what you probably need to do. Moving the data is hard, but not because the "no name" database is incompatible; it's because an SMB's whole setup is often already geared around an in-house data store, and disrupting that setup to actually, physically move the data can be tricky. That's why a database is often almost impossible to exterminate once an organization starts using it.

Related Categories
Featured Research