A glimpse of salvation

By Andrew Clifford

We can break free from the major management problems of IT by designing systems differently.

On our heretical journey we have seen that the major management problems in IT can be traced back to designs that we have historically used to provide workable and cost-effective solutions. We have seen that our current IT management approaches do not fix the underlying problems. They help us cope with complexity and misalignment, but by so doing they unwittingly dig us further in.

To break free from this, we have to go further than trying to cope with complexity and misalignment. We need to fix the underlying problem by using advances in technology to design simpler systems.

• In the past, servers were expensive to buy and complicated to administer. It made sense to buy large servers and share them across multiple business applications. Now commodity hardware and virtualisation make it cheap and easy to provide one server per application.
• System software like databases and transaction processing monitors used to be expensive and difficult to administer. It made sense to have large, shared instances. There are now excellent open source alternatives that can be installed on multiple machines for free, and installation and configuration has improved significantly. Running one application per server makes administration much simpler. It is now easy to move to a model in which system software is just part of the application that uses it.
• In the past, the only real-time integration methods were shared files and shared databases. Multiple business applications were built around shared data so that they could integrate. Modern integration methods, based on internet protocols, messaging and XML, make it easier to get independent systems to work together without sharing each other's data structures.

These advances let us design systems which encapsulate their technology stack, rather than having each layer in the stack as an external, independent, shared layer. This makes IT much simpler. IT becomes a set of independent systems, not a sea of components implemented across shared layers.

This "system orientation" is only part of the story. We also need to make systems more aligned and understandable to the broader business. We need to make sure that each system is clearly owned. The capabilities of the system to store, process and communicate information should lie within their owner's business responsibility. Interfaces should be authoritative flows of meaning and responsibility, not just an implementation detail gluing two components together. We could call this "responsibility orientation".

This sort of change has happened before, when we moved from assemblers to third generation languages, indexed file systems to relational databases, and from procedural coding to object orientation. In each of these transitions we accepted some loss of technical efficiency for a gain in human efficiency through better understanding. We need to do the same for system architecture.

System orientation and responsibility orientation provide focus to help us run smaller, more effective projects. They provide clarity and allow independent change which helps manage "legacy" situations. They remove complicated technical structures and reduce the demand for scarce skills. But these are the tip of the iceberg. Next week I will cover the full impacts of these changes, which go much further than system design.

Subscription