Is SYSOA worthwhile?

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.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

SYSOA and infrastructure

System-oriented architecture could help organisations build effective IT infrastructure by clarifying business requirements and making infrastructure easier to justify.

IT infrastructure is a catch-all term for the IT on which business systems are run. It includes hardware and operating systems. It includes specialised software such as monitoring and backup.

Many organisations save costs by standardising and consolidating infrastructure. This can be difficult because nobody outside the IT organisation really understands the issues and so it is difficult to make a business case. Standardisation is hampered by applications that insist on doing things in a non-standard way.

System-oriented architecture (SYSOA) splits IT into strictly independent systems. SYSOA deals with infrastructure in one of two ways. The infrastructure for each system can be managed as part of the system - each system owns its own slice of infrastructure. Alternatively, the infrastructure can be provided as a generic IT capability, in the form of appliances. Either way, SYSOA maintains a clear relationship between infrastructure and the systems it supports. This helps show the impact of infrastructure on the cost and risks of business systems, and helps justify the infrastructure.

The distinction between infrastructure that is part of a system and infrastructure that is a standard appliance helps clarify responsibilities.

Organisations with standard infrastructure can consider the infrastructure as an appliance. Because it is a standard capability that is the same for all systems, no single system can set requirements. The IT organisation can, and should, design the infrastructure to meet the general case, not unique requirements from unusual systems.

SYSOA allows for systems that need non-standard infrastructure, but clarifies that the full responsibility for defining requirements, justification and cost falls on the system owner and their IT representatives. (It can not just be dumped on the infrastructure specialists.) Showing the difficulties and full costs of non-standard infrastructure is the best way of showing the value of standardisation.

Many organisations are adopting server and storage virtualization as a way of reducing infrastructure costs. SYSOA encourages smaller, more independent servers that have few interdependencies, which are good candidates for virtualization.

In SYSOA, infrastructure services such as monitoring and backup, are either systems in their own right, or part of the standard appliances. (Often they are both - a core system, and then components on each appliance.) Making them systems in their own right raises their visibility, as they can then be considered alongside all the business systems.

SYSOA is not the major driving force for infrastructure, but in many ways it makes a positive contribution:

• The system view of SYSOA helps justify infrastructure because it makes a clear connection between the characteristics of infrastructure and the costs and risks of business systems.
• SYSOA provides a framework for the standardisation and consolidation of infrastructure.
• SYSOA allows for exceptions to the standards, but clarifies where the responsibility and full costs of these lie.
• SYSOA works well with virtualization.
• SYSOA helps raise the profile of infrastructure systems such as monitoring and backup.

Next week I will bring together SYSOA's impact on many different parts of IT, to weigh up whether it is something we should pursue.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

SYSOA, PCs and web-based systems

System-oriented architecture gives clarity and discipline to the management of PCs and web-based systems.

I have been exploring the idea of structuring IT into strictly independent systems, which I call system-oriented architecture (SYSOA).

For back-end, server-based systems, SYSOA provides clear rules for ownership and separation that can make management easier and more effective. But what about PC systems and systems with a browser front end?

Let's start with the simplest case. A server-based application with a browser front end can be considered and managed as a single system. The browser, and the PC on which it runs, are just a generic capability - an appliance - that is not managed as part of the system.

PC software itself can be managed in one of two ways.

Standard PC software, which everyone needs in the same way, can be managed as part of the PC appliance. More specialised PC software that has a specific business purpose needs to be managed as a system in its own right.

This distinction allows the IT organisation to focus on providing a relatively simple, standard PC platform. Specialised PC-based business applications require additional ownership, control, resources and management. The PC support team are not just dumped with the integration, support and management of every piece of PC software. They provide a standard platform and rules for how other systems can use that platform.

SYSOA clarifies client/server systems. The client (PC application) and the server are separate systems. There is no special relationship between client and server. Composite applications, where clients use the services of many different systems, are the norm. Client/server is not a special and difficult category of architecture, but a normal interaction of independent systems.

PC-based software that combines components from many different applications undermines system independence. To be compatible with SYSOA, either:

• The applications that are combined must be managed together as a single system.
• Each application must run independently and use well-defined interface methods, not just in-memory calls and data sharing.

This isn't really a restriction. It's a response to the problem of "dll hell", where different bits of PC software use conflicting components. The disciplines of SYSOA ensure that PC-based business systems are well-behaved and do not cause conflicts.

Not all composite applications are PC-based. Some server-based systems (such as "portals" and "mash-ups") allow new user interfaces to be built from the components of other systems. SYSOA clarifies that these are just standard interactions between independent systems, not a special category of architecture.

To summarise, SYSOA provides clear guidance in many areas of PCs and web-based systems:

• SYSOA makes a clear distinction between managing a standard PC platform and managing specialised PC-based business systems that need more business ownership, control and resources.
• SYSOA encourages better management of PC applications to avoid "dll hell".
• SYSOA encourages the standardisation of client/server connectivity, and the enablement of composite applications, both PC-based and server-based.
• SYSOA provides a management structure that can be applied consistently across PC systems, web-based systems and server-based systems.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

SYSOA and systems integration

System-oriented architecture (SYSOA), which splits IT into strictly independent systems, provides a very effective basis for systems integration.

SYSOA encourages good integration design.

• SYSOA insists on clearly defined system responsibilities and system boundaries, and interfaces that represent meaningful flows of business information between system owners.
• SYSOA stresses that interfaces should not compromise the independence of systems by revealing the internal data structures of systems, their processing, or their technology.
• SYSOA clearly distinguishes between integration of system components, for which few rules apply, and integration between systems, which must be carefully controlled.

As well as encouraging good integration design, SYSOA helps make sense of middleware used to build integration solutions.

For example, integration designs often uses fire-and-forget messages. This requires some middleware, such as message queuing, to handle the message between the sending and receiving application. SYSOA achieves this in one of two ways: either the sending systems includes a middleware component which takes the responsibility for the message away from the main application software, or the sending system passes the data on to a middleware system (such as a message queuing system) that takes this responsibility.

As another example, business process management (BPM) tools are used to co-ordinate the flow of data between applications to support a meaningful business process. SYSOA clarifies this by defining each application of BPM as a separate system with a specific purpose (the management of a particular end-to-end business process) and an owner.

Each type of middleware technology can be classified as a component, or as a system in its own right. Where middleware is promoted to system status, SYSOA enforces that it is meaningful and owned, which provides the clarity and authority required to manage it effectively. SYSOA does not do away with middleware or undermine its importance, but makes it more understandable, ownable and practical.

SYSOA works well with common standards for the technical implementation of integration (such as XML data formats and messaging middleware), and with a common data model for integration. However, SYSOA does not enforce this, and legitimises a more laissez-faire approach. This may seem like a weakness, but I think it is a strength in two ways.

First, SYSOA's approach is very practical. It means that you can start to achieve the management benefits of SYSOA without a costly redevelopment of all interfaces. SYSOA provides clarity and direction for integration without either requiring or preventing the implementation of common standards.

Secondly, it forces the problems to be managed properly. Integration and middleware are often presented as a magic glue to resolve the differences between systems. But middleware does not solve these problems, it only moves them. Differences in technical implementation represents ongoing complexity, risk and cost to IT. Differences in the meaning of data represent real misunderstandings and risks in business communication. These problems need to be fixed, not moved. SYSOA forces the problems back to the systems themselves, where they can be permanently fixed.

SYSOA provides the clarity and ownership required for effective integration. It moves middleware away from overambitious magic glue to practical, ownable solutions. It forces integration problems to be managed properly, and not abdicated. SYSOA is a very effective basis for systems integration.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.