The barriers to effective systems management

By Andrew Clifford

Many persistent IT problems relate to the qualities of the systems themselves. Tackling these is not a technical problem, but a management problem of communication, justification, control and accountability.

Last week I suggested that many problems in IT relate to the systems themselves, not just how we run projects. This week, I want to expand on this idea and see what barriers there are to overcoming these problems.

Here are some examples of problems that we find very hard to fix.

• Through time, systems become ill structured, and increasingly difficult to work with. Eventually we hardly dare modify systems because of their instability.
• Many systems run on old technology that is no longer supported.
• We have concerns about areas of risk. Systems ought to be more secure. We are not confident that we could restore systems after a disaster.
• Few systems have effective documentation, or effective test plans.
• Systems have become so interconnected that every system change has knock-on effects on other systems.

These problems all relate to the systems themselves, what I call "system qualities". They are not primarily about how we run change projects. They are about how we manage systems in the long term.

Why do we find these sorts of problems so hard to fix?

It is not a technical issue. We understand these problems technically. We know how to restructure code and how to upgrade technology. We know how to make things secure. We know how to write, how to test, and how to integrate.

It is not a lack of importance. These problems are a constant drain on IT resources, and impose significant constraints on our ability to meet business needs.

It is not because we do not care. We work late to fix problems, but it ends up as a disjointed, best-efforts approach. We can never finish the job.

We find this hard because we can not justify the time and effort. These problems always have to come after the day-to-day support of the business service, and after projects to support business change.

If we want to fix these problems we need a better way of communicating the value of system qualities, and the risks that business runs by not addressing the problems. This would allow the broader business to understand that some of these problems are so important that they too deserve management attention, time and money.

But businesses will not spend money unless they can see some return. The IT function has to be accountable. It has to provide a way of showing that money is being well spent, and measuring that these problems are being fixed.

I think that what looks like a series of unrelated technical problems reflects the same underlying management problem. We do not have an effective method for communicating the value of system qualities, for justifying the work, for giving the broader business control, or for making the IT function accountable.

We can only solve the technical problems if we solve this management problem.

Next week I will show how this management problem has been solved in other areas of IT, and begin to think about how we can do the same for the qualities of the systems themselves.

Subscription