Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
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:

  • Data management. Shared databases can be a valuable corporate assets, and yet they seriously undermine the separation of systems.
  • Integration. Although strong system boundaries are critical to system integration, advanced middleware takes functionality out of systems and appears to break system boundary rules.
  • User interfaces. Browsers and client/server systems are hard to classify.
  • Infrastructure. To be cost-effective, infrastructure has to be shared between multiple systems, which undermines their separation.

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.

Next: System-oriented architecture principles


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more