The term service-oriented architecture (SOA) hadn\u2019t gained currency in 2002 when TrueCredit, a subsidiary of the TransUnion credit verification agency, began deployment of an enterprisewide portal. CIO Scott Metzger\u2019s 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.\n\nBut Metzger soon realized that the effort was about more than this one application; it was an excellent excuse to begin mapping out the company\u2019s 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\u2019s relationship with the business. "[We have] a much closer relationship with business [now]. It\u2019s a great way to unify the organization," he says. A March 2006 survey by 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\u2019s 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\u2019s various services\u2014including credit processing, payments management and credit monitoring\u2014both 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 an SOA infrastructure, but it won\u2019t 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 an SOA deliver on its promise of true IT-business alignment. But it also introduces new challenges for CIOs\u2014challenges that stretch IT\u2019s abilities in areas that have been chronically underdeveloped: process and architectural planning. Their staffs will also be stretched. In short, CIOs who expect that they can do SOA the same way they\u2019ve always done technology implementations risk being blindsided.Challenge 1: Deploy in Pieces But Create a Long-Term PlanAn SOA involves years of effort to get its ultimate result. That\u2019s why respondents to the CIO\/Computerworld survey cited the challenge of shifting to an 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 (a sister company to CIO\u2019s publisher). 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\u2019t build anything. "How you\u2019re going to manage version 2 [of your services] and beyond is important to think through up front," says Metzger. "It\u2019s important to understand how volatile a particular business process is."Any organization implementing an 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\u2019s 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\u2019s 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 SeriouslyBecause 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\u2014which 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\u2019 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 SAP 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\u2019s Rogers.Challenge 3: Rethink Your Talent PoolIn addition to architecture staff that develop and manage the SOA\u2019s big picture, the CIO will need a development staff that is comfortable with both business processes and the services approach to developing applications. And business experts who can partner with IT on process identification and implementation are also critical\u2014the CIO\u2019s organization can\u2019t do it all."Retraining, hiring and redeploying are all needed," says Rogers, so most CIOs will bring in some key hires experienced with SOA and retrain the existing staff in SOA-oriented thinking. "It\u2019s an ongoing process, so start out small and do a lot of retraining," says TrueCredit\u2019s Metzger.Challenge 4: Apply SOA Principles to Your Data TooOften overlooked in initial SOA efforts is the importance of treating data\u2014not just application functionality\u2014as a service, says ZapThink\u2019s Schmelzer. In an SOA, multiple services residing in multiple applications might combine to execute a business process. If each service uses different data sources, or even the same data source in different ways, the results might not be what you expect, he says.For example, Metzger enforces strict separation between services that access and store data and those that act on the data, such as performing calculations. He also keeps presentation services\u2014those that format the data for the user or for reports\u2014separate from other services. This helps ensure that all services have the same context for a specific piece of data. The Payoff: Real Business-IT AlignmentAll of these challenges underscore how different SOA is from traditional enterprise technology efforts. The CIO must put the technologist hat to the side and become an advocate for business processes. Better knowledge of those processes leads to better technology design, which reduces the cost of maintaining existing systems\u2014something that now accounts for 70 percent to 80 percent of IT budgets, says Schmelzer."We\u2019ve been talking for years about IT-business alignment," says IDC\u2019s Rogers. An SOA lets you actually achieve that goal\u2014if you can develop the architectural vision and execute on it over the long term. The process is not easy, but early adopters like Peck, Metzger and Stubbs would never go back to the traditional IT approach. "A lot of [D.C.] government would not work without SOA," says Peck.