The Truth About SOA

1 2 Page 2
Page 2 of 2

Veterans caution that it’s difficult to predict the reusability of services. Sizing the services properly (known as granularity) so they don’t try to do too much or too little is an art. "We have challenges with granularity," says Howie Miller, VP of integration architecture for IBM’s internal IT group. "I’d say 30 percent of our assets drive 90 percent of the return because they are sized better," says Miller. Heffner agrees: "At one auto company I’ve talked to, they had some services that were used 20 times and others that were used only once."

Q: I need to show value to the

business for everything I do. How do I balance the architecture planning with the need to prove value to the business quickly?

A: Architectural planning is time-consuming. Service-oriented development, drawing upon well-known programming principles and widely available technology standards (such as SOAP, HTTP and so on), can happen a lot faster. But the two need to happen in parallel, say experts. "We do development projects as needed and then on the side we have a longer multiyear project of mapping out the processes and building enterprise-level services," says Kurt Wissner, managing director of enterprise architecture and development for American Electric Power (AEP). "People need to see the benefit of SOA pretty quickly. That’s why I like the project route, because otherwise you don’t have anything tangible to sell to anyone about why you’re doing this."

While it would help to have the architectural plan and the process mapping in place before building the services (to improve the chances for reuse), architecture planning has no short-term payback, which can be devastating. "I tried to boil the ocean at another company and I failed," recalls Wissner. "We did a big multimillion-dollar architecture plan that duplicated what we already had. It didn’t provide much value over traditional point-to-point integration, and we had nothing to show for our efforts. If you start with the entire enterprise, there are too many risks you might fail."

By taking the enterprise planning in smaller chunks at AEP, Wissner can more easily recover from setbacks. "We’ve had hiccups but could take corrective action because the issue wasn’t that big," he says. "If you break it into simpler pieces, it’s more easily digestible."

"Business processes change all the time," adds Praveen Sharabu, director of enterprise architecture and infrastructure for transportation company Con-Way. "Nobody can wait for two years while you document everything, and it will be obsolete by the time you finish."

Q: I can’t afford to build a million different services. How do I know which services will provide the most value for my investment?

A: When in doubt, start with processes that involve customers, directly affect revenue and address a specific pain point in the business. A 2006 survey by the Business Performance Management Institute found evolving customer needs and preferences to be the top driver in business process change or the introduction of new applications, followed by competitive threats and new revenue opportunities. (Cost savings was a distant fourth.) "Externally facing applications are the ones that provide the most business value, and they have a good set of change requirements that come up very often," says Gartner’s Sholler. "If you can improve those applications by 10 percent, it’s better than improving lower-level applications by 50 percent." Of course, adds Sholler, SOA may not provide more value than, say, a good packaged application. "But if it’s something you would have to build yourself anyway, you need to do it service-oriented," he says.

Q: How will SOA affect my IT group?

A: If you have a decentralized company, be prepared for a struggle. SOA drives centralization. Indeed, it demands it. "You have to have someone heading it up, and you have to have one individual or small team manage the architecture," says Mike Falls, senior system engineer for Fastenal, an industrial and construction supply company. "If each team is left to itself, they may each come up with different ways of building services. You need one group, one set of research and someone to make sure the development groups are sticking to the service development methodology."

As the service portfolio grows, the development process may begin to look like an assembly line. "It becomes a factory," says AEP’s Wissner. "You have these different project teams that you funnel work through, and they can grow and shrink as required."

Once the SOA factory gets ramped up, expect to add more project managers, business analysts and architects as the productivity of the developers increases, says ProFlowers’ Hall. "Two developers can now do the work of six," he says. "That means the architects and project managers are running to keep up with the output of the engineers. We are probably doing 50 percent more work than we did three years ago."

Those programmers need to understand object-oriented programming and distributed applications—and that means an investment in training. According to the CIO/Computerworld survey, only 25 percent of respondents have the staffs they need for SOA—49 percent said they are planning or have training programs in place for current staff to bring them up to speed.

If You Can’t Beat ’Em, Integrate ’Em

In the new SOA world, enterprise vendors suddenly are eager to make sure their application suites can play well with others.

In the ’90s, your integration strategy was simple: Buy as many preintegrated applications from a single vendor as possible. That worked for you, and it worked extremely well for the vendor; integrated application suites fetched a high price and required long-term maintenance and support contracts that promised a steady, predictable stream of revenue from customers.

Even better, CIOs’ fear of integration pain gave vendors a built-in sales advantage whenever a company wanted to add a new application to its stack. It was easier for the CIO to pick a preintegrated application from the dominant vendor than to take a risk on a best-of-breed newcomer—even if its application had better functionality—because expensive integration disasters had become the much-publicized bane of the industry. Better to have disappointed users, CIOs reasoned, than headlines in The Wall Street Journal.

But the rise of service-oriented architecture has produced a shift in integration strategy. SOA makes the radical assertion that the enterprise application infrastructure is irrelevant. Technology is constructed according to services specified by the business, not by processes contained within an enterprise application vendor’s software box. In this scenario, packaged software is a piece of the service, just another component in a larger business process—such as an insurance claims process that links a jumble of functions and data inside ERP, CRM and old mainframe legacy systems. The application’s vendor doesn’t matter anymore; the linkages between the applications is the important thing.

As a result, the vendors’ integration strategies have become more important than the features of their software. (Both dominant enterprise software vendors, Oracle and SAP, have begun offering integration middleware to go along with their software suites, although both are sticking with the big, integrated software suite vision.)

In the brave new world of SOA, the big software vendors have decided to take a page from Microsoft’s playbook and duplicate the Windows strategy. With the Windows operating system running on 95 percent of PCs, software developers are eager to create software that works with Windows because it means they can reach the most customers and make the most money. As a result, the thousands of applications available for Windows today ensure its dominance in the operating system market tomorrow. Similarly, the big enterprise software vendors are trying to ensure their futures in an SOA world by assembling ecosystems around their core applications.

For example, the most startling change in strategy comes from SAP, long the dominant player in ERP. For years, SAP resisted alliances with other software vendors and insisted on building its own applications. But post-SOA, SAP is busy service-enabling its applications and using its new middleware software, NetWeaver, to entice companies to build software to run on the NetWeaver platform (which incorporates Web services standards). Online CRM software provider Salesforce.com has created AppExchange, where developers can download free software to integrate their software add-ons with Salesforce’s core software. Oracle, meanwhile, has been busy building its platform through acquisitions, including middleware software that is the linchpin for its SOA pitch.

With CIOs reluctant to upgrade to new versions of enterprise software, the big vendors are saying, "Look, we can’t sell with our old value proposition anymore," says Gartner’s Sholler. "So they’re trying to make [their software] the foundation for other solutions in markets they haven’t been able to reach."

But this strategy has put the enterprise application companies on a collision course with traditional middleware providers such as BEA, IBM and WebMethods, which are coming to the SOA party from the bottom up, through the integration infrastructure layer. "Everybody is winding up tangled up in the same space," says Sholler.

Although the integration infrastructure companies have much more experience with the foundational elements of SOA, all vendors are looking to build long-term relationships with customers. Consequently, despite the abundance of Web services standards embedded in their products to ease integration headaches, everybody has a proprietary hook somewhere. Oracle’s Fusion applications will work only with Oracle’s database. SAP’s new applications require NetWeaver middleware, according to Gartner and Forrester Research. Even the integration infrastructure companies have enough proprietary elements to make it difficult to swap out their integration software.

The bottom line for CIOs? Beware vendors pledging to build your SOA for you. Unless, like Whirlpool’s Sezer, you’re not worried about dependence on your vendor, which in Sezer’s case happens to be SAP. "What’s wrong with being dependent on a vendor as long as I’m providing value to my company with the solution?" he asks.

But CIOs on the whole fear dependency, especially in the current wave of consolidation, according to a 2005 Accenture survey of CIOs. While 65 percent of CIOs said vendor consolidation makes for a more integrated software infrastructure, and 61 percent believe it will reduce their vendor management burden, 87 percent said vendor consolidation will lead to lock-in, 61 percent believe it will decrease price competition, and 57 percent believe it will reduce pressures for vendors to innovate. Only 35 percent saw vendor consolidation as a good thing.

For SOA believers like Transamerica’s Gleason, annuity products and services division, an independent SOA controlled by the CIO is one of the best protections against lock-in. "No one vendor can be all things to everyone," he says. "There’s always going to be somebody out there who will be able to do a piece of your process better than anybody else can. And the first company to adopt that is going to have competitive advantage."

Copyright © 2006 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Security vs. innovation: IT's trickiest balancing act