14 October 2008

System-oriented architecture (SYSOA)

By Andrew Clifford

Should we design IT so that every system is entirely independent of every other system?

I often write about the idea of thinking of IT as just a set of systems. (See Systems orientation: understand your IT and Systemhood.) The general idea is that we currently think of IT as a complex of processes, organisational structure and technology, but that we can simplify this by superimposing a view that divides IT into a set of notionally independent systems.

This system view has many benefits. It makes IT much easier to understand, especially to a non-technical audience. It provides a unifying principle that lets us bring together a lot of technology management under a single umbrella. It is the basis for easy and powerful IT improvement techniques like system quality management.

Mostly, I think of a system view as just that - a view superimposed on the reality of IT to give an effective handle for management. The real, physical stuff of IT - servers, networks, software, databases, support groups - is not really separated out so cleanly. But for the next few weeks, I want to explore what would happen if we did clearly separate each system through the entire IT stack. To give it a name, we could call this approach system-oriented architecture, or SYSOA (not to be confused with a service-oriented architecture, SOA).

In IT we are often apologetic about having independent systems within our architecture. The fashionable view is that independent systems should be broken down into a sea of reusable services. I want to explore the opposite direction, and consider what would happen if we used independent systems as the basic building block of the whole architecture.

I want to start next week by suggesting some principles for SYSOA. What is a system, and what isn't a system? How do we classify things like email services and PCs? What design rules do we need to ensure that systems are truly independent?

I then want to consider the application of SYSOA in four areas, which are architecturally the most challenging:

Lastly, I want to see whether this is a practical and valuable approach, and how we could take the first steps on this journey.

This is an exploration of an idea. This is not necessarily the right thing to do, but by considering it we can learn a lot about architecture and IT management. But I wouldn't completely dismiss the idea, either. Despite being unfashionable, I want to show that there is a lot of common-sense in a system-oriented architecture, and that, perhaps, it is something that we should take very seriously.