A Surprising Thought Experiment in Cloud BI TCO

Recently, I have been thinking about whether cloud BI really does deliver significant cost savings. I must note that I have been skeptical about that: BI is about data, and the cost of handling data, often the biggest cost of data-driven applications, tends to be close to the same across architectures. Thus, even though in most cases cloud multi-tenancy and sharing of databases across enterprises can deliver some enterprise-app cost savings, they are minor compared to the cost of data administration (which should be close to equal between in-house and SaaS) and offset to a great extent by added networking and monitoring of an external provider.

As I often do in these cases, I performed what Albert Einstein used to call a “thought experiment”: I asked myself how, in various specific SMB cases, cloud BI might stack up against “enterprise” BI in TCO. Frankly, the results surprised me. It appears that there are indeed areas where cloud BI has a major cost advantage over in-house BI – but those cases are not the ones that vendors seem to be citing.

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.

Yes, it makes sense to me that a cloud BI provider can deliver major cost savings, if they are using a “no name” database and if you can move your BI data to their cloud. On the other hand, if they are using a “no name” database, they’re certainly not going to boast about it. The acid test is the price: if your cloud BI provider gives you a price not only much lower than the Oracles of the world, but also lower than their newbie competitors, and is not boasting about the scalability of their (unnamed) database, it’s possible that they’ve figured out this neat trick for better profitability. Just in case, ask.

At the same time, SMBs should ask themselves what to do about their existing databases. Yes, it’s hard to change in-house databases; but why can’t you take new BI workloads or new data types and try them in-house on a “no name” database? It may be too tough to do, in which case cloud BI is a great alternative; or you may find that Progress, Informix, or even Ingres Database (once a proprietary enterprise database, now open source) is a strange but highly effective BI infrastructure.

I conclude that for SMBs, it is indeed possible to find a silver lining in a cloud – but also inside your own local office. Who woulda thunk it?