Understanding and implementing SOA in a middleware environment

SOA (Service-Oriented Architecture) is arguably one of the most misunderstood terms in the IT industry.

Whilst this is probably because the term has been around since the earliest days of computing in the 1960s and 1970s, when software flowcharts were de-rigueur for program development, the methodology is highly appropriate to today's 32- and 64-bit computing systems.

Put simply, SOA is a methodology for defining how different business processes - which can be fully or partially IT-enabled - interact with each other.

The aim of SOA modelling is to develop a loose coupling between different operating systems, their software and other technologies in such a way that it is possible to easily exchange data between the various processes.

To do this, SOA defines the IT-enabled business functions of an organisation into separate services which can then be linked together across a network.

The major advantage that stems from positive use of SOA is that quite disparate IT elements can be linked together: for example, a 1980s legacy mainframe-based system can be efficiently interfaced with a modern client-server PC-based network without wastage.

Furthermore, the programming that underlies the legacy systems can also be re-used in the modern computer system, thanks to the use of common coding structures and other programming approaches.



What's in it for me?

Whilst SOA methodologies were the domain of `men in white coats' in the 1980s and 1990s, the discipline of approaching IT development - at all levels - using an SOA model is that many more people in a given organisation can understand how the IT process works.

At its most basic, a 3D flowchart-style map can be drawn up of a company's various IT-enabled processes, allowing most managers to understand - in relatively simple terms - what is required to interconnect the various IT functions together. Continued on next page Tags: EDI, SOA, business intelligence, business process management