Systemhood's challenging future

By Andrew Clifford

Systemhood could challenge project management and service delivery as the basis for managing IT.

In the last two newsletters I have presented the idea of systemhood. Systemhood involves asserting the definition of systems strongly, and using systems as the basis for management. The opposite of systemhood is to think of IT as a complex of technology, IT organisation, IT projects, IT processes, business change and business usage.

Systemhood makes IT easier to understand, and helps us see which bits of IT add value. It helps us control IT, for example by reducing the scope of IT projects that have impossible objectives. It helps us make the case for proactive management of existing IT systems, which reduces long-term costs. Systemhood helps cut out unnecessary demand for IT, and reduce the IT work required to deliver business value.

Systemhood has many potential benefits, but is it realistic and is it desirable?

The main argument against systemhood is that a lot of IT is not structured as separate systems. It is built as layers of technical infrastructure that are shared by many business applications.

I worked for many years as a systems integration specialist. When you integrate systems, it is really important to preserve the autonomy of systems. Autonomy allows IT to evolve in a controlled manner, without hugely disruptive wholesale change. Shared infrastructure layers have their roots in a more technologically constrained past, and are the enemy of autonomy. Although I know some would disagree, I would argue that architectures that are not based on strongly autonomous separate systems are simply weak architectures.

Another argument against systemhood is that it is not flexible, and that it places too much emphasis on internal IT structures, not business. Component-based IT that runs on shared infrastructure is more flexible and a better basis for modern flexible business.

Using IT to enforce business flexibility is a misapplication of IT. Inefficiencies in business operations can not be overcome by implementing less constrained IT. IT can support the richer information flows required for flexible business, but only after business had adopted that change. Modern integration methods mean that even fully autonomous systems can be used in very flexible ways.

Structuring IT as systems is not inward looking. It makes IT understandable and meaningful to a non-technical audience. It encourages strong ownership. Presenting IT as infrastructure layers, IT projects and service delivery processes is much more inward looking.

Although there are arguments against systemhood, there are sound counterarguments in favour.

This brings me to the future of Minimal IT. I want to explore just how far systemhood can be taken. The main "product" from systemhood has been system governance. I have written a lot about system governance as a decision making tool for compliance, cost reduction and infrastructure investment. This has not been contentious because there are relatively few competing ideas in these areas. But now I want to explore whether system governance could be developed into a more assertive framework for managing the business value of IT and for structuring IT work. This is more contentious because these ideas compete with established project management and service delivery processes.

Will systemhood stretch this far? I am not sure. But it is definitely worth exploring further.

Subscription