What is SOA and Why Does it Matter?

ClearPath Forward3 minutes readMar 15th, 2012
SHARE +

Developing IT applications that keep pace with business requirements has always been a challenge to IT providers. To improve productivity and the quality of software, the IT industry has tried to adopt practices standard in other engineering disciplines. In particular, using ready-made components within well-defined and proven structures has received a lot of attention. Any complex product such as an aircraft contains large numbers of components or subsystems – engines and avionics systems for instance – which are sourced from many different companies.

From the earliest days of the software industry, technologies such as modular and structured programming, component and object technologies, together with methodologies for design and implementation, have attempted to impose order on software development and encourage reuse. In more recent years, a number of factors have made the need for good systems engineering even more critical.

First, time and cost pressures are becoming ever-more acute – do more with less is the mantra. Greater technical complication is a second factor: IT services are increasingly delivered by a collaboration of separate systems. The systems may be within a single organisation but external collaboration is more and more prevalent. Although not a new phenomenon – airline systems have been collaborating for decades – the rise of the Internet has increased the level of inter-communication by orders of magnitude.

A third factor is history. Few organisations start from scratch but have a collection of existing systems running the business. Attempting to rewrite or otherwise replace these systems is a high risk and time-consuming activity. It is much more effective to incorporate them into a collaborative structure.

Building such structures cannot be done on an ad hoc basis, inventing the rules as we go along. That way leads to chaos, just as it would with any large engineering project. Success depends on working within a coherent framework of patterns, rules and standards: architecture is the name we give to such a framework. Service-oriented architecture (SOA) has emerged as the leading framework.

In the SOA approach, IT is regarded as providing services for its users, the consumers of the services. The services are delivered by one or more service providers, which are existing and new application programs. All that is known externally about a service provider is what it does and how to request its services. They are independent of each other, may be implemented in any technology and be located in different organisations.

In addition to providing a pattern for building systems in this way, SOA recommends standards such as Web Services for interconnection.  It also describes approaches for incorporating existing application systems, which may not have been written with SOA in mind. There is extensive collaboration in the industry, in bodies such as the World-Wide Web Consortium (W3C), to develop the standards required.

The industry in general and Unisys in particular now have a considerable body of experience in adapting existing applications to fit an SOA approach. ClearPath systems, for example, frequently host critical applications which represent a massive investment in intellectual property. In the majority of cases, adapting them to run in an SOA implementation is proving to be straightforward, using the rich set of tools available. The level of effort, risk and cost involved is trivial compared with rewriting the applications from scratch.

I’ve written a lot more on SOA and ClearPath systems in the following White Papers: Service-Oriented Architecture: Delivering for Business and Service-Oriented Architecture: ClearPath Systems in SOA.

Tags-   ClearPath Service-Oriented Archhitecture