Why you really need a list of systems

By Andrew Clifford

Writing a single, definitive list of the IT systems within your organisation is a simple task that can deliver significant long term benefits.

There's a simple question I bet you can't answer: how many IT systems are there in your organisation, and what are they all called? And even if you can answer that, I bet I would get a different answer from everyone else.

You are not alone. I used to work in an organisation that came up with a different list every time we counted them. Sometimes we had 100 systems, sometimes 250.

I am sure you do have some lists of systems. But different groups will have different lists. The development group will have a list of projects; the operations group a list of overnight batches; source control a list of code areas; system administrators a list of servers; architects a logical application model; and the help desk and support teams other lists. I bet they are not all the same list.

This does matter. Name differences are a perennial cause of confusion. Business ownership of IT is impossible without a clear definition of what is being owned. Good design requires that systems are decoupled, but this is impossible without a consistent definition of systems boundaries.

Every business has records of its assets, such as property, vehicles and manufacturing facilities. We in IT constantly sell the value of information, and the need to have a single version of the truth. But most organisations don't have a single version of the truth for their IT systems. Is the IT less important than other business assets?

The primary purpose of the list is to help manage the IT, so use management characteristics to define the list. Draw system boundaries around things that force you to manage systems differently, such as different business areas, business processes, system vendors and technology stacks. It is more important that you define clear boundaries than exactly where they are drawn. You can always revise the list later.

Having drawn up a single list, use it everywhere. Where you have to use other lists (like system administrators and servers), cross-refer to the definitive list. The more you use a single list, the more useful it becomes.

A single list overcomes communication problems, clarifies ownership, and strengthens design. More significantly, presenting the IT as clearly defined systems shows that the IT is not just unmanageable technological mush that acts as the backdrop to projects or as a cost to IT services. You can present individual IT systems as business assets. Your systems can begin to compete with property, vehicles and manufacturing facilities for management attention.

We have a lot of long term problems in IT because we find it hard to justify proactive management, such as preventative maintenance and technology refreshes. But it is easier to justify preserving the value of an asset. When was the last time you needed a business case to have a company car serviced, or mend a leaking roof? Presenting your IT systems as business assets helps make the case for proactive management. And the first step to presenting you systems as business assets is to write a single, definitive list.

Subscription