Pulling Together an
SOA Strategy

SOA is the most important concept yet for building business and IT alignment. But it requires a clear strategy — because it will change IT forever.

By Galen Gruman

The concept of service-oriented architecture has gained real steam among CIOs in the past year, promising a way to more quickly build and adapt software functionality to deliver new, more flexible business processes.

A November 2005 Yankee Group Research Inc. survey of 306 U.S. organizations found that all had started or planned to start SOA initiatives within two years. Using an SOA lets you "craft enterprise-like functional-IT across hundreds of moving parts," says John Halamka, CIO at CareGroup Healthcare System in Boston.

Properly deployed, SOA puts business processes — rather than software — in the driver's seat. By piecing together functionality and data from almost any application and orchestrating them to help automate a business process, IT can break the boundaries imposed by many mainframe and enterprise applications. The SOA approach also encourages reuse of these services, reducing development efforts over time and ensuring greater consistency across processes.

For example, Boston-based research firm Aberdeen Group Inc. predicts that a fully implemented SOA will reduce development costs by 25%, or about $53 billion over five years, across the 2,000 largest firms worldwide. The Guardian Life Insurance Company of America in New York has seen a 30% drop in such costs, says Jaime Sguerra, chief architect.

But SOA means dramatic change for most IT departments. The skills required include expertise in object-oriented development, business analysis and complex service orchestration. Get busy finding these people: By 2008, 80% of development projects will be based on the SOA model, Gartner Inc. predicted in a March 2005 report.

Though by no means easy, SOA is the most important blueprint yet devised for achieving business and IT alignment. It can help IT move from being just a cost center and technology provider to becoming the key enabler of critical business processes.

Leading Change

A December 2005 Aberdeen Group study of 284 companies shows that CIOs lead SOA efforts 40% of the time. Even though SOA promises clearer business benefits than traditional technology efforts, business managers lead SOA efforts just 18% of the time. CIOs have the advantage of both managing the IT staff that implements the SOA and of being neutral in business-unit turf battles.

“Our real challenge was getting our 76 agencies to share,” says Suzanne Peck, chief technology officer of the District of Columbia, which in a five-year SOA effort has collapsed 370 applications into nine sets of cross-agency business services. SOA gives CIOs the strategy they need for bringing speed, flexibility and innovation to business processes.

CIOs routinely hear complaints from business management about how inflexible and costly the IT infrastructure is, and how long it takes to deploy applications. SOA forces IT to understand business issues so it can develop services that address real business requirements. That requires a closer partnership between IT and business staffs, making the business analyst role in IT a key one. SOA forces the business and IT to take a common design and development approach, so it’s no surprise that Aberdeen Group’s survey showed that half of large companies cite “alignment with the business” as the top factor that drove them to initiate or implement SOA. This factor was closely followed by “managing IT complexity,” cited by 49% of large companies.

This tight coupling between IT and business puts the CIO at the nexus between the two groups, in a position that requires deep business understanding and an ability to lead IT efforts that deliver on the business needs. Because services reflect actual business processes, business managers will be able to measure a CIO’s effectiveness on aligning IT to business values, something that’s difficult to do with traditional IT projects. “It’s a great way to unify the organization,” says Scott Metzger, CIO at San Luis Obispo, Calif.-based TrueCredit, a subsidiary of credit reporting agency Trans Union LLC.

But that value may not be apparent right away. SOA requires a retooled IT infrastructure, and the first applications delivered will largely execute existing business processes. But the benefits should soon become apparent, as IT adapts the services more quickly to changing business needs and builds entirely new services.

“The marginal cost for putting on the next Web service is zero,” says Guido Sacchi, CIO and executive director of shared services at Atlanta-based CompuCredit Corp.

Not Just a Project

Because SOA is an architecture, not a specific technology or product, CIOs should not promise to deploy “an SOA.” Instead, they should promise to deliver business-critical services using the SOA model. A complete SOA effort can take five or more years to deploy. Fortunately, SOA’s approach of breaking applications into discrete services means an SOA effort can be incremental, gradually replacing traditional applications.

“It’s a long-term journey” to a truly different way of delivering business processes, says Judith Hurwitz, president of Hurwitz & Associates, an IT consultancy in Waltham, Mass.

The SOA approach and its supporting technologies allow greater interplay among existing and new applications but also require a new kind of application development. Services require extra work to create the interface that links the service with others and describes what the service does in business and technical terms and how other systems access it. “A good service knows who it is, can describe itself to others and show who wants to connect to it,” says Jeff Gleason, director of IT strategies for the financial markets group at Transamerica Life Insurance and Annuity. “The essence of service-style integration is that the interface is intelligent and communicative.”

Creating and deploying services within an SOA also requires a different type of talent. The IT team must include services and data architects, developers who understand object orientation, business analysts, developers familiar with the inner workings of existing systems, experts in distributed systems development and management, and staffers familiar with Web-oriented tools and standards. “It’s not easy to find people able to build these types of architectures,” warns Sacchi.

And then the CIO needs to ensure that everyone follows the architecture. “SOA isn’t a technology; it’s a framework, a blueprint, and if you don’t have control over it and aren’t guaranteeing that it’s being applied across the organization, you’ll never have a true SOA. There are probably a million ways to architect an integration layer, but you can’t have a thousand different ways inside your company,” says Rick Sweeney, chief architect at Blue Cross and Blue Shield of Massachusetts.

When Shadman Zafar, senior vice president for architecture and e-services at Verizon Communications Inc., began developing a services catalog in 2001, many developers promised to follow the SOA and reuse components — but they didn’t. “We had to stop some projects,” he recalls. “People learned that they had to reuse the enterprise assets.”

Technology Is Young

As promising as SOA is as a concept, the enabling technologies remain immature. So some initial SOA efforts won’t scale to handle the number of services that a fully deployed SOA would have in a large enterprise. Because an SOA breaks applications into components that can be mixed and matched in multiple ways, managing those interactions and keeping track of the services and their business and data logic can be difficult.

One challenge caused by this complexity is that of master data management. In an SOA, data can be used by different services, which may or may not understand the data’s meaning and context in the same way.

“The more you distribute the data, the more likely it is that there will be problems,” says Song Park, director of pricing and availability technology at Starwood Hotels & Resorts Worldwide Inc. The result could be what Don DePalma, president of Common Sense Advisory Inc. in Lowell, Mass., calls “frankendata,” which calls into question the accuracy of the results generated by the services and applications. Once you get over the thrill of the first services, you will discover the pain of data management “when you put together your first three- or four-way data service,” says DePalma.

“There’s always a context to data. Even when a field is blank, different applications impose different assumptions about what that means,” says Ronald Schmelzer, an analyst at ZapThink LLC, a Waltham, Mass.-based research firm. The solution is to treat data logic as you would business logic in an SOA: as separate services that don’t hide context or assumptions from the business services.

“Think about the processes that affect the master data wherever it lives,” advises Henry Morris, an analyst at research firm IDC. For example, the business logic that looks up a customer’s order status should rely on a separate data service to match the customer ID across the databases and applications that provide individual results — such as order date, order amount, product description and ship-ping status — to that business logic.

As IT creates more services, it becomes harder to keep track of which services are available and what each one does. That can lead to the repeated creation of the same services, eliminating the reuse advantage of SOA, as well as threatening the benefit of having common services for common tasks. At the least, you need an architectural review group that looks at proposed services to see if they might already exist or can be adapted from what already exists. At best, the CIO should create a services repository or registry that develop-ers (and business requesters) can access, though the current technology for this is not yet well developed. “We knew at 15 components that we’d need a registry,” says Edmund Vazquez, Web services program manager at Sprint Business Services, a unit of Sprint Nextel Corp. Sprint’s registry lets business and IT staffers see if a needed service already exists, or if there’s a similar one that can be used to develop a new service.

Incremental Approach

The transition to an SOA should be just that, a transition, not a big bang. In the early phases of implementing an SOA, it makes the most sense to choose projects that provide the greatest financial impact and thus generate support for further IT investment to enable the use of more services.

Once you’ve picked the initial target, it’s usually best to focus on related services for the next stage, so the developers can understand their interactions and divide the constituent services appropriately. The next step is to move into different business domains in the same incremental fashion.

“One of the nice things about SOA adoption is that adoption, implementation and deployments can be incremental as long as you keep your eye on the bigger picture,” says Vazquez.

But achieving the promise of SOA requires a firm commitment from the CIO — with support from the rest of the business — to think differently. Otherwise, SOA investments will simply be this decade’s IT fad, creating many projects with no lasting impact. If an SOA’s focus becomes specific technologies — rather than the architecture — IT has missed the point, says Praveen Sharabu, director enterprise architecture at Con-Way Transportation Services Inc., a trucking company based in Ann Arbor, Mich. “Companies tend to look for a Holy Grail. But this is really about building a solid foundation,” he says.

Galen Gruman is principal of The Zango Group in San Francisco and a regular contributor to CIO magazine. Contact him at ggruman@zangogroup.com.