Dashboard Software: Drag and Drop Versus Coding

There seem to be two schools of thought when it comes to dashboard software and how the dashboards are created by the end user. What I'll call the Cognos philosophy seems to be by far the more prominent. The goal of that philosophy is to let the very final end user create their own dashboard. Pre-built catalogs, drag and drop, wizards, etc are used extensively so the user never has to interact with the data source directly. The other school of thought says that the job of building the dashboard is best left to a developer. The mechanism can range from simple SQL to scripting languages to full blown programming via APIs. I'm sure people had built software using that style long before I entered the scene, but I'll still egotistically call that the Blue Sky philosophy.

Clearly, I'm in the second camp. In my experience, there's a direct correlation between how useful a dashboard is and how difficult it is to build. Easy things are easy, hard things are hard. When we built our product, we decided right from the start that we would design the app to make it as easy as possible to program a new dashboard report (we call them Instruments). There are only so many things you can do with drag and drop or even pure SQL (I'm sure there are SQL gurus out there that would disagree, but I'm talking about expertise that is likely to be found within a company's IT department). In a program you can do all sorts of things to optimize the performance and it makes it very easy to aggregate data from multiple heterogeneous sources.

We chose Java as the programming language because it is probably the most popular language on the planet (for now), so it's like that any customer will have Java programmers on hand. Plus, Java has the third-party library support to talk to just about any type of data source, be it relational database, mainframe, flat file, web service, whatever. I know tools like Cognos do have scripting languages, but it seems like the goal is stay out of that level if at all possible. With the Blue Sky philosophy, we ask people to admit up front that it's going to require coding and we optimize for that situation.

Don't get me wrong - there are a lot of cool things you can do with drag and drop and ad hoc SQL queries and those kinds of interfaces definitely have a place, but for hard-core, real-time metrics, alerts, and exception management, coding is the way to go.