Minimal IT - System-oriented architecture principles

21 October 2008

System-oriented architecture principles

If we want our IT to consist only of strictly independent systems, what would our design principles be?

Last week I introduced the idea of a system-oriented architecture (SYSOA), in which the basic unit of IT is a strictly independent system.

To consider this further, we need some definitions and some principles.

First, definitions. IT is made up of three types of entity: systems, appliances and network.

A system is a purposeful and independent collection of application software, the system software and hardware on which it runs, and all the support services required for its operation.
An appliance is a generic hardware and software capability that may provide a service to a system or systems, but which is not otherwise purposeful.
The network is the means of communication between systems.

The principles for systems are:

Every system has a defined purpose, usage and owner.
Every system is independent from all others. It can run independently from all others (though it may not be able to do useful work). It does not share data or runtime components with any others. It does not assume the state of data in any others.
Every system is an instance of a system definition. Many system definitions have only one instance but, for example, a branch-based system is likely to be an instance of a common definition.
There are no special relationships between systems. There is no special relationship between client and server systems, between instances of the same system definition, or between systems that co-operate to support a meaningful business activity. Systems can not be broken down into systems, and systems are not assembled from systems.
Systems only communicate with each other through pairs of defined request-response messages.
Every system has a physical existence. It is located somewhere, and it is clear where this system ends and the next system starts.
Technical functionality can be defined as a system provided that it is a purposeful and independent piece of functionality.

Not all IT can be broken down into meaningful systems. The appliance category covers IT that needs to be managed as hardware or software outside of the definition of a system, such as a storage array or a PC. Appliances of the same type are interchangeable.

The distinction between an appliance and a component of a system is subjective, and reflects its usage and how it is managed. If it supports only one system and is managed as part of that system, then it is a component of the system. If it supports many systems, or it is managed as a generic capability, then it is an appliance.

Although these principles may seem simple, they challenge commonly held views of IT. They do not support the view of IT as a library of reusable components, or the idea of IT as layered architecture. However, I think that these principles could achieve the same aims, but in a simpler and better-controlled way. Next week, I will cover how data management would need to change to conform to a system-oriented architecture.