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

IT Risk - platform and architecture matter

Once, in my days running sales and marketing for a software company, the VP of Technology was growing agitated with my complaints about our product's hardware and database architecture. "OK," he said in exasperation, "if you don't like [proprietary platform], what platform do you want the product to run on?"

In imitation of a Qwest ad from that time, I said, "I want it to run on any operating system, on any database, from any provider." I then glanced at him to make sure he wasn't winding up to smack me in the head. "You asked."

What I was trying to get across is that fighting the platform battle with customers is a certain loser. If they are a Unix shop, and you are trying to sell them Linux, or OS400, it's a nearly impossible task. It's better, frankly, to cut your losses and find another prospect for which your product is a good architectural fit.

Why is that so? A new book helps sort it out. "IT Risk," by George Westerman of MIT's Sloan School and Richard Hunter of the Gartner Group, discusses how companies can and should manage risk within their information-technology infrastructures.

And one of Westerman and Hunter's key points is that a company's foundation architecture must be simple and standardized. Such an architecture can be more easily protected from disaster, can adapt more quickly to changes in the business, and can limit data access to authorized parties more easily than a hodgepodge of separate systems, platforms and applications.

Like it or not, when you are trying to sell a nonconforming software product into a company that has built a simple, standardized IT foundation, you are trying to force them to accept a hodgepodge. And they won't do it.

Product managers need to manage the lifecycle of their architectures as well as the lifecycle of their functionality. It can be painful and expensive, but not as expensive as a good product that loses its market due to an outdated architecture.

information technology, IT, books, risk, product management, reading list, books