System-oriented architecture is valuable because it provides a common point of reference between business owners, users, IT management and technical specialists.
Presenting IT as separate systems provides a simple management view that makes it easier to communicate IT, easier to spot problems, and easier to justify improvements. In practice, though, IT isn't that simple. IT is often built of layers of intermixed applications and technologies, and the skills of many different specialists.
I have been considering what would happen if we turned this simple management view of IT as separate systems into reality, by using systems, rather than layers and technologies, as the physical building blocks of IT.
I have called this approach system-oriented architecture (SYSOA). Over the past few weeks I have considered the principles of SYSOA and its application in four architecturally demanding areas: data management; systems integration, PCs and the web, and IT infrastructure.
In each area, SYSOA brings discipline and clarity. It insists on clear definition and clear ownership. It discourages IT designs where systems share resources in a non-disciplined way, such as one system dipping into the database of another system, or PC applications lashed together from components of other PC applications. However, in each of these cases, the extra disciplines of SYSOA are, arguably, a good thing that prevents solutions that are difficult to manage.
SYSOA helps standardisation. It provides a clear framework for providing standard IT platforms as generic appliances. It allows for exceptions to the standards, but shows that the full cost of defining, building and running non-standard platforms has to be met by the systems that need them. SYSOA stops specialists having to take on non-standard builds without the support or resources to do the job properly.
When considered from any one specialist area, SYSOA is not revolutionary. Different specialists - development, analysis, DBA, middleware, desktops, web, infrastructure - might think SYSOA is a nice idea, but it isn't how any of these areas view their work.
The impact and benefit of SYSOA is subtler than that. It does not replace specialist views, but is a shared view that each of these different areas can work within. Each area has to focus on its own technologies - objects, processes, consolidated databases, web services, virtualization, standard PC builds, web server clusters - but SYSOA creates a simple, common structure into which all these different technologies fit.
Over the past few weeks I have become more certain that there is something very valuable in SYSOA. Taking a system view of IT has great management advantages. Making that system view real in the IT architecture takes the management advantages deeper into the work of the IT organisation.
Achieving SYSOA is simple. All you need to do is to think of systems as the main structuring principle of your IT. Clearly define the purpose, ownership and boundary of each system. Make sure everyone uses the same definition, and never build solutions that undermines your ability to manage each system separately. This will then let you use systems as an understandable and much-needed common point of reference between business owners, users, IT management and technical specialists.