SYSOA and systems integration

By Andrew Clifford

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.

Subscription