We've argued before that thinking of IT as a business within a business is a helpful (if simplified) analogy. In Part 1 of this series - dealing with costs - we argued that no successful business can avoid understanding its costs and cost structures for long, and proposed that they be represented in a matrix of resources and activities. In Part 2 we further argued that knowing the costs without understanding the value doesn't get us very far, and as a first step to understanding value we looked at application quality, distinguishing between Functional and Technical Quality.
Useful as it is to understand these elements, they do not, on their own, determine the application portfolio strategy because quality, as we have so far defined it, does not address how well the applications contribute to business success. A rich IS chart of accounts would need the "demand side" (the business) to be segmented in some way, so that priorities might be made. Evidently, not all parts of a business require the same investment or support, and one size most emphatically does not fit all. But what's a reasonable way of thinking about this segmentation? In this note we talk about using process and application mapping to aid segmentation and prioritisation;
An applications portfolio strategy has to balance a number of different elements. Functional Quality is a measure of how well an application is perceived (by a user) to provide the desired functionality. On its own, this assumes that all users of an application have the same needs, and that their opinions are equally important. It also may not highlight questions of resilience, or of the need for integration with other applications, so although this is a good place to start, it doesn't get us to where we need to be.
Furthermore, just knowing the functional quality of an application doesn't tell you how important the application is - how it contributes to any process it supports or how important that process is. There can be no general assumption that any application with a low functional quality (or indeed Technical Quality) as we defined it last time should be improved. We clearly need to extend the notion of quality to include the degree to which an application "adds value" to the business processes they support and how important the processes are to the business, in order to determine our strategy.
In order to determine this we need at least two things:
These are non-trivial tasks, but having them hugely assists the development of a rational applications portfolio strategy. At a minimum such a strategy will lay out where money should be spent on new functionality, increased resilience, faster networks, better IS support, or indeed saved by spending it on something that has nothing to do with IT at all. Deciding which processes are "more important" is clearly not something which the CIO can determine without appropriate business involvement, and it may seem that the question is too broad to admit of an easy answer. It is true that there may be no simple answer, and that it may evolve over time; it is also true that every area of the business will have to be supported to some minimum standard. However, attempting to answer the question of process priority contributes enormously to agreeing investment trade-offs, which are in any event unavoidable.
Looking at technology through the lens of a process architecture requires a number of distinctions to be made: What price end to end management and support?
Without the business architecture and applications mapping it will be hard to predict the consequences of systems failure. This may mean that incidents are assigned inappropriate severity levels when they occur, and levels of required resilience not correctly determined.
An applications strategy must not degenerate into a question whether it's better to beef up application Technical Quality (because the system is a kluge) or drown it in new functionality (because the customer is king). Unless applications are mapped to processes which are themselves evaluated according to contribution to business value, investment will be a very hit or miss affair. The analysis will show where value might be created; the strategy will lay out where the value needs to be created (cost reduction, process acceleration, improvement of quality, customer satisfaction etc).
Next time we'll look at enriching the IS Charts of Accounts further by incorporating levels of performance.