Chief BIAS Officer

Your Computation Mileage May Vary

Computation may be the first energy using technology where there is no natural limit on how much people will use. E.g., consider cars - I might want a giant SUV, but I don't want one 10 times bigger than that. There's a practical limit here. But in computation? Why wouldn't I want a massive supercomputer at my beck and call 24/7? If it makes my life a little more convenient then why not? It's not like I have to haul it around with me or park it, and it can be literally anywhere in the world and I don't care. Now, in the era of big internet search engines, a huge number of computers are at my beck and call any time I want. I type a query in the box and perhaps thousands of computers jump in a data center somewhere. Also, many computers have been scouring the internet preparing the data they are jumping to send back to me when I query them.

These computers and the energy they consume weren't there a few short years ago. Now they're turned on and busy processing the queries we all throw at them. So, my personal energy consumption due to this computation has gone up quite a bit. There's a carbon footprint here. Normally we don't think about the energy consumption of these computers. What is the carbon footprint of my internet searching anyway?

Well, let's say the thousands of computers that jump when I query the internet are racked up. A standard computer rack can hold from 20 to 80 computers depending on model, and can consume 20Kwatts of power. Cooling eats up another 50% of that power, so 30Kwatts total per rack. When I say thousands of computers jump for me, that means order hundreds of racks. So let's say 100 racks of computers at 30Kwatts per rack.

That's 3+ Megawatts.

Just how much energy is that? Is that a lot? It sounds like a lot.

Well most people drive cars and understand energy in terms of gallons of gasoline....so let's convert 3 megawatts into gallons of gasoline burned efficiently, per unit of time. I drive an efficient car (not the mega SUV I mentioned above), so I use up about 10 gallons of gas a week. I use my favorite internet search engine, perhaps 10 times a day. Let's say my queries take 1 second each for the thousands of computers that jump whenever I search. So that's 10 x 7 days x 1 seconds = 70 seconds. So 70 seconds of 3Megawatts is 210 Megawatt seconds. A gallon of gas contains roughly 35 kilowatt hours of energy which is 126,000 kilowatt seconds, or 126 megawatt seconds. So my google searches for a week burn up about 1.666 gallons of gas a week. This is about 1/6 of my regular fuel consumption per week.

Furthermore, it costs, at the current $4/gallon, around $6.40.

Now, the above estimates of compute time are probably overly generous. I just did a google search, and they say it took 0.32 seconds to execute, quite a bit less than my estimate of 1 second above. Also, I don't know if that's the total computation time, or the parallel computation time on some huge cluster of computers. If it's just one computer spending that 0.32 seconds, then the energy is of course much less.

But that's beside the point. I want really high quality information available at my fingertips. If thousands of computers did have to jump to get it for me at my every whim, then I don't really care.... there's no natural limit to what I want here. It' s not like driving a giant SUV where a much bigger one wouldn't be interesting. Why would I care how big the computer that serves me has to be. It's not like it has to fit in my house.

That is, until the price tag for the energy comes into play. And the carbon footprint of that energy if it comes from fossil fuel.

Amazon, Microsoft, and Google Reinvent the Database - Did it Need Reinventing?

Amazon has introduced a simple database, Google's app engine includes a simplified database. Microsoft is beta testing SQL Server Data Services, which despite the name "SQL Server" is anything but. It's got a new Linq-based query system.

Haven't these guys ever heard of a little something called SQL, which is a standard? It feels more like Google wants to lock you in with their Google-specific data API, and ditto for Amazon's DB and Microsoft's new baby.

This reminds me of the browser wars all over again. Different players, same slug-fest. Nobody is taking the interests of the developer who wants portability to heart. I want to deploy an application and I want to be able to use either Google, Microsoft, or Amazon because my application is written to some standards. These parties are behaving as if that is exactly what they don't want you to be able to do.

At least on the Amazon cloud I can run whatever Linux system instance I want, so I can run a database of my choosing. Google provides no such flexibility (yet).

All this database innovation would be fine if it really delivered value, but I really fail to see the advantages of these new systems over say, a SQL subset, which could be simplified substantially from the broader SQL standard. Not for a real system anyway.

Open Source, GPL and SaaS

So, there are lots of reasons why SaaS rocks as a way of delivering functionality to customers. One of them is the ability to make good use of GPL'ed software.

At a regular closed-source software company, you can't include any software in your products that you get from the web which carries the GPL (Gnu Public License), because this license requires all "derived works" to also use the GPL and be open source. This is why the GPL is often called the "Gnu public virus", the license contaminates the software it touches.

What's worse, there's a more limited LGPL, which is supposed to allow linking to other software without having the GPL provisions apply to the whole linked "work" of software. Though this would seem to fix the problem, many software companies don't allow use of LGPL software either. (Reasons here seem to be more paranoia about patent restrictions, than real, but lawyers are lawyers.)

Here's the trick: The GPL is troublesome only for companies that distribute software. Here's where the SaaS idea wins. We don't distribute our software. We're a service provider. We have no problem at all basing our service on software built from GPL'ed pieces. We're in perfect compliance with the license.

The GPL recently was updated from v2 to v3, and there was worry that v3 would close what is called the "service loophole". This didn't happen. GPL v3 still allows the service loophole. They decided against closing it.

Net result: there's a huge and growing body of open source software, and the largest part of it carries the GPL license. As a SaaS provider we can exploit this base of code to do what we want without fear.

This is a big advantage over "ordinary" software.

SaaS vs. On-Premise Software for the Enterprise - Round 1

The SaaS delivery model is quite compelling to me. I founded a dot-com company back in 1999 which was what we called back then an “application service provider”, but the acronym ASP now seems to mean “average sales price”, and SaaS is what we call this deployment strategy today. Anyway,  we delivered an information service to Internet portals which they used to enhance their search results. It was here that I discovered the sheer joy of being able to select and standardize on a processing platform independent of the customer’s choices. I say ‘joy’ because on-premise software in the enterprise space is really difficult to create. I have to digress here a bit to tell you why.

 

Today, there is not much difference between computers from the various manufacturers. The reason one company is an HP shop and another a Sun shop probably has little to do with the technology from those vendors and much to do with which vendor has a superior sales rep in the territory covering that company. This is not cynicism. It's just that computing platforms are largely commodity these days. There’s no value being added here by these platform selections, but it implies that an on-premise software offering from any vendor has to run on both Sun and HP platforms, and many others.

In enterprise software, this diversity of platforms creates a tremendous overhead for on-premise software companies. Consider a standard enterprise integration software package. It must run on Unix variants from IBM, Sun, HP, also Linux, Windows. It might also have to run on mainframes, mid-tiers (AS400 and such). It must support many versions of the OS for each, it must provide reliable connectivity to Oracle, DB2, Sybase, and many others, and many versions of each, not to mention every ERP platform (+versions thereof)…. I think you see that the combinatorics of this make QA quite troubling.

It gets worse.

There’s this aspect where every important feature of enterprise software has to be available but also pluggable. E.g., when selling a software package to a customer they will ask: “Does it have high-availability (HA) features?” The answer here is supposed to be “yes”. But another customer will ask: “Does it work with the HA package I already bought and am using for these other systems I have?”, and the answer here is also supposed to be “yes”.  So HA has to be both built in, and pluggable. This is a nightmare for a software architect for enterprise software. Making a reliable software system where something as intimately configured as HA is pluggable is…. well, very challenging.  Scary really.

Now consider SaaS instead of software packages. The provider, e.g., me, that is, Oco, selects an approach to scalability, HA, etc. we select a standard platform. We get big economy of scale from this. We have only to support a small number of versions of anything, and that’s just so we retain some internal flexibility in what we’re doing to provide reliable and performant services for our customers. This frees us up to concentrate on adding value by adding the features our customers need. QA is vastly simplified because the combinatoric explosion is gone. Involving our customers in the data-aspects of the QA is also easy in that new and old versions of an Oco service can be simultaneously up and usable. Customers can evaluate/test a new one while continuing to use an older one. There’s no “forklift” upgrades i.e., where the new software version supercedes the old one, and upgrades it and there is no going back, no agony over whether installing a new version will disrupt a prior functioning system, etc.

To a software developer, working on the features is where it's at. It's more satisfying to deliver more features to customers sooner. It's liberating and energizing. All these lead to good psychology for keeping the developers motivated, and that adds up to satisified customers.

Now if you consider the arguments above, appliances (product consists of hardware + software) can also a reasonable approach, so long as maintenance of the system isn't a burden placed on the customer. But that is a subject for a future posting.

Business Integration - Dare I say "Semantic" Integration?

There's a number of fairly deep insights about what Oco does that explain a number of issues in our industry. There's all these stats about how 1/2 or more of BI/DW (data warehouse) projects fail. There's a reason for this: there's a big gap between the IT systems and staff who do BI/DW projects, and the business people who must use the data to make business decisions. The gap runs two ways. The IT folks don't know enough about the business, and the business people don't know enough about the IT systems.

A big part of the value Oco provides is our structured methodology for figuring out the business metrics needed, and our technology for finding them in the data. This allows us to close this gap.

What Oco does is what I call semantic integration.

Now "semantics" is my 2nd least favorite word. My least favorite is "ontology", which is only used to obfuscate from what I can tell. I only use the word "semantics" to distinguish from "syntax", i.e., by semantics I mean "more meaning than just syntax". I hope this becomes clear below.

What most projects (the kind that often fail) do is syntactic integration. IT folks are told business people need more data. So they set out to do what they can do, which is to collect together all the data of the organization in one data warehouse; however, they lack the business knowledge to consolidate disparate information into common concepts. They can access and move the data all into one database, because that's a syntactic problem.

I live in Red Sox Nation (yes I live near Boston, yes we have been sports spoiled for a few years now. Guilty as charged!), so let me illustrate this syntax vs. semantics issue with an example from baseball.

Suppose I have a data file. In it is a bunch of records about baseball player statistics. One of the fields is named "AVG". It is an integer. This is very likely to be the batting average, and we all know that batting average is a number between 0 and 1, typically rounded to 3 decimal places. Batting a thousand is 1.000. Typically this kind of data would be stored as an integer, not a decimal.

Syntactically, I can access the AVG field, and put it in a database column of my data warehouse and I can even do validity checking to make sure no value is negative or above 1000. This is all low-level syntactic stuff.

Now, moving up to the business or "semantic" layer. A real baseball fan or manager, who understands the business, knows that nobody bats above 0.500, and here's an interesting thing,... in fact a batting average isn't even computed for a player until they've had at least 12 at-bats. This allows one to deal with missing data in the data set, or at least some of the missing data. So I hope you see how I needed to understand the data in a more powerful way. I have to get the the business meaning of the data in order to understand how to deal with simple issues like whether it's ok for this data field to be missing.

Ok if you are following my argument, but it goes deeper. A more savvy baseball manager knows that batting average isn't such a great statistic, that on-base percentage is actually far more predictive of whether players help win games. This is real business knowledge. So, if I am trying to evaluate players, I need to compute, from whatever data I have, the on-base percentage. Knowing this I can take data from disparate systems which contains a variety of low level raw stats, and compute the on-base percentage from them. I also need agreement across my team, or league or whatever, that this statistic is one we should all measure in the same way, and when we say "on-base percentage" we should all mean the same thing by that.

This is what I mean by semantic integration. Without this agreement that on-base percentage is the metric of merit, you are stuck at the syntax layer wondering why you don't have compatible data coming in from each of the source systems into the data warehouse. That is, the IT person who hasn't been told to compute on-base percentage doesn't compute it. The data analyst trying to use the DW doesn't find useful semantic metrics like on-base percentage in the data. Rather they find the raw ingredients from which it could be computed, but not consistently or easily. They can't do the needed reconciliations to allow on-based percentage to be computed easily because they're operating below that level of knowledge.

Now flip over to the role of the business department trying to use a data warehouse. The data analyst can't analyze the data because they have to do the semantic integration first. All the data is syntactically integrated, but it's not exactly set up to allow computing the statistic of interest. A very complex integration must happen in the queries on the data warehouse to get to something meaningful to the business. This is why data warehouses spawn data marts by the way, the data mart provides some of the mismatch. It is used to fill in some of this missing business semantics.

This ability to understand the semantic integration that is needed, to facilitate a discussion among the business people who need the data and extract from them what are these metrics and then use them to drive the lower level syntactic-level integration - this is truly what makes Oco work. This is a key part of what makes our solutions valuable.

My BIASes

Welcome readers.

This blog will contain my opinions, call them my biases if you want, on topics related to Business Intelligence, and Software as a Service.   

My acronym "BIAS" for "Business Intelligence as a Service" is very unofficially what Oco (www.oco-inc.com) does.  I say "unofficially" because I did not check with the VP Sales and Marketing before starting with this (Hi Anil), some other folks said "go for it", so here we are!

Lots of blogs I see are collections of snippets each roughly with content of "Check THIS out" containing links. You will definitely not get these sorts of items here. I will comment and link things when I have something useful to add.

Many people are curious about what makes SaaS such a good idea, and I have pretty strong biases/opinions about this subject. I am CTO (or CBO) at Oco because I'm a big believer in the importance of this evolution of computer technology. I will share the reasons why I decided to get into this specialty, and why I believe it will be successful and important in the marketplace. I think these reasons are relevant to people on the buy-side and the sell-side of this technology who need to understand its advantages. I believe many of these advantages are actually quite subtle and not yet well represented in cyberspace.

As for bias and non-bias: I considered posting this blog as some neutral sites where there are other bloggers on related topics. I decided not to go there because the blogs there have this fairness about them with respect to vendors, and the writers of them don't work for vendors, and so on. That is so not me! I am far too biased. I work at Oco because I'm passionate about what it does, the value that delivers, and I believe it is important. Yes, they pay me. I think everyone understands that.

That said, this blog is not a marketing vehicle. I take my reputation as a technologist very seriously, and I would never tell someone that what Oco has to sell is good for them to purchase unless I firmly believed this was truly going to make their life easier, solve a problem, or generally add value for them. So while my biases will be expressed here, you can be assured that my biases are for good technical reasons, or at least intuition that I hope is correct, and not just because it is what my company happens to sell.

So, that's enough of the caveats and "bias" puns.... 

Many people are looking at the SaaS trend today and want to understand how and when to engage with it, what it really means, why it's a good idea, etc. I've been in high-volume commercial data processing since 1995, and enterprise software during that entire period. I've seen the issues of enterprise software development (and it's achilles heel, QA, which will be a post "real soon now") and I strongly believe this hosted/cloud "as a Service" deployment paradigm is very clearly the way for companies like mine to deliver value to customers most effectively, and specifically for business intelligence applications to be created and deployed for businesses today.

Thanks for reading, and I hope you find subsequent posts useful. Please comment on them. Don't hesitate. Show your biases please. I'm convinced most people have good reasons for them.