What You Need to Know About Service-Oriented Architecture

Don Buskard, senior vice president and CTO at AXA Financial, a $7.5 billion insurance and financial services company, compares his service-oriented architecture (SOA) to a system of gears: some big and slow-turning, some small and fast. And Buskard believes SOA is the right mechanism?a transmission of sorts?for an IT environment (like so many others) in which relatively ponderous data-crunching legacy systems must mesh with agile front-facing applications.

Service-oriented architecture isn’t a new approach to software design. Some of the notions behind SOA have been around for years. Jess Thompson, a research director at Gartner, says the underlying concepts date back to the early 1970s, when researchers started drawing boundaries around software and providing access to that software only through well-defined interfaces

(an idea called encapsulation). But lately, SOA has been gaining traction, especially as CIOs begin to think seriously about Web services. Gartner estimates that by 2008, more than 60 percent of enterprises will use SOA as a “guiding principle” when creating mission-critical applications and processes.

But to implement an SOA, you must first understand it?and that isn’t always easy. So let’s begin with some simple questions and (hopefully) simple answers.

What the Heck Is an SOA?

SOAs start with services, which are groups of software components that carry out business processes, for example, verifying a credit card transaction or processing a purchase order. At its most basic, an SOA is a collection of services on a network that communicate with one another. The services are loosely coupled (meaning that an application doesn’t have to know the technical details of another application in order to talk to it), have well-defined, platform-independent interfaces, and are reusable. SOA is a higher level of application development (also referred to as coarse granularity) that, by focusing on business processes and using standard interfaces, helps mask the underlying technical complexity of the IT environment. It’s like translating a high school science text for your kindergarten-age daughter; you can tell her that the heart pumps blood without getting into the mitral valve and pulmonary veins.

Isn’t SOA Just Corba in New Clothes?

No. SOA is an evolution from traditional tightly coupled application connections?including common object request broker architecture, or Corba?to loosely coupled ones, such as Web services. Tight coupling makes it hard for applications to adapt to changing business requirements, as each modification to one application may force developers to make changes in other connected applications. Also, object-oriented development uses a finer level of granularity?objects might be defined at the level of employee or customer order. In an SOA, a service is defined at a more abstract level, say, a business process such as generating a phone bill.

What Are the Benefits of Adopting an SOA?

SOAs make it easier to integrate the “everything but the kitchen sink” IT environments found in most companies. “That’s the big value of an SOA; it works very well in heterogeneous environments,” says Jason Bloomberg, a senior analyst at ZapThink, a Web services consultancy. Developers don’t have to spend an inordinate amount of time writing new lines of code to connect applications. Instead, they can use standard protocols, such as Web services. And large chunks of SOA code are reusable, reducing development costs. An SOA takes your legacy investments?your SAP, Siebel, Oracle and the like?and makes them all play nicely (and more cheaply) together.

“That’s the sweet spot for SOA?leveraging your existing portfolio,” says Tim Bass, president of Silk Road, an IT consultancy. You don’t need to rip and replace those systems with brand-new ones. By identifying the capabilities of existing systems and leveraging them, you maximize the value of your IT investments while minimizing your risk, he says. Also, building services?for example, using simple object access protocol (SOAP) and Web services description language (WSDL)?not only smooths the internal integration process, it also lets customers and business partners share information more easily across company firewalls.

Another benefit of an SOA is that it can lead to a better dialogue between the CIO and line-of-business execs by forcing IT workers to think in terms of business?not technical?architectures. If a business wants to build a better inventory control system, for example, the operations folks can hook up with the IT architects and talk about the best way to design it based on business flows and how best to meet the needs of the business. And implementing that design, which often involves large-scale integration, becomes a less gruesome task.

For that dialogue to work, businesspeople have to think about the best ways to run their business. What processes do I need to put in place to best accommodate my customers? How can I improve my level of customer service? By exposing and sharing information across once-siloed applications, companies can extract more business performance data in real-time, improving business intelligence. There’s a whole new level of responsiveness companies can exploit through a common architecture, says Dana Gardner, a senior analyst at the Yankee Group. “If there’s a hurricane on the East Coast, [resulting in a] great need to move plywood from another part of the country, I can be responsive in real-time,” he says. “I have information about what’s going on in my business that I didn’t have before.” In a perfect SOA world, companies improve their ability to adapt to changing business requirements and shifting market conditions.

Finally, the benefits of easier integration and increased agility lead to greater ROI. Buskard says he’s achieved a 200 percent return on his SOA investment. One of AXA Financial’s most popular SOA-based services is Get Client, in which any front-end app can issue a command and, after probing around the legacy systems, come back with a complete picture of a customer’s investments. Buskard says that Get Client is one example of how AXA achieves its ROI?developers design services to be generic enough that they can work with an array of front-facing systems, reducing development time and freeing developers to spend more time on business solutions. In addition, IT workers can easily incorporate new technologies into the SOA, reducing risk and expense while speeding development of new applications.

What Role Does Web Services Play in an SOA?

First, it’s important to note that an SOA does not require Web services; and Web services can be deployed without an SOA. There are those, however, who believe that building an SOA using Web services is the ideal approach. Gartner’s Thompson belongs to that camp. He cautions, however, that users must implement Web services properly to create an SOA. If done correctly, he notes, a Web service is little more than an SOA that uses SOAP and WSDL.

Buskard, on the other hand, has built his company’s SOA without Web services, as none of his internal or external customers are asking for them at this point (though he’s keeping his ear to the ground in case they do later on). Instead, he uses IBM’s WebSphere MQ as a messaging and integration layer to connect legacy systems with his front-end apps. This works in tandem with Candle’s PathWAI suite, which helps optimize WebSphere MQ by monitoring its performance.

Jon Johnson, chief engineer for Northrop Grumman Mission Systems of the Colorado Springs Engineering Organization, also has built an SOA, based on a publish-subscribe system (see “An SOA Glossary,” Page 80) without Web services. He’s deployed Java Message Service as a messaging layer on top of a Web server and an application server, and uses the enterprise service bus from Sonic Software to help with integration and data movement. Johnson says that his services are designed like Web services, only without the Web services interface.

One of the major benefits of the SOA, he says, is that the right data gets sent to the right person or application. For example, when a user logs on using an ID, the system knows who the user is and pushes only the data?for example, maps and task lists?that the person is authorized to see.

What Are the Challenges?

Security is a big one. “It’s always easier to secure a closed system than an open architecture,” says Silk Road’s Bass. CIOs must deal with the lack of security standards for Web services (see “Calculated Risks,” www.cio.com/printlinks). To overcome some of these security roadblocks, Bass advises that companies move slowly when setting up an SOA, focusing first on business processes that don’t require a high level of security.

Trying to manage the complexity of a services configuration can be tricky as well, says Bass, and requires a good SOA governance model. For example, if you have nodes on a network that are service-oriented and 100 people are using a certain interface, how do you communicate with those users if someone decides to change the interface?

Another issue is network monitoring. “As we create the capability to orchestrate complex Net-centric business processes in a service-oriented architecture, we also create complex monitoring and auditing requirements,” says Bass. For instance, when a transaction goes awry on a service-oriented network, which could involve multiple service providers, finding out what went wrong or where the transaction dropped or whether someone put bad information in the network can be a challenge. “The current Web services technical standards are only beginning to scratch the surface in making these lofty service-oriented distributed collaboration, process orchestration and monitoring goals a practical reality,” Bass claims.

Finally, there’s the cost issue. Building an SOA isn’t cheap; reengineering your existing systems architecture is going to cost some serious money. It also requires significant human capital, including business analysts to lay out the business processes, systems architects to turn processes into specifications, software engineers to develop the new code and project managers to track it all.

Are There Any Generally Accepted Best Practices for Building an SOA?

It may sound obvious, but having a blueprint for your SOA is critical. It’s very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building an SOA is to keep people?including both IT and business-side staff?focused on the architecture goals.

IT execs will also need to identify the right level of service to provide. And those services shouldn’t have too fine a granularity?that defeats the goal of services, which is to function at a higher, business-process level. Too narrow a focus creates a need for more services, which increases development time. And in the worst case, too many services can flood a network. You should also employ an SOA where it will do the most good. Bass notes that quality of service needs to be taken into account when implementing SOAs. He says that a loosely coupled architecture is good for systems that don’t require near-real-time responses. Pick systems where, if information doesn’t get where it needs to be on time, the consequences are minor, not catastrophic. (For example, an SOA-based air-traffic control system would be a bad idea.)

Should You Be Thinking About an SOA?

Many CIOs are seriously considering SOAs, particularly as they experiment with Web services. The potential payoffs are compelling?increased agility, faster and cheaper integration, the leveraging of existing IT assets and a focus on business processes. Sure, building an SOA requires a significant investment, and there are still plenty of questions around the immature Web services market. But, at a minimum, it’s a strategy worth watching.