Low Dashboard Use in Enterprise

Aberdeen recently released another study about the role of key performance indicators in various organizations. As expected, the "best in class" organizations have a much higher overall use of KPIs. What's surprising is how few of the companies in the survey make use of dashboards, scorecards, analytics, and alerts. Even among best in class companies, the chart below shows that almost 40% do not use dashboards and even less use those other methods. Maybe I've been in the dashboard business so long that I'm biased, but those numbers seem low to me. Most companies must still be using ad hoc reports, spreadsheets, and whatever information they can pull from their transactional systems. Those tools will always have a place, but the efficiency, collaboration, consistency, and accuracy of dashboards seem to make them a no-brainer for KPI tracking. I guess there's a lot of room for improvement.

Enterprise Software Design

Robert Scoble started a big blogging war about the beauty, or lack thereof, in enterprise software. His follow-up post covers the initial post and responses fairly well so I won't rehash it here. But I will put in my two cents about how the discussion relates to dashboard software.

The software I write is definitely targeted towards the enterprise. Our biggest customers are Fortune 500 companies. What I find is that, in the dashboard space, you sometimes feel like you have to avoid writing software that's too sexy. Sure, the marketing and sales guys want pretty dashboards with lots of colors and speedometer gauges. But some customers almost act like if it looks good, it's just fluff and not functional.

Aside from that, you're warned so often by the visual design experts not to overdo the prettiness, that you almost become gun shy about your software looking too nice, even if you really are trying to make it functional.

So, you follow all the rules and try to keep your dashboard clean and uncluttered and avoid scrolling and all that. And then your customers come along and put everything into a table view and put 50 gauges on the same page because they prefer vertical scrolling to clicking. And they're happy.

So I guess the only moral I take away from all this is to try my best to make software that's both highly functional and decent looking. Either option sounds pretty good.

Dashboard in the Cloud?

Software as a service (SaaS) or running applications "in the cloud" is all the rage these days. I've been thinking about the applicability of that model to dashboard software. To be clear, I'm talking about an application that is hosted by someone other than the company that is using it, not just subscription-based licensing, which is a different issue.

The advantages of SaaS for dashboard software for the user are not much different than for other applications: lower IT costs, less up-front cost, easy (theoretically) upgrades, potentially better security and scalability.

However, there is a big difference between a typical dashboard application and something like a CRM system: the data. In a dashboard app, the data typically comes from many other systems. Whether it's real-time or batched the data has to get from inside the firewall to outside the firewall where the dashboard lives. That opens up a big can of worms in terms of security and performance.

On the performance side, a dashboard that pulls data from a relational database would now be going over the net which is going to increase the latency of the queries. Depending on how those queries are designed and the speed of the link, this could be a huge performance hit. The same thing would apply to a dashboard that pulled data off of a message bus. There would be less of an issue if a "push" model was used where some process that lives inside the firewall sends data to the dashboard app. But now we've moved some functionality inside the firewall and back into the hands of IT which decreases the benefit of the SaaS model.

Also, the data seen on the dashboard is now going over the public internet and is likely stored in a database living at the hosting provider. This is a security risk that will have to be carefully managed, but it's not an unsolvable problem. The data can easily be sent encrypted and the dashboard itself can support https so the data can't be intercepted on the way back to the end-user's browser. The database issue is mainly a matter of the trust you have in the hosting provider so the application vendor better do their homework when selecting one.

Microsoft has published a good primer on these kinds of issues and SaaS in general. It's not specific to Microsoft technologies and the first parts are not too technical.

Despite the issues, I believe SaaS does have potential for dashboard software. In cases where collaboration among multiple companies is a requirement, such as CPFR, many of these same issues would have to be addressed anyway. In those situations, the chances are good that a hosted solution would be forced to solve the problems in a better way than a traditional install. So I can