Size doesn’t necessarily matter, but what does?
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:
- Firstly we need to understand (and document) the business architecture, which will show how the various processes of the business fit together, how value is created, and what the consequences will be for the business of a process failure.
- Secondly, we need to understand (and document) which processes are supported by which applications, as well as understanding whether there are any manual work-arounds, and the immediate business consequences of system failure.
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?
- Processes that are practically impossible to carry out without the use of an application, (which would otherwise require cumbersome manual work-arounds) should be treated quite differently from those that are merely facilitated by the use of an application (compare checking into a flight compared with reviewing some sales statistics). For example, questions of user uptake are far more relevant for applications whose use is discretionary. Applications which have to be used to effect a business transaction can be designed more from a performance perspective, than a user comfort perspective;
- Some processes may be carried out by a small number of people (and supporting applications will therefore be used by a small number of people); it doesn’t follow that the processes (or applications) are of secondary importance just because of that. A company with low margins but lots of cash flow may depend on sophisticated treasury systems used by very few people;
- A “process organisation” is one where key processes are managed end to end, not in silos. The same should apply to the technology support provided to the applications and other technology to support the processes. We have seen many examples where processes are not managed end to end, but are fragmented, leading to messy interfaces, unclean hand-overs, and significant quality and performance problems. This situation will be made worse if IT support and architectures are aligned to these silos.
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).