SOA Success? Focus on Process and Architecture

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 enterprisewide 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 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 an 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 an 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. Their staffs 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

An 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 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’s 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’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 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’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 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’s Rogers.

Challenge 3: Rethink Your Talent Pool

In addition to architecture staff that develop and manage the SOA’s 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—the CIO’s organization can’t 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’s an ongoing process, so start out small and do a lot of retraining,” says TrueCredit’s Metzger.

Challenge 4: Apply SOA Principles to Your Data Too

Often overlooked in initial SOA efforts is the importance of treating data—not just application functionality—as a service, says ZapThink’s 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—those that format the data for the user or for reports—separate from other services. This helps ensure that all services have the same context for a specific piece of data.

The Payoff: Real Business-IT Alignment

All 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—something that now accounts for 70 percent to

80 percent of IT budgets, says Schmelzer.

“We’ve been talking for years about IT-business alignment,” says IDC’s Rogers. An SOA lets you actually achieve that goal—if 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.