To gain the business IT alignment promised by service-oriented architecture, CIOs have to focus on process and architecture - not just technology.

The term service-oriented architecture (SOA) hadn't gained currency in 2002 when TrueCredit, a subsidiary of the TransUnion credit verification agency, began deployment of an enterprise-wide portal. CIO Scott Metzger's goals were simple: Identify the business processes and the IT functions to be delivered through the portal, and reuse software wherever possible to reduce development cost and speed deployment.

But Metzger soon realized that the effort was about more than this one application; it was an excellent excuse to begin mapping out the company's most important business processes to create an architecture that would let IT develop and modify the supporting applications easily as business needs changed. Call it SOA or whatever you want, says Metzger, but for him, the shift in thought that began with the portal application was a turning point in IT's relationship with the business. "[We have] a much closer relationship with business [now]. It's a great way to unify the organization," he says. A March 2006 survey by US CIO and Computerworld shows that 77 percent of enterprises adopting SOA seek greater business flexibility.

In his eureka moment, Metzger also realized a key strategy that has guided his SOA effort ever since: "It's not a technology road map but a business plan. Find a way to articulate the actual business process independent of any technology. That will best protect your SOA investment in the long term." Since 2002, Metzger has built a common portal and services manager to deliver the company's various services - including credit processing, payments management and credit monitoring - both internally and to external customers.

The importance of process in SOA means CIOs should be addressing architectural issues at the same time that they consider purchasing or implementing SOA infrastructure, says Ron Schmelzer, a senior analyst at SOA research firm ZapThink. "You can purchase a SOA infrastructure, but it won't be as useful as it can be unless an architectural plan driven by business process is in place," he adds.

That focus on process rather than on specific technology is what lets a SOA deliver on its promise of true IT-business alignment. But it also introduces new challenges for CIOs - challenges that stretch IT's abilities in areas that have been chronically underdeveloped: process and architectural planning. IT staff will also be stretched. In short, CIOs who expect that they can do SOA the same way they've always done technology implementations risk being blindsided.

CHALLENGE 1:

Deploy in Pieces but Create a Long-Term Plan

A SOA involves years of effort to get its ultimate result. That's why respondents to the CIO/Computerworld survey cited the challenge of shifting to a SOA architecture while meeting current business needs as the top concern (63 percent).

The trick is to not deploy SOA all at once, because by the time most "big-bang" efforts are completed, the business needs may have changed and much of the implementation will be outdated, says Sandra Rogers, program director for SOA, Web services and integration at research company IDC (US). Instead, create the architecture and deploy specific services in phases, perhaps by focusing on one application domain at a time or choosing projects based on business urgency. "You can build incrementally," says Suzanne Peck, CTO of the District of Columbia. In 1999, Peck began reorganizing 370 legacy systems into nine functional groupings in preparation for a new SOA. The services include both new code and Web-services-based interfaces to legacy code, as well as new composite applications.

But until you develop the underlying architecture, you can't build anything. "How you're going to manage version 2 [of your services] and beyond is important to think through up front," says Metzger. "It's important to understand how volatile a particular business process is."

Any organization implementing a SOA should create a basic architectural model for a manageable piece of the business, and then apply that model opportunistically to individual projects, using them both to test the model and to deploy the SOA in pieces, says ZapThink's Schmelzer. That architecture includes identifying all of the business processes, the interactions among them, the specific applications and functions (existing and needed) to deploy them, and the flow of business logic and data to execute the business processes. Identifying these pieces lets you understand common functions that can be standardized across all processes, as well as identify the compliance, security and management requirements.

Be prepared to spend up to a year doing the initial business process and architectural analysis, advises TrueCredit's Metzger. But that extra time spent up front will pay off exponentially, he says. Today, new services at TrueCredit have only a six-week development cycle. At the District of Columbia, some services are delivered in as little as 12 weeks (more complex ones take four to six months).

CHALLENGE 2:

Take Governance Seriously

Because SOA is ultimately about creating and managing IT processes in support of business processes, governance is critical. "Development organizations are used to building applications, but now they are assembling parts," says Dennis Gaughan, research director for IT governance at AMR Research. And that development has to be done in a standard way - which can rub developers the wrong way. "SOA takes a lot of the control away [from individual developers], so you get resistance," says John Stubbs, CIO at Sony Pictures Entertainment, the distribution arm of Sony. Sony Pictures' SOA efforts have resulted in a common service for managing the licensing rights of movies and TV shows across several lines of business (including DVD sales and theatrical releases) affecting 39 business units (including legal and marketing). The IT group is now using the SOA to deploy common Web services for its financials processes like accounts receivable.

A way to enforce the SOA principle of reuse is to have a review board that evaluates new applications to ensure they are really needed. Sony Pictures and TrueCredit both use such a board. The review board should include the CIO or CTO, chief architect, key technology and process experts from IT, and key business analysts, says IDC's Rogers.