What in hell is Service-Oriented Architecture?

A hint--it does not describe the new headquarters building for the International Red Cross. Rather, it is either the newest empty IT buzzword or the most important innovation in corporate computing since that Internet thing.

First, let's describe the problem. Companies still do most of their business functions in-house. To support those functions, they have over the years developed customized IT systems. Through growth and acquisition, these same companies have ended up with multiple instances of very similar processes supported by very different systems. This duplication is wasteful both in IT costs (maintaining redundant systems) and in operating costs (doing the same thing in different ways).

Employing an ERP system like SAP or Peoplesoft can address part of the problem--through brute force, a successful SAP implementation requires a company to adopt one way to process, say, employee expense reports. Yet that leaves lots of room for improvement. For the Fortune 1000, are there really 1000 uniquely valuable ways to process expense reports?

And that's where Service-Oriented Architecture (SOA) comes in. SOA specifies IT systems as loosely coupled sets of services. Processing an employee expense report is one such service. Different front-ends, say web vs. mobile, are different services. A system architect then would combine these services into applications--plugging the web front end on for a desktop expense-report application, plugging the mobile front end on for a mobile app.

This was some of the thinking behind object-oriented programming since the 1970's, but services are much larger than objects, they are completely self-contained, and the "orchestration" required to assemble them does not require programming. What makes this possible is the internet and programming tools like Java, SOAP, XML, etc. A chunk of code receives a request for services over the net, processes it, and returns results to the calling process.

A company, were it to organize itself around a service-oriented architecture, could easily select systems to implement a standard expense reporting process, or outsource the process. If a better system or outsourcing partner emerged, the company could adopt it easily. And so on across all its processes. The promise would be a company that executes commodity processes very efficiently, and that is able to truly differentiate its most value-adding processes.

But it's a daunting change. The article "The Next Revolution in Productivity," by Ric Merrifield, Jack Calhoun and Dennis Stevens, in the June Harvard Business Review addresses this question. It also provides a detailed overview of SOA and the implications of this model for companies.

Which are: the potential of SOA is almost limitless, yet implementing it will be very difficult. It might be more expensive than those terribly costly SAP implementations you read about in the paper. In fact, startups who adopt this type of methodology from the outset may be creating a long-term competitive advantage against the dinosaurs.

Further reading on SOA:
An SOA overview from xml.com
IBM resources on SOA
The same from Microsoft
A nice one-page diagram

Tags:
what in hell is, information technology, architecture, business processes