I recently came across a white paper on the "five styles of BI" and thought that would be an interesting read. As it turns out, more interesting than I expected. In this paper, the vendor (in order to protect the innocent, we'll just call them MacroTactics) made a statement regarding the performance capacity of this particular vendor's solution: 72,000 reports per hour. Let's see, 72,000 reports per hour... that would be 576,000 reports in an 8 hour day... and 149,760,000 reports per year. Wow. Who's reading that stuff?

Now, I fully buy in to the fact that applications that deal with lots and lots of data need to be hugely scalable, but what I don't buy is how this is in any fashion a measure that anyone can use to figure out if a particular BI solution is right for them. I can just imagine the requirements spec for that solution: "15.1.182.f - Solution must be capable of creating 70,000 reports per hour. Alternately, solution will be able to generate 140,000,000 reports per year." 140 million reports! Incredible. (Now, what did I do with my mini-me?)

Seriously, here's the thing. More reports is rarely the answer. We already have plenty of data and plenty of reports. What buyers and users really want is fewer reports and more information that helps them get their jobs done better and faster.

We'd encourage business intelligence vendors to think of themselves more as data storytellers than data factories churning out generic report widgets…even if they can do it at incredibly high speeds. From this perspective, you wouldn't want to hear Steven Spielberg bragging about his ability to pump out a dozen movies a year or J.K. Rowling trumpeting her ability to write 1000 pages a year (hmm, wait a sec).

Here’s a little predictive analytics:

About a year ago, I took a swipe at the “$80 million supercomputer to analyze NYC student achievement.” It smelled more like a super sales job than a super useful analytical tool.

At the time I had said:

Teachers are underpaid, hardly appreciated, and overworked. I can only wonder what the half-life is of a system that asks teachers to log on to get information delivered by the “chief accountability officer.”

Well, it appears that things haven’t gone that smoothly with the supercomputer. Today, I received a link from Leonie Haimson, a NYC education advocate, to a story entitled SCHOOLS COMPUTER AN $80M ‘DISASTER’.

Not only has the supercomputer struggled to gain much traction with users (“The school system’s new $80 million computer super system to track student performance has been a super debacle, teachers and principals say”), it has coincided with severe budget cuts.

We see these data warehousing problems all the time with our clients, and the NYC supercomputer displays all the hallmarks:

• Delivery delays: Nearly six months after the Department of Education unveiled the “first of its kind” data-management system, the city’s 80,000 teachers have yet to log on because of glitches and delays.


• Bad user experience: Many principals have complained that it runs slowly, lacks vital information, and is often too frustrating to use.


• Complicated training and set-up: School officials were hoping to have everyone hooked up and trained within months… delays in creating IDs and passwords for teachers
• Trying to do too much, delivering too little: The principal added that she preferred to get student information from a combination of old data systems “rather than wait for ARIS to churn and churn and churn and maybe give me half the report I need.”
• Massive cost: Complaints about the expensive system—on which nearly $35 million has been spent so far—have gotten louder since the city unceremoniously chopped $100 million from individual school budgets last month.
• And yet, few success anecdotes to justify the investment: ARIS had already enabled her data team to analyze the performance trends of the school’s many English-language learners.

It does offer one thing that I haven’t seen before: a Chief Accountability Officer.

We don’t tend to agree with Microsoft when it comes to data analysis and presentations. In fact, we’ve even been critical of them for misrepresenting data, excessive visual “flair”, missed opportunities to improve Excel, forgetting their power users, subpar presentation tools, and wasteful slide masters.

With all these past differences, I was a little surprised to find that we do share some common ground. Check out the comments (from an article in Internet News) by Peter Klein, CFO for Microsoft’s Business Division in describing the world of business intelligence:

“I’ve talked to a lot of customers about business intelligence and the one thing that they tell me is it’s really hard to use,” said Peter Klein, during at the Credit Suisse conference.

“‘I’m not getting the value out of the investment that I made,’” Klein said customers had complained. “‘I have invested a lot in my back-end systems, and today 10 percent or less of my employees actually touch it, or get access to the data. I’ve got six different BI solutions across multiple different departments, none of which talk to each other. And they’re hard to use, so I’ve got to send people to training for two weeks to learn how to use it.

Finally, we are speaking the same language. Now, I’m curious to see what they are going to do about it.

There are two kinds of people in this world: those who put things into two categories and those who don’t. Maybe this isn’t the best representation of the complexities of the human race, but it does give me a cheap lead-in to compare two types of problem solutions: “high tech,” focused on tools, and “high touch,” focused on interpersonal communications.

I was reminded of these two approaches by a recent interesting article in Wired that expresses an opinion about why America’s performance in Iraq has been disappointing. The basic premise of this article is that America has entered into this engagement in a “technology networked” fashion, drowning it in technology; the more, the better.

The article suggests that the US forces would make more progress if they were to spend more time on a “socially networked” approach. For instance, instead of remote controlling a drone from 100 miles away, spend more time drinking chai with local leaders. Not the absence of technology, but the incorporation of technology into a socially based environment.

“If I know where the enemy is, I can kill it. My problem is I can’t connect with the local population.” This was a quote from one division commander. Change a couple of words and you end up with a statement that many of us would find all too familiar:

“If I know where the inefficiency is, I can fix it. My problem is I can’t connect with my data.”

Aren’t we witnessing this in spades right now in the BI space? There’s no lack of number of tools and number of features in these tools. The challenge is figuring out who the real insurgents are and how you deal with them. If you’ve been reading the Juice blog for very long, you have a pretty good feeling for how we approach what we believe is a social problem (high touch) and not a technical one (high tech).

The good news is that the US forces are changing their approach to socialize more with the Iraqi people—hopefully leading to a better Iraq. Is there good news for the BI space? We’d like to hear from you on how you’re making sure you focus enough on the social “high touch” aspects of our space. What’s your insurgent data? How can you get to know it better?

“The last mile” is a term that often is applied in the telecom industry in reference to “the final leg of delivering connectivity from a communications provider to a customer.” It is an expensive and complex step due to the challenge of pushing information from centralized, high capacity channels to many diverse end-points where information is ultimately used.

We think there is a “last mile” problem in business intelligence too. This critical bridge between data warehouses and communication of insights to decision-makers is often weak or missing. Your investments and meticulous efforts to create a central infrastructure can become worthless without effective delivery to end-users. “But how about my reporting interface?” you wonder. That’s a creaky and narrow bridge to rely on for the last mile of business intelligence.

Listening to our clients, we are confident the last mile is a real problem. The ultimate source of this failure is less clear. Here are a few of theories:

1. The engineers who built the data warehouse build the interface. No offense to the talented individuals who can push around, clean, normalize, and integrate data—but they may not be ideally suited to designing a user interface for non-technical users. A designer wouldn’t create charts that look like this (our favorite example of chart-based encryption):

In the worst case, developers are dismissive of user experience. I’ve met with IT folks who felt confident that providing a massive data table would provide a suitable solution for delivering information to users. “Hey, they’re getting their data. Is there a problem?”

2. Reporting is considered the fundamental mechanism for working with data. Here’s a framework we’ve started to consider in thinking through the multiple approaches for getting value from data:

• Reporting lets you monitor things that are well-understood and relatively predictable.
• Exporation or analysis helps you understand new processes and erratic and shifting behaviors.
• Presentation is about communicating insights and understanding, often building on both reporting and analysis.

Many people assume that a reporting tool is sufficient to do in-depth analysis and communicate results. That’s like trying to build a deck with a screwdriver.

3. Poor fundamentals in information display. Despite the efforts of folks like Edward Tufte and Stephen Few, general literacy in this area is still low. Shiny, 3D pie charts are still acceptable, even desirable in some places. Particularly disturbing is the persistence and pervasiveness of this problem in Excel where there still remains some confusion as to why this is bad information display:

You don’t have to go any further than the Dashboard Spy to find examples of the visual muck that is commonplace.