March 2010 Previous month Next month

# The Only BI Cost Formula You Will Ever Need

Posted by Brad Peterman Mar 30, 2010

I'm continually amazed (and horrified) to see the annual BI maintenance and development budgets of clients that I visit. I think they are truly amazed themselves, and many times they wonder how they got to that point in the first place. It got me thinking about the parallels to automobile ownership. Did you ever have a car that you bought new, and then 5 years later you looked back at the cost of ownership of the car and said to yourself "HOW did I spend this much over 5 years on a single car?!"

Does the cost cycle feel like this?

Purchase price, warranty, add-ons, upgrades, repair parts, labor, tires, plugs, oil changes, parts, labor, towing, tune ups, new parts, recalls, repairs, labor, break job, tires, labor, etc...

It's likely you were caught in the complexity trap of cost. Some cars come off the line for \$20k and cost you \$5k to operate over 5 years. No real problem there. You have to expect some cost of ownership and maintenance. So why is it that many cars that cost \$50k (new) will cost you an additional \$30k just to operate over 5 years? Shouldn't they be even cheaper to operate, given the high initial cost? The problem is the complexity cost formula. It always prevails.

That which is more complex and requires greater specialty of skills will naturally cost more to maintain over time.

Think about it. Doesn't this same cost formula hold true for anything you own? Cars, houses, power tools. How about your company? Your government? It always holds true. That's why it's no surprise that this formula is at the center of the skyrocketing maintenance costs for traditional BI solutions. Here is the formula in its simplest form:

## Cost of BI = (# of moving parts) X (# of specialty skills needed)

Using this formula, break down the BI solution(s) you already have, or even those you might be evaluating.

1. How many tools are involved to get data from source to user? How many layers and processes does a column of data have to go through? How many repositories, databases, cubes, warehouses, data models, scripts and libraries does the data need to travel through to get onto a dashboard? These are your moving parts.
2. How many specialty BI skill sets and software skill sets are needed to deliver BI with that solution? How many data modelers, ETL designers, DBAs, data architects, BI tool specialists, OLAP analysts, warehouse technicians, report developers, project managers and BI designers does it take to produce a dashboard or BI analytics interface? These are your specialty skills.

Multiply these together and you quickly get an accounting for those massive development and maintenance costs of traditional BI. The costs of specialty skill sets have gone up rapidly in I.T. over the past 10 years and will continue to rise. This puts great pressure on companies to either do less BI or to find a way to outsource some of the skills. If you haven't already seen this happening then keep your eyes open, you will.

The good news is that more and more companies are rejecting the tendency to add even more complexity and specialty to their cost formulas. This is helping bring about simpler, more powerful BI tools that can utilize traditional skills sets and business knowledge that are abundant in our companies today. Do the same. Be aware of the BI Cost Formula, and don't fall victim to it.

Posted by mmy Mar 22, 2010

"SIB" at QlikTech stands for "Seeing Is Believing". Some people call this a "proof of concept." In the SIB process we build an application at a company's site in just a few days that can access their data, and analyze and display answers to solve specific business objectives. In other words, you get to see your BI solution in action--connecting to your data, not some canned program--so that you can see if it works as well as advertised. There's relatively no risk-on the other hand--to chance a decision without such a proof of concept, could cause hours of frustration and negative consequences down the road.

For example, a CFO at a regional bank was looking for a solution to provide instant ad-hoc reporting/analysis of P&L's and account information by branch, for himself and other end-users. After trying other solutions, the best they could do was to provide end-users with access to desired information at the end of each month, and this included tedious manual manipulations of data in spreadsheets. Although the CFO needed to solve this problem, he was leery of making a wrong decision. A "SIB" made sense to the CFO, because he was willing to risk a small amount of time and effort to evaluate and witness a potential solution running off of his own data, rather than committing to a larger investment in time and dollars into an unproven solution.

During the "SIB" which was observed by the CFO, his CEO, and others, there was immediate "buy-in" by all when they saw how easily their desired information could be visualized and what this would mean for the performance of the bank. Result: consensus and recognition for a job well done.

Conversely, many executives buy a complete implementation on faith when choosing reporting, analysis or dashboard applications, and hope that the implementation will work with limited evidence to support their decision. Each night they have to go to bed hoping and praying that their investment will succeed and pay-off.

# What is Scalability?

Posted by Brad Peterman Mar 15, 2010

One of the best buzz words in BI is "scalability". Heck, it's even fun to say...scay-luh-bill-uh-tee. The problem, like any good BI buzz word, is that is has way too many meanings that are convenient, but misleading. Here is the Wikipedia definition of scalability:

"scalability is a system's ability to either handle growing amounts of work in a graceful manner or to be readily enlarged."

So, this means that mowing your lawn with scissors IS scalable. Or put another way, "Scissors are a scalable solution to cutting your lawn".

Uh, no. Not so much. The Wikipedia definition is missing something to ground it in reality. If we add something to the Wikipedia definition, we get....

"scalability is a system's ability to either handle growing amounts of work in a graceful manner or to be readily enlarged, at a cost threshold under which you are willing to perform the scaling."

Ah, better. Now scissors are only a scalable solution to cutting our lawns if we are willing to hire 60 people to simultaneously snip away for 4 hours each week. OK, so what does this mean to the business intelligence world? It means less of these conversations with your vendor:

Vendor: "Our tool scales to 10,000 users."
Client: "Yes, but I will need 100 servers to do it."

Vendor: "Our tool scales to 10 TB of data."
Client: "Sure, but I will need dozens of cubes and 16 hours of batch processing at night."

Vendor: "Our tool can scale to the largest enterprise needs."
Client: "As long as I have the largest enterprise support staff to keep it running."

The answer to whether or not a BI solution is "scalable" is, in real life, directly correlated to your ability to perform the scaling under acceptable cost thresholds. Put another way, scale is not relevant when it requires costs that exceed your tolerance. Make your cost tolerances part of the BI tool selection process and you will be able to focus on much more relevant and meaningful requirements.

• How much does a 3-tab dashboard with 12 charts cost to build?
• Can I add 5 new columns and a new drill-down metric to the dashboard, with testing, in under 8 hours?
• How long does it take to build 4-5 dashboards with 500 MM rows of data for a user base of 1,000 users?
• How much will it cost me (in time and hardware/software) to scale out my solution from one production server to a cluster of 3 servers?
• How many skill sets (and which ones) are needed to maintain a 15 dashboard solution for a user group of 2,000 users?

These questions get to the heart of our "new" definition of scalability, which only accounts for scalability "at a cost threshold under which you are willing to perform the scaling". So the next time your BI vendor starts throwing the "scalability" word around, remember that scissors are made for paper, not grass.

Note: this blog was not endorsed by or funded by any lawn mower manufacturers, nor does the author promote, sell or profit from the purchase of said machines. ;-)

By date:
By tag: