Effective dashboard design. Few and far between.

Everyone has a dashboard don't they? IT service management and monitoring tools all have them. As long as there's a web interface you can customise with traffic lights and gauges then it counts as a dashboard doesn't it? Well no, certainly not according to Stephen Few, the author of beautiful reference books on the art and science of data visualisation.

Few is an evangelist for giving data meaning through visual communication and I'm a recent disciple. In his book 'Information Dashboard Design', he defines a dashboard as the:

'Visual display of the most important information needed to achieve one or more objectives which fits entirely on a single computer screen so it can be monitored at a glance'.

That'll do nicely Stephen.

He critiques examples of dashboards which, whilst you're still uninitiated, don't look too bad. By the time you reach the end of the book you realise that they were truly awful. Poor choice of colours, inappropriate visualisations and non-data pixels are the most common faults. Logos, pie charts and gauges in particular get some stick. Some of BI tool vendors - Business Objects, Oracle, Hyperion, Cognos - are culpable but the greater culprits are the analysts using them to create these monsters.

As well as explaining preattentive processing and the Gestalt principles of visual perception, Few describes the display media which are most useful for dashboards. Summarisation and exception are two key design characteristics; summaries create an aggregate perspective which prompts further questions whilst exceptions, and implicitly the underlying thresholds, draw attention to variations from normals and targets. Customising a dashboard for the audience, their objectives and how they will act on the information is also crucial in deciding on the content. This is where KPI design and visualisation design converge.

I'm often involved in extracting and visualising management information from IT monitoring and service desk tools. These could be the tools which sit there polling or logging day in, day out, but often relegated to an operational notification function. Yes, you can produce traffic lights, charts for WAN or CPU usage and filter huge lists of events but how are you going to use this, er, noise to report the value of the IT service provided to your customers? IT service desks may be better at providing reporting features but suffer from the visual bloat which gets in the way of effective, efficient communication.

Instead of wrestling with the native visualisations that IT management tools provide sometimes it can be useful to re-evaluate what's really important about the information being communicated and work harder on those 'critical few' KPIs and how best to visualise them in a way which helps the audience make better decisions.

I apply Few's techniques everywhere I can. They sit squarely at the intersection of my professional passion for analysing IT performance and a personal interest in aesthetics and creative design.

I highly recommend Few's books if you're working in this area and his website has lots of useful resources. His closing remarks inspire us to design a dashboard which: "makes people's lives better, helps them to work smarter, or gives them what they need to succeed in something that is important to them". As a purpose, there can't be many more worthwhile.

Utilisation. Too busy to manage it?

Utilisation (or utilization if you prefer); In spite of being one of the most widely used terms to describe the performance of IT systems, it often the most misunderstood.  This post examines why this could have real business performance and cost implications.

Utilisation is a common measure of how much of a resource is, or was, being consumed. For storage resources such as physical disks & memory, this is an absolute measure of the available capacity in use eg. 500 Gigabyte of data consumes 50% of a 1 Terabyte disk. This is as intuitive and easy to understand as the glass of water analogy; half full or half empty depending on your outlook.

Misunderstandings can arise though when utilisation is a measure how much of the time a resource was busy. WAN links, CPUs or disk controllers are all resources which, whilst busy processing something, are 100% utilised. Only as the measurement interval increases does the utilisation become less than 100%. A CPU which is 100% busy for 30 seconds and then idle for 30 seconds will be reported as 50% utilised over a 1 minute sampling period.

This might suggest that a time-based utilisation measure is inherently flawed and inaccurate because values reported by monitoring tools are always averaged, even the so-called peaks. In fact this average measure gives rise to something useful because requests which can’t be serviced whilst a resource is busy must wait in a queue for an average time which is determined the average utilisation.

The higher the utilisation of a resource, the higher the probability of encountering queuing and the longer the queues become. Requests are delayed in the queue for the combined service times of the preceding queued requests. So in a system where the throughput of individual components is known, the highest delays – bottlenecks in other words - are encountered wherever the utilisation and service time are highest. Average utilisation then becomes a measure ‘by proxy’ of the queuing delay at each component.

Every part of an application’s response time is bounded by network, CPU & controller queuing delays as well as the actual processing time.  Poor response times mean a poor user experience and reduced productivity. So the time-based utilisation of the end-to-end system resources becomes a critical KPI for managing business performance, IT value perception and capacity costs.

In a converged and virtualised world, there is continual contention for resources so ‘Quality of Service’ scheduling mechanisms which provide queuing control at each bottleneck become a necessary capability. These techniques allow cost efficiency to be maximised, driving resource utilisation as high as possible whilst protecting response times for priority services.

The good news is that utilisation is relatively easy to measure, more so than queuing delays. The real challenge is to collect and present this in a coherent way and translate it into KPIs which reflect real performance impacts. Fail to understand, measure and control utilisation however, and IT could be failing the business.