SOA for Dummies

Ask an IT executive to define service-oriented architecture (SOA), and there’s a good chance you’ll get at least some kind of a reasonable answer. Ask that executive’s functional peers the same question, and the answer might not be so clear.

SOA has become a hot topic in the IT world, and many view it as the next stage in the evolutionary process for companies and the IT that supports them. “SOA is inevitable,” Charles Abrams, research director with Gartner, told the E-Commerce Times. “The misconception is that people think they can make a decision to go SOA or not go SOA.”

What it means to “go SOA,” however, is less certain, particularly outside enterprise IT circles. The concept may offer greater efficiency, productivity and collaboration and enable competitive advantage and growth, but if you don’t know what it is, it probably won’t take you too far.

Entering Lego Land

OASIS, the Organization for the Advancement of Structured Information Standards, defines SOA as “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”

That’s all well and good, but it can be a lot more useful to use metaphorical terms. Think instead of SOA as a set of Legos.

“In the old days, IT was basically thought of like Silly Putty — you could build anything you wanted, but everything had to be done in custom fashion,” Miko Matsumura, vice president and deputy CTO at webMethods and committee chair at OASIS, told the E-Commerce Times.

Continuing the toy metaphor, the second era of IT was “the toy car era — you bought everything preassembled in one giant package,” Matsumura explained.

With SOA, we have now entered the Lego era. “You can basically get anything you want, it’s just a question of putting together the pieces,” Matsumura said.

Assemble to Order

Let’s say a company wants a metaphorical car — a metaphor for some strategic capability. In the Silly Putty era, of course, it would have had to build it by hand in a relatively slow and expensive process. In the next era, the company would have bought the whole thing ready-made. The problem then, though, was that if business conditions changed and the company decided what it really needed was a metaphorical boat, it would have been out of luck.

“It was like ERP (enterprise resource planning),” Matsumura explained. “Companies bought a big solution and then found out it didn’t do some things they wanted it to.”

In the Lego world of SOA, on the other hand, “it’s a kind of assemble-to-order computing,” he added. You simply snap together the right pieces, and what you want is what you get.

To see why that’s so compelling, imagine now that you’re a toy manufacturer, and you learn that toxic paint is being used in some of your product line. You need to move quickly across multiple business processes, searching your supply chain to find the problems, identifying and establishing relationships with new suppliers, going back into your distribution network to find the bad products and recall them.

“All these things are more swift and comprehensive with SOA because you can quickly reconfigure your processes,” Dana Gardner, principal analyst with Interarbor Solutions, told the E-Commerce Times. “SOA provides excellent agility.”

Focus on Business Services

Returning to the Lego metaphor, one thing that’s critical to understand is that the building blocks of the enterprise and its IT are not functions or applications or other units of computing, but rather business services — with an emphasis on the “business” part.

“A business service has to have a business meaning,” Matsumura explained. “If you describe a business service to a business person and they don’t understand what you’re talking about, then it isn’t a business service.”

In some ways, a business service is almost like an iPod, he added: “It does only one thing, but it does it perfectly and it fits in with the other things you want to do.”

By reconfiguring itself into a collection of business services, the whole idea is that an SOA enterprise can “snap” those services together as needed for multiple different kinds of solutions.

External Links

Let’s take a bank for example. One of its business services might be a customer identity service, which records basic information such as customer names and addresses. Another service might be a loan application service, which would take down information about how much money a customer wants to borrow and other related information. What might happen then is that the loan application service might connect with a credit reporting service outside the organization.

That, in turn, gets back to the OASIS definition’s notion of using capabilities under the control of different ownership domains. “What’s interesting about these Legos is that you can assemble them from all over the place,” Matsumura explained. “They don’t all have to be under the same roof.”

If a company wants to do something involving business services it doesn’t have, that’s a signal that it might need to partner with another firm — “snap in someone else’s Lego and make them part of your virtual enterprise,” Matsumura said.

The world of SOA then becomes a world of mashups, where what you’re mashing up is business services. “What becomes really important is your customer, and what your customer wants to have happen,” he said.

New kinds of competitive business decisions can follow. For example, “if I’m a phone carrier, should I merge with a TV station?” Matsumura explained. “SOA makes decisions like this much more fluid.”

Realizing Hidden Value

Cost savings can be another result.

“One way of looking at it is a client/server architecture done right,” Abrams said. “It’s primarily about saving money because it lets you use the power of the software, services, platforms and integration technologies that you purchased in the past five years or so — power you’re not getting now because the technologies are not working well together.”

Indeed, “it saves money over time because you’re no longer supporting individual silos,” Gardner agreed. “This way you reuse each service under multiple business processes.”

On a higher level, services can be managed as a portfolio, letting the enterprise focus on those with the highest rewards, Matsumura added. “What SOA can do is enable business users to understand not only what it is those techie guys in IT are doing — which is good — but also, because of the portfolio metaphor, it allows them to judge the relative merit of things and helps them decide what to focus on.”

‘Simply Imperative’

Implementing SOA involves organizational changes on multiple levels, both technological and cultural, and can take anywhere from six months to six years, Matsumura said. However, the benefits are many.

“I think the really exciting factor about SOA is that it takes a bunch of incomprehensible technologies and it makes them into a human endeavor,” he concluded. “It takes something that was previously seen as messy and technical and drives it into something that’s seen as clean and single-functional, almost like an appliance.”

The result: “As IT people start to focus on business services, the business people start to say, ‘I didn’t know we could do that!’,” Matsumura said. “A lot of the preexisting capabilities become usable again and part of a bigger system.”

In short, “the world is moving in this direction, whether you like it or not,” Gardner said. “SOA is simply imperative.”