Vendors could do themselves a favour by demystifying service-oriented architecture (SOA). There’s nothing magical about it: businesses use service-oriented architecture all the time. A building company will use an associated rubble removal service that kicks in once the building service is completed. The two services are not the same thing, do not depend on each other, yet have a clear relationship that contributes to the overall smooth operation of the business. They may use the same truck: one service to get the materials to the site and the other to take the rubble away, but both services are still independent, although coupled.

Sharing the underlying technical function of transport is cost-effective for a business that provides both building and rubble removal services. It’s a simplified example but it illustrates many of the basic principles of how SOA should work: loose coupling of services, optimisation of business processes, sharing of underlying technical services for lower costs and nary an IT acronym in sight.