Speedometers

I just discovered a new blog about business intelligence with an emphasis on charting and dashboarding. It's from a company called Juice Analytics. One of their recent posts is about the use of the speedometer chart widget in dashboards. They, like Stephen Few, are not a big fan of this method of presentation and give various good reasons as to why.

At first I was feeling a little guilty after reading the article, because even though I've read Few, I have still incorporated the speedometer into our dashboard software. It's great for demoing because it looks good, it's easily recognizable, and it helps support the whole dashboard analogy (you don't see many pie charts on your car dashboard). In fact, I added it at the request of one of our sales reps because for the longest time one of our presentations contained the following quote:

I want a supply-chain dashboard that looks like the dash in my 911 Carrera, with all of the dials set to my specific supply-chain metrics. And when any one goes out of tolerance, I want the dial to redline and let me drill into the specific issue.
Hans Peter Schaefer – The Gillette Company.

So should I argue about the car analogy with the CEO of a Fortune 500 company? The challenge is that we do have many situations where there is a key metric or score that needs to be tracked. That score can then be sliced and diced a number of different ways, but different users will want to drill down to different views. For example, one user may want to see the trend so a line graph or a spark line would be appropriate. Another user may want to compare the value across regions or departments. Or by product group or person or any number of categories. Some people will want a combination of those views. So while the speedometer does take up unnecessary space, hide trends, etc, how do you decide which alternate view to use?

The answer may simply be that speedometers are appropriate in one situation: demoing dashboard software. You're trying to illustrate concepts to people in different roles in a short period of time. For better or worse, people get the speedometer. A sales presentation is not the place to preach about the visual display of quantitative information or the effective visual communication of data. If you start with a single value and drill down to a few examples that are more effective displays, the audience will understand that there are options. When you get into the analysis phase, you can weed out the bad displays since you'll have access to the people that understand how the information will be used. Each user can have an initial display tailored to the actions they are likely to take based on the data.

So, I'm not killing the speedometer widget just yet. Maybe for some people, it really does provide the right level of detail. But I'll continue to approach it with a dose of skepticism and look for better ways to express information.

Laptops and Programming for Kids

This is off-topic but I wanted to mention a couple of things that I've run across recently.

The first is the $100 (closer to $200) laptop project's Give One Get One program. For a limited time you can pay about $400 to get a laptop for yourself or your child and another one will be donated to a child in a developing country. The laptops look pretty cool especially for young kids because they're designed for rugged use and minimal access to support.

I also ran across a kid's programming language called Scratch. It was developed at MIT and it's a way of programming that uses simple drag and drop instead of typing commands. I've tried to get my son interested in programming before, but his eyes just glazed over at even simple Ruby code. But he seems really interested in this. He plays a lot of free Flash games and Scratch theoretically will let him write his own. You can join a community where other kids share their programs. Hmm... maybe I'll look into using it for our dasboard SDK.

IBM Cognos Acquisition - The End of BI?

IBM is acuiring Cognos, which blows my theory that that Infor would do it. Infoworld's take on the deal is that BI is dead because the big BI tools will become part of the database offering (Oracle and DB2). I'm not so sure about that. Business intelligence has always been more about the intelligence than the tool. It's not really that difficult to pull data out of a relational database and display it in a table or graph. The tools definitely help organize things and can provide a layer of abstraction so the end-users don't have to see the ugliness of the database, but someone still has to do create that abstraction and that's where the value of BI lies.

Contrast the IBM/Cognos deal with the SAP purchase of Business Objects. SAP obviously has knowledge of their own data; now they have a tool to present that data in meaningful ways directly to the people that want it. Combining actual data with a BI tool is powerful. Combining a database with a BI tool still leaves a huge gap. The companies that use DB2 or Oracle will not be able to just turn on Cognos or Business Objects and get value - it will take the standard huge development effort just like it always has. And even though SAP has the better chance to deliver a turnkey BI solution, the complexity and customization of most SAP implementations means it's going to take a while.

I'm not claiming these deals aren't important or won't be successful - just that there's more to BI than a database engine and a reporting tool.

Pros and Cons of Real-time Dashboards

A lot of Business Intelligence applications boast about being "real-time". On the surface this sounds like a good thing, but in my experience there are trade-offs between real-time and batch processing for dashboard software.

For operational systems, real-time is a must in some cases. For example, managing labor requires you to know precisely what tasks have been completed and what are available. Alerts that are designed to notify you of a situation in time to take action to prevent it from escalating also may require real-time information. Using real-time data usually avoids an extra data store that has to be maintained, backed up, and monitored. The data is pulled directly from the transaction systems or pushed to a temporary cache within the dashboard application.

However, in many cases, it is actually better to use batched data. Transactional legacy applications are usually tuned for OLTP processing, whereas dashboards typically demand DSS queries. Many databases can't be tuned properly to handle both so there is either a performance hit on the dashboard side or on the legacy side. In a batched architecture, the developers can create their own data model that the dashboard uses, which allows the dashboard performance to be optimized without impacting the transactional systems.

With a separate data store, the developers can reuse the dashboard with no changes to go against different transactional applications. For example, in a project I've worked on we had to report against three different legacy applications all doing the same task. By abstracting the data out into our own data model, we were able to write one set of dashboard components that worked over all three systems. As new systems come online or we get new customers with different systems, we can implement the same dashboard quickly because all we have to do is write the loaders to populate our data model.

Additionally, transactional applications often have to purge old data to keep the database small and fast. Data batched for a dashboard can be kept around indefinitely to be used for historical reporting and trending.

When designing a dashboard, it's important to talk to the users to determine if they want real-time because it's a nice sounding buzzword, or if they really need it. Dashboards should be as real-time as they need to be and not more.

Virtual Dashboard Appliances?

I've recently been working with a customer to develop a prototype of a dashboard for monitoring the process of unloading trailers in a warehouse. It will report on metrics such as late appointments, average unload time, the number of pallets that need to be re-stacked due to damages, rotten wood, etc. We have a quick turnaround on the prototype so I've been thinking about the best way to get our application in the customer's hands with minimal training and IT time on their side.

In an unrelated project I've been using Microsoft Virtual PC to work on a client's network because a) they use the Cisco VPN and the client does incredibly nasty things to your computer (starting with two unprompted reboots during the install process; b) the Cisco VPN doesn't work on Vista so I need to run a Virtual XP to use it; and c) I want a guaranteed virus-free clean environment to connect to the customer's network and what better way than a clean install with only the minimum applications.

Putting the two together, I decided to hand over the prototype by just creating a virtual machine with everything pre-installed and configured. The client can load that machine up on any PC, give it as much memory as necessary, and demo with no new hardware or installations.

That got me to thinking - could that be a good model for doing installs of Dashboards in general? We could install the app server and database, backup software, admin tools, etc; pre-configure everything, and ship it to a customer to drop in and start using right away. It's like SaaS but the customer retains more control in that their data never has to go outside the firewall. The really cool part is if they have issues that need support, they can send the entire virtual machine back to us where we can install debugging tools, etc to find the problem.

I was feeling pretty proud of myself for thinking of that until I read this article talking about virtual applicances. It turns out to not be such an original idea. Still, it's an interesting concept and I'll be on the lookout for opportunities where it makes sense.