Think back for a moment. When was the first time you heard the term ‘dashboard’ applied to any device, commodity, product, service or thing outside of the automotive space?
For software engineers focused on the Business Intelligence (BI) space in pre-millennial times, it might have been an application interface leveraging a part of Microsoft Excel to provide some higher-level abstraction. For the average business layperson, it might be after the advent of BusinessObjects in the 1990s, or perhaps even somewhere probably closer to the company’s absorption into SAP in 2007.
Dashboards will always play a role in analytics, but just how long should any particular dashboard stick around? At scale, the production and management of dashboards can be very costly, and significantly inefficient, often leading to poor decision-making and bad outcomes. The real key to success is understanding the power of currency: Which tables are most used, and why?
Information economy inside track
InsideAnalysis Eric Kavanagh and co-host Lynn Moore of DigitalHive recently staged an analytical discussion to find out where the speedometer really sits in relation to dashboards today. Speakers included Peter Kapur of Waste Management, Brien McHale of Deloitte and Chirag Padalia of Blue Cross and Blue Shield.
The group centered their discussion around an interesting question: what is the half-life of an IT dashboard? That is, with half-life here (obviously, hopefully) relating to the measure of time it takes for a radioactive isotope to lose half its radioactivity… or indeed for any substance or product to lose half its value.
A dashboard’s half-life is determined by how useful it is, how directly it integrates with current technologies (let’s not forget, platform evolution can render a dashboard redundant or obsolete) and how much users actually use it. Over their recent history, (and we mean the last two decades) dashboards have become increasingly popularized because organizations wanted to go faster.
But, as their use expands and mushrooms, we don’t want users to end up searching through multiple dashboards to find what they need, so we do need to try and engineer-in some kind of grading system in order to assess functionality and usefulness. In other words, we need to look at dashboards in relation to business outcomes.
Democratization of data fallout factor
It’s important for us to realize that as part of the democratization of data – where every user in every team and in every department and in every company division gets their own data dashboard – there is also a risk and fallout factor. Dashboards may be relatively ubiquitous, but they are neither omnipotent or ever-lasting. They may need to be re-factored or fully retired as a result of any number of reasons, with changes in governance and compliance legislation often being a prime ratioanle.
There’s an old Russian proverb that says, there is nothing more permanent than a temporary solution – dashboards are often brought into being with the intention of making them permanent, but only using temporary technologies. Hence, another risk and fallout factor is here highlighted.
The problem, so often… in the real world, is that organizations operate with comparatively mission-critical data dashboards, yet they fail to create and structure (and indeed implement) any kind of formalized dashboard decommissioning strategy – and failure to do so is less than safe.
The data lifecycle
We can perhaps gain some insight into dashboard half-life if we look at the constituent parts that make up this technology and, crucially, we should also look at the fuel-base that they run on – data We now recognize with greater clarity how data itself exists within a data lifecycle – some data is older, historical and belongs to legacy systems, but a lot of data is new, fresh, real-time and travels at the speed of light.
Old data in a new dashboard is okay, for historical tracking purposes. But industries differ in terms of how long they need to keep data (the insurance industry, for example, is more heavily regulated than most) and so we need to think about how long data actually needs to be around.
If an organization or industry body is not required to keep data, then hanging onto it could pose some kind of risk. Knowing what’s in your dashboard can help a business determine what the half-life of the dashboard itself is and how long it needs to be around.
But whichever way you cut it, building dashboards is tough in the first place. There are so many questions to ask. Very often the data science and developer team will be tasked with getting data sets from 10 different sources and manually stitching together visualizations or the presentation layer and trying to form some higher-level end product. Getting all that right and then enabling a growth process for scale is just never ever simple.
Back in the day, we might have had five people run macros on an Excel file to update the organization’s analytics. Now, today, we have the advantage of automated autonomous updates, which might be hooked up to an Azure instance, or dovetail in calls from SQL database commands and so much more at the backend. That’s great, but for every automation, we need to understand its provenance and progeny if we are going to control dashboard half-life productively.
Slippin’ into silos
Data dashboard lifecycles are also determined by a factor of the cleanliness of the data environment over which they sit and preside. If an organization suffers from chronic data silos, then it is consolidating a dashboard-based view of that information estate is likely to be fuzzy, out of focus or at best myopic.
Where we probably need to get to (spoiler alert, it’s not probably, it’s definitely, we’re just being polite) is a point where we assess the quantitative value of dashboards going forward. That way, we can focus on the ones that really matter and make sure that the company’s staff base is only focusing on the ones that make a difference, that are relevant, that are up to date, that are current and that are generating value.
But the question becomes, how do we that? Do you have to assign certain people to this role or does it happen via some more organic means?
It’s tough to say, but at least we’re having the discussion. Determining specific ownership (whether that be related to one individual, or a whole group) could be a very prudent and sensible first step. When we can more clearly define data dashboard ownership, then we can be more certain about who is doing what (and when) in terms of decision-making.
Understanding dashboards
In real world operational practice, understanding what dashboards do can be surprisingly tough. This thread was an interesting part of the speaker’s discussion in this session. The suggestion here is that, for example, when the US Congress (or any other international parliamentary body) lays down a new law, they should also lay down an opening paragraph or two that sets out in layperson’s terms what the bill or statute is trying to accomplish.
It’s an approach that could work for dashboards, especially when original developers leave an organization for pastures new.
In actuality, many organizations already take an approach that mirrors this suggestion and create landing pages and/or glossaries for their dashboards. That’s not to say the dashboard universe is perfect and there should certainly be some additional upfront governance out there to guide users across these technologies, but the impetus and willingness to do better is there.
If we can gain some of these controls over dashboard usage, then we can determine half-life margins more accurately and lay down sunset policy provisions and stipulations to determine how long any given information source should be channelled through a business.
Who moved my dashboard cheese?
It’s important that we think about the health, wealth and risk of stealth in data-driven dashboards at all levels. A key part of that thought process is determining dashboard half-life in order to maintain control over lifespan and usefulness.
As we half-life the half-life and move towards dashboard retirement, we will also have a responsibility to educate and inform users on the status of any given dashboard. Nobody wants a who moved my cheese scenario to develop, which in this case could come down to who moved my dashboard functionality.
Data-centric data-driven dashboard half-life is still very much subject to a process of nuclear fission, anyone for a slice of melted Cheddar?
Bloor Group CEO and InsideAnalysis Host Eric Kavanagh summed it up this way: “Every organization must deal with the ongoing entropy of technical debt, and this reality extends into the realm of dashboards. DigitalHive found a way to solve many of these problems elegantly, thus helping BI teams stay on track with their primary goals of fostering meaningul insights, and helping organizations stay on track.”
About Adrian Bridgwater
Adrian Bridgwater is a freelance journalist and corporate content creation specialist focusing on cross platform software application development as well as all related aspects software engineering, project management and technology as a whole. Adrian is a regular writer and blogger with Computer Weekly and others covering the application development landscape to detail the movers, shakers and start-ups that make the industry the vibrant place that it is. His journalistic creed is to bring forward-thinking, impartial, technology editorial to a professional (and hobbyist) software audience around the world. His mission is to objectively inform, educate and challenge - and through this champion better coding capabilities and ultimately better software engineering.