Special Reports

How to Explain SOA to Your CIO

SOAs will help change how business and IT work together. It will take time, though. Meanwhile, here's what you want your CIO to know so that your company can move in the right direction.

• By Linda Briggs
• 11/01/2004

You know how it works with the latest buzzword. The day is coming when you'll run into someone from top management in the elevator, or in the hallway after a meeting, and he or she will casually ask, "So what are we doing these days about SOAs?" That's when you want to be ready with just the right amount of information to help a top-level business executive understand why a service-oriented architecture (SOA) is beneficial and something you're well-positioned for even though it won't solve every IT problem. To help you explain that and more, here's a primer on the strategic ideas and business benefits behind SOA.

For starters, some quick points on SOAs: As nearly everyone is fond of pointing out, service-oriented architectures have been around for a long time. It's a fairly simple concept, really: to standardize software functions, or services, so that numerous dissimilar applications and technologies can share them—both inside and outside the company. The loose coupling of systems and data that is the hallmark of SOAs helps address what has become a huge problem in business: complex, inflexible systems that don't share data well and can't be reconfigured quickly to meet changing business needs.

"If you're looking at your organization, you probably have duplicate systems and processes with a lot of copying and pasting from one system to another," according to Dave Mendlen, Microsoft director of Web services marketing. "For example, there's a lot of investment in CRM systems, but [companies] haven't gotten a lot of benefit from it. [With an SOA], you can now leverage that investment and get reuse at a macro level."

Predecessors such as CORBA and EDI never quite delivered on their premise of universal interoperability because they are tightly coupled, and because the technical community hasn't been able to agree on universal standards. With XML and Web services in place, and more key standards falling into line all the time, service-oriented architectures can finally start to fulfill their promise.

In explaining all this to your CIO, you'll want to be careful about distinguishing between Web services and service-oriented architectures (see "SOA: Debunking 3 Common Myths"), according to Jason Bloomberg of ZapThink, an analyst firm that specializes in XML, Web services, and SOAs. "They're different things and have different implementation patterns and different rates of return. Web services are more tactical, solving integration issues; SOAs are more strategic and provide greater business utility." Web services are some of the parts, in other words; SOAs are the connections between them.

That leads to the much-repeated promises of SOA—loosely coupled services and flexible software leading to agile business processes. That's all well and good, but from a CIO's point of view, you want to be sure to highlight the business case. After all, this is an industry that sees hype around new technologies come and go like airplanes into O'Hare International. Fortunately, with SOA, there are plenty of real business benefits ahead.

Gauging the Business Returns
One key benefit to stress is the vision of reusing existing systems and data. At many companies, probably yours included, data is locked up in various systems that don't communicate well. The idea of software reuse is attractive to management because huge portions of IT budgets are typically tied up in simply maintaining existing systems, according to Peter Linkin, senior director of integration product marketing at BEA Systems. That leaves little to spend on new systems as business needs change.

"Much of the interest in SOA is coming from managers," Linkin said. "We've been hearing from customers for a while now that the great majority of budgets—70 to 90 percent—are tied up in maintaining existing systems."

On the other hand, you should stress to management that the benefits from an SOA probably won't be immediate. For most companies, the return on investment will be long-term, after you start to reuse services and data more efficiently. That's the real business reason to begin to work with SOA ideas now: to stay competitive long-term.

Industries moving first to SOAs are those that typically lead in IT—the financial services sector, for example, which tends to spend heavily on IT. The insurance industry, according to Ron Schmelzer of ZapThink, is also leading the charge. That's because huge insurance companies are often running expensive legacy systems. That makes them eager to adopt a cost-effective way to get at the business processes, data, and other valuable assets locked up in those systems. Legacy is thus "a sweet spot for this technology," according to Schmelzer. As those companies try to reuse existing investments to save money, he said, SOAs and Web services offer an obvious solution.

"There's a lot of good short-term ROI" on SOA efforts that integrate existing mainframe applications, portal structures, application servers, deployed business logic, and directory systems, Schmelzer said. And those projects can yield a fairly quick return—"in some cases, a few months."

Assessing Vendor Positions
Although part of the promise of SOA is a cross-platform exchange that allows competing technologies such as Java and .NET to talk, that doesn't mean products and platforms won't matter. As always, vendors are jockeying for position, touting their products as the best answer for your organization.

Sorting between differing vendors can be tough, and this is where you can help top management, who should be at least partly relying on trusted in-house architects and developers for advice as they head down the path to SOA. Of course, whatever technologies you're running now will probably affect your future direction. But a great advantage of Web services and SOA is that you can leverage your heterogeneous environments—if you've been a Java shop but see advantages in a Microsoft solution, you can more easily integrate .NET into your existing environment.

One thing you want to be careful about is making sure you choose vendors and products participating in the development of Web services standards. Companies such as BEA, IBM, and Microsoft have been heavily involved in standards boards from the beginning, so that's a good indication of future interoperability.

In terms of tools, you can reassure management that top vendors are now including the basic tools needed to create SOA environments in their products. J2EE products from BEA, IBM, and Oracle, as well as Microsoft's Visual Studio .NET, for example, contain the necessary development environment and Web services calls, along with XML creation capability.

According to ZapThink, vendors' offerings fall into two rough categories of choices, and you might want to weigh your approach based on that. First is the application-centric approach, which ZapThink says works best in less heterogeneous environments with a smaller set of technologies. IBM, Microsoft, BEA, Sun Microsystems, and Oracle all offer products that fall in this category.

The other approach is based around message queuing and asynchronous messaging, or what's referred to as an Enterprise Service Bus (ESB). It uses a more message-oriented approach to connecting systems, Schmelzer said, and thus can be cost-effective. Smaller players such as Sonic Software are competing here, although Microsoft's, BEA's, and IBM's products also fall into this space.

Whatever vendor you choose, keep a close eye on standards. That's the advice of David Linthicum, CTO of Grand Central Communications, a company making a big play in Web services and SOAs. "People need to be careful about lock-in," Linthicum said. "Watch out for proprietary interfaces and extensions that go beyond the standard. Make sure they can work and play with other technologies."

SOA Challenges Ahead
Although much of the hype around SOA tends to make it sound like a done deal, you'll want to point out to management that work remains to be done in several areas. That includes evolving standards, including some important security standards. Legitimate questions about performance also arise, as well as management of Web services and SOAs themselves.

Performance is a common issue that comes up regarding Web services, and by implication service-oriented architectures. Does moving to an SOA, with its web of loosely coupled services and heavy use of XML, mean network performance will suffer? After all, by their nature, loosely coupled Web services will have more overhead than their tightly coupled counterparts. Also, Web services' use of XML tends to mean larger messages. It all adds up to slower-moving traffic—and more of it.

Most analysts and observers agree that hardware will continue its historic pattern of more processing power at lower prices, thus keeping up with increased traffic and more complex software demands. But performance, and your infrastructure's ability to handle the associated additional overhead with Web services, is definitely something to keep in mind during an SOA design.

For starters, you'll want to steer management to consider where in your organization an SOA makes sense—and where it doesn't. Many applications don't need super-fast response times. In cases where they do, the loose coupling implicit in an SOA might not be the best approach.

It comes down to using SOAs appropriately. "They're especially good when you have changing business requirements," said ZapThink's Bloomberg. "But they're not good when you have very high performance requirements—I wouldn't want my anti-lock braking system to be a service-oriented architecture. I want it to be tightly coupled and to respond in milliseconds."

According to consultant Doug Barry, who has written a book on SOAs (see the sidebar, "SOA Resources"), good design makes the difference. Because an SOA tends to mandate sending large, somewhat slow messages, your Web services and SOA design should address that—for one thing, by considering the granularity of services, Barry suggested. For example, a good design ensures the network isn't sending numerous small XML messages back and forth unnecessarily. Organizations that previously used DCOM or CORBA dealt with this same design issue, he pointed out.

Performance questions go back to the need for overall planning and organization as you move to Web services and an SOA. "You can architect [the system] poorly, and it will still work. But it will come back to haunt you," according to Michael Liebow, vice president of Web services for IBM Global Services. Precisely because Web services are bandwidth-intensive and potentially resource-demanding, "you need to be mindful of their impact on your organization," Liebow said. "Technically, they're not elegant. They're heavy, they're resource hogs." Design with that in mind.

Security, always an issue, is no more or less a concern with Web services and SOAs than elsewhere in your enterprise. You can reassure management that just as elsewhere in the organization, security depends on careful design and implementation. In fact, Bloomberg argues that security can be tighter with an SOA, because "with SOA, it should be handled on the enterprise level and fully policy-based. If you get that right, you'll be more secure than in doing security on a silo basis."

Developing security standards are important, so you'll want to help your company keep an eye on the premier security standard for Web services, WS-Security, and others that will evolve within that framework. WS-Security is a fairly mature standard and can handle complex authentication and encryption, but more security standards are in the works.

What about management? Who keeps track of all of these services, running anywhere across your company or anywhere in the world? Who's responsible when something breaks? Eventually, the promise of a well-designed SOA is less management, not more. "If you build an SOA properly," according to ZapThink's Bloomberg, "operations management should be simpler. Your infrastructure should be metadata-driven. Instead of all these different instances of functionality and business logic locked up in all these different systems, where you need special technology to access it, the goal is to have metadata that describes these systems—and the metadata can be managed in a central way."

On some levels, management simply isn't an issue yet because most companies don't have enough Web services in place. When they do, according to Bloomberg, the software tools to help will be available—a rare case of technology actually preceding the market.

Once again, a well-designed and easy-to-manage SOA comes from careful planning. "You're not going to get around putting some thought into this," Grand Central's Linthicum warned. "You've got to do your homework up front—don't just start throwing technology at it."

Are We There Yet?
There's little doubt that service-oriented architectures will change IT forever in a fundamental way, but dramatic phrases like that don't say exactly when such a change might take place. It's important for your CIO to realize that it will take considerable effort and investment across many companies to get from here to there. The good news: Because this isn't something happening overnight, your company has time to act (see the sidebar, "Staffing Up for SOA").

How long? Well, most growth predications for this sector of the market are optimistic. According to IBM, Web services and the SOA market, now just 3 percent of the IT services market, will grow to 17 percent by 2007—about $100 billion in client spending overall. That's not software or hardware—just services.

According to IDC, more than 80 percent of companies surveyed plan to have Web services projects under way by 2005. IDC predicts that the total value of the Web services market alone, including hardware and software as well as services, will grow to $21 billion by 2007.

As Web services and SOAs come into use more and more, Gartner predicts a dramatic drop in the cost of releasing and customizing applications. Today, for every $1 spent on a software license, it costs about $5 to $6 to implement the software. By 2008, Gartner says, advances in Web services will drastically lower the installation costs of software applications to $2–$2.50 for every $1 spent on a license.

Finally, according to ZapThink, we're close to what they call "the tipping point" for Web services: the point when enough companies will have adopted at least some Web services that deployment and use will explode. "When that point passes," ZapThink predicts in a paper, "the world of distributed computing will never be the same."

Getting Ready for SOA
Given those kinds of dramatic predictions and spending ramp-ups, what can you do to help prepare yourself and your company, including top management, for the changes ahead?

One thing nearly everyone agrees on is this: Don't wait. There's definitely a learning curve to implementing Web services and an SOA, and you might need to discard a few failed projects as you go. You'll want to discourage your CIO from approaching things with an eye only on the ROI—that's not the best approach initially with any new technology.

"I tell people they need to get started now so they'll be ready when the rest of their industry is ready," according to consultant Barry. "The issue for a company is this: Within your industry and three, four, five years down the line, when people are going to be hooked together and able to use Web services in some way, you want to be there. If you don't get started now, you won't be participating then."

Also, don't let management fall into the trap of looking at Web services and SOAs as the solution to everything. "You need to know when to pick up the SOA hammer, and when to pick up some other architectural approach," Microsoft's Mendlen said. "It's just one of many tools, [and] not the architecture you want to use for everything. We're trying to tell customers, SOA is a means to the end—and the end is these connected systems."

So encourage your company to start with small projects and expect some failures. Fortunately, this isn't a technology that needs a huge commitment initially. At some point, when you see more clearly where you want to go, you can convince your CIO to commit more resources. Again, accessing data within a legacy application through Web services can create an early win. An area with manual processes that can be performed by software instead is another good place to look for a relatively easy ROI.

Keep an eye on ongoing progress with standards pertaining to Web services. Don't let evolving standards hold you back, but stay aware and participate in the process. Watch where your particular industry is going, and how fast it's getting there. After all, a big part of SOA is about sharing, so you want to know when others in your sector are ready to join in and how you can maintain your competitive advantage.

In short, you want to help your CIO view the move to Web services and SOAs in two ways. First, it's an immediate initiative that your company should start dabbling in now, if it hasn't already. Second, SOA is a huge wave that you want to ride as it gradually transforms business processes and IT.