by Carrie Mathews

SOA Transformation: New Roles, New Processes for SOA

Oct 01, 20065 mins

CIOs are also beginning to realize that SOA is not just a project with a start and an end date.

Around the CIO water cooler, service-oriented architecture, or SOA, still has all the buzz. The idea of creating reusable service components and deploying them in applications across the enterprise is irresistible. But CIOs are also beginning to realize that SOA is not just a project with a start and an end date. “The goal of an SOA project is not to get the first implementation done and then go back to business as usual,” says Richard Thomas, senior VP and CTO at Quintiles Transnational, a pharmaceutical, health-care and biotech research company. “This is a whole new way of doing business.” (For more answers to your SOA questions, see The Truth About SOA.)

Members of the CIO Executive Council met recently in Chicago to discuss how to prepare for this new way of doing business. They shared their experiences in the areas of planning, cultural change, organizational structure and metrics.

Start With a Business (Process) Plan

The National Association of State Chief Information Officers (NASCIO) published a May 2006 research brief outlining ways that states can take advantage of SOA. A key NASCIO recommendation is not to rush into building an SOA without a transition plan and a defined business case. Drew Mashburn, chief enterprise architect for the state of Arkansas, contributed to the NASCIO research brief and currently is setting a strategic direction for SOA in his state. Right now, there are approximately 130 state agencies, boards and commissions in Arkansas, many with their own custom-built or purchased applications. “Moving to SOA will definitely be a huge cultural shift,” says Mashburn. “It’s critical to have strong support from agency leadership, the governor and the state legislature.”

SOA’s New Math

When he looks at his IT dashboard, Ken Yerves, CIO and senior VP at JM Family Enterprises (Southeast Toyota is a unit of JM), no longer sees a category for “application availability.” Instead, the dashboard displays the number of minutes that a service is meeting an agreed-upon level. When any process falls below that level, the dial goes to red and begins showing how long the service is out of whack. Once the issue is resolved, it returns to green and the timer resets. For more on SOA metrics, read Finding the Best Metrics for SOA

To gain that support, Arkansas Executive CIO Doug Elkins and his workgroup are in the early phases of establishing a strategic plan that will identify common business processes across agencies, identify potential areas for interoperability and application reuse, and specify cost savings and other efficiencies. The plan will articulate the two most important benefits that SOA is expected to bring: cost savings and increased collaboration between agencies.

Calculate the Cultural Change

Approaching SOA as a change management challenge will help CIOs prepare for the cultural issues that invariably will arise in such fundamental areas as application and resource ownership. Neal Shaw, chief architect at H&R Block, admits that he “underestimated the amount of cultural change that would be required.” For instance, one of Shaw⬔s application teams built a service for a specific application. Other development teams decided to use the new service for their own projects but failed to inform the original builders. Consequently, when an update was made to the new service, the other applications that had incorporated it broke. Developers must now think about who “owns” which service and what updates might be forthcoming.

To create this shift in mind-set, Rick Sweeney, chief architect at health insurer Blue Cross Blue Shield of Massachusetts, encourages his staff to think differently about business user requests. For example, when a user asks for enrollment data, his staff doesn⬔t treat it as an information request and then think about how to craft an application to fulfill it; they consider it an “enrollment service” request, which prompts discussion about potentially reusable components. This change may seem purely semantic, but the new kind of thinking it generates is very important to SOA success.

Create IT-Business Relationship Roles

Organizing for SOA can also lead to changes in the structure of the IT staff. Thomas at Quintiles Transnational created a new position called business relationship manager. “I want these people to look at the entire business line and make sure that it⬔s consistent with what IT is doing with SOA. They are our single point of contact,” says Thomas. When Quintiles works on an implementation with a process or service component that could have high value within or across business lines, the business relationship manager takes ownership of that implementation.  

CIO and Senior VP Ken Yerves of JM Family Enterprises, an automotive holding company, agrees that staff realignment may be needed to adopt SOA successfully. He created a new position, client advocate, at the same time that his company was moving to SOA. About 20 client advocates staff four project management offices and are subject-matter experts for those specific business processes. With this expertise, they can identify potential process changes to improve the business environment, and are responsible for analyzing business and user technology needs, including how best to apply reusable service components. “The business tells me that these client advocates actually know how the business works better than they do,” says Yerves.

The training needed for these new IT-business expert roles should not be underestimated, particularly in nontechnical areas like general business strategy, business processes and service delivery. “I have actually doubled my training expenses year-on-year since we started our SOA implementation three years ago,” Yerves says. “And it hasn⬔t been for pure technical training.”