Last time we talked about needing an IT equivalent of a chart of accounts – and suggested that you needed a matrix to represent the cost of resources by activity (and vice versa) if you were serious about understanding what costs money. There is much more we could say about the cost structures – what drives cost and how they operate – which become essential when you are contemplating change (new development, retiring applications, re-platforming services, or outsourcing).
However, before that happens you need to understand and demonstrate how well your services meet the needs of the business. We’ve argued before that thinking of IT as a business within a business is a very helpful (if simplified) analogy; the basis of every successful business is understanding how well it is delivering its services to its customers. How can you start to do that?
We said last time that CIOs often lack the easily understood language to talk about their business with the business. They need to understand what the real demand is for their services, and how well the services they do provide (including applications) are meeting business needs. This isn’t just about asking what “users want” – there needs to be some granularity to these questions, which can be mapped in a sensible way to business value. We said last time that an IT Chart of Accounts would include scorecards of things worth measuring and improving and which (internal) customers can find relevant. Today we want to concentrate on Applications.
There are many ways of categorising applications, dependent on our interests. If we’re assessing the condition of the applications portfolio, we should make a very clear distinction between functional and technical quality. There are indeed other things we need to know about the applications that we have “brought to market” – for example how many people use them, which processes they support, what it costs to run and maintain them, how old they are, and perhaps whether we consider them to be ”strategic” – but for now, we need to concentrate on the notion of application quality.
Functional quality is the degree to which an application provides the people who use it with a tool which matches their needs. It is therefore a relative measure; you can’t tell anything about the functional quality of an application by inspecting it alone, you have to look at how well it fits its purpose. The difference between what they get and what they need is the measure of bad quality.
Technical Quality on the other hand is a matter of how well the application has been written, and how easily it can be managed and maintained. In this sense it is an absolute measure, and you don’t need to know what it is used for to judge its technical quality. Measures of technical quality (as indeed benchmarks and targets) will change as technology changes.
It is evident that if we have been able to measure, or at least estimate, the technical and functional quality of our applications portfolio, that we can represent them on a matrix, because these two measures of quality are independent of each other. A badly written cheap and cheerful kluge might suit what it is used for perfectly; A beautifully architected fully resilient application with no data quality problems can sit there unused and unloved by the business. The question is to determine whether the quality of our applications needs improving, and in which regard. This however, cannot really be answered unless we have some of the other information we just talked about (including cost).
It is hard to manage what isn’t measured, and if you have no effective way of measuring the functional and technical quality of the applications, you will be running blind when it comes to managing the portfolio; either you will be tempted to improve technical quality for potentially spurious reasons, or to pile on functionality believing that that is what the business needs. As we argued with the cost example, not having a clear structure to represent the quality of the applications portfolio may mean simply associating lists of applications with technologies, age, and staff responsibilities.
Such lists do not in general provide a basis for the CIO or his customers to make rational economic decisions. Moreover, not understanding the elements of quality mean that “application improvement programmes” may be very hit and miss. Perhaps what is needed is user training, or on-line documentation, not functionality. Even needed functionality might relate to a set of applications (e.g., single sign on) rather than single applications.
The chart of accounts that incorporates quality has to support application portfolio decisions. Cost is not value, and knowing one without the other isn’t helpful. A CIO who knows the cost of everything but the value of nothing (in Oscar Wilde’s phrase) is of course an ineffective and unappreciated CIO.
CIOs and their customers may value their applications and the services, but they cannot know whether they are worth what they are costing if the true cost is not understood. Managing an applications portfolio is hard enough, but not knowing - specifically – how the costs are generated is hugely disabling when it comes to helping the business make decisions.
Although gathering quality metrics and keeping them up to date, may look like a non-value adding overhead, it is essential to being able to run the Business of IT simply because it provides true insight into what you have provided, and how that may need to change in the future.