I have been so busy getting ramped up on GoodData that I haven't had a minute to post here in over a week.  On Friday, I am headed out to our R&D Center in Prague, Czech Republic - looks horrible doesn't it? :) - for a week to do a brain-meld with our engineering team and deep-dive the GoodData architecture. I've learned a lot about it in the past two weeks but clearly, there's nothing like sitting down with the hard-core developers and discovering how the sausage has really been made for the past two years.

One of the unique things about this platform is the fact it was designed for the cloud from the get-go. "Born and bred in the cloud" as they say.  And that was several years ago, before the cloud "explosion", when the idea of running a full BI stack in the cloud was just a fantasy to most people.  They said it couldn't be done (matter of fact, some folks still claim that, but reality proved them wrong in 2009) but Roman Stanek and his guys did it and I think the results speak for themselves (here's one of many examples).

I think the "born and bred in the cloud" stamp is important because there is so much hype and hyperbole about all things "cloud" these days. Especially in the BI space.  A lot of times when you hear or read things about clouds, it tends to feel like this (with apologies to my Thailand readers who obviously understand that script).

To separate the wheat from the chaff, you really have to ask the right questions. Namely, is your architecture really cloud-based or did you simply throw bits over the wall onto a bunch of hosted boxes (or VMs)?  Do you understand the meaning and implications of real multi-tenancy? Are you simply shifting technology because it's hip (marketing-wise), or do you truly possess cloud DNA? And on the non-technical side, do the economics make sense?

In the mid-1990s, ASPs (application service providers) were all the rage. Everyone wanted to "go ASP".  I worked for some of them. But the "software" crawled, got in the users' way, was hell to maintain and deploy, and the costing model didn't work.  Many (most) went belly-up. But hey, at the time, it sounded good and the VCs wrote checks.  But already back then, painful lessons were learned.  Namely that it's virtually impossible to change horses in the middle of a race. 

The inherent value of "born and bred in the cloud" platforms is not simply technical to me.  Clearly the engineering is intricate and "cool", but what's really at stake is what Roman calls "price-based costing".  (Speaking of pricing and clouds, check out Roman's latest blog post, it's à propos!).  This is a Peter Drucker concept but it applies really nicely to cloud-based economics.    

Price-based costing is defined as "choosing a desired sales price and costing out production to meet that sales price with a desired profit margin".  The idea is to first determine what you want to charge for a product or service, and then work the development economics backwards to achieve that price point. When you're starting from scratch with a cloud-based technology, you can pull that off, because parameters, cost and elasticity are linearly deterministic.  The up-front costs are fairly low and the flexibility is fantastic.  Additionally, the tools are cheap, commonly available and simple.  

Consider that the GoodData backend is almost all coded in Perl on Linux with a REST interface!  (I'm not suggesting Perl or Linux are "simplistic" but I worked the MSFT development stack all my life, and I can see orders of magnitude in complexity reduction here).  

So now, if you have legacy bits and a "ground-based" engineering platform (and people), you're stuck on a price structure in this bearish economy, and you can't just flip to a cloud model as a panacea, no matter what your Marketing people tell you.  Whether you sell proprietary or open source software, you're in the same predicament. Sure, you can provide less functionality or cripple your offering (or worse yet, try to make do with less people), but just throwing it inside a "cloud" won't do it economically, and the outcome will likely be painful. The DNA just isn't there. 

So when some BI vendors simply slap some code (open source or not) onto AMIs (say like Mondrian for example) and call it a BI on-demand offering with a ROLAP engine, it makes me wonder if they "get" the concept at all.  Mind you I ponder the same thing about big league BI tooling players who simply re-package their (oh so heavy) bits into virtual boxes and call it a cloud day as well. 

With a genuine "born and bred" cloud model, you have fine grained leeway in adjusting the pricing dial. Guess what, you can even turn it down all the way to zero and still survive for a long time at given data volumes.  At GoodData, for example, you can get 10MB accounts for free.  Not a huge amount, certainly, yet sufficient to "play with".  But no matter how many people sign up for that, GoodData's cloud platform can handle it both volume wise and cost wise at ridiculous scale and at the flip of a switch.  Scalability in a "born and bred" cloud platform is very (did I say very?) cheap.  And pricing can be finely tuned by throttling the technology, not the other way around. And this isn't about taking a loss for marketing purposes. GoodData, like any other sound business (except OSS maybe), isn't about giving stuff away for free, believe you me.

So I guess my point would be: caveat emptor.  The next time you're considering replacing that big honking on-premise BI tool with the vendor's "new improved" cloud-based on-demand version, check under the hood and make sure that "born and bred" DNA is there (hint: not likely).  And the next time you're considering a "native" SaaS cloud vendor for your BI analytics, ask the right questions about what makes their backend tick.  You might be in for an interesting smoke and mirrors show.

Read the original blog entry...