Four tips for making SOA about the business
By Jon Brodkin, NetworkWorld
October 22, 2007 — Building a service-oriented architecture requires great technical skill, but don't forgot that SOA technology first and foremost is about business processes and agility. Following these four tips will help you keep business goals front and center in your SOA planning and development.
1. Prioritize project phases by user benefit, not technology implementation
Your SOA implementation will require plenty of technology upgrades, but a good project can solve some tactical business problems before it addresses the back-end infrastructure, says Keith Sievers, CIO at Kemper Auto and Home Insurance in Jacksonville, Fla.
At Kemper, Sievers led an SOA project to replace policy applications that date to the 1980s. He began by revamping services for price-quoting, error-handling and credit-card payment processing; that meant addressing certain infrastructure upgrades right away, such as those for data modeling. He was able to put off behind-the-scenes services -- such as batch processing, which takes care of renewals, he says. "Try to front-load your project with things that are more important to users. To them, [your four-year SOA project] looks like a two-year project," he adds.
Figuring out which pieces of an SOA project will have the biggest business benefits requires user involvement in planning and ongoing decision making, experts say. "At some organizations, IT defines the business processes," says Bart Perkins, a former CIO of Dole Foods and Yum Brands who founded Leverage Partners, an IT consulting firm. "But users don't necessarily always buy into IT's definition. And that does create a problem."
2. Don't overwhelm users with SOA jargon
As sets of initials go, SOA is bound to confuse users, who want to know how IT projects will benefit the business and not how you're going to make that happen, some experts say.
IT executives should "banish the phrase SOA" from their vocabularies, says James Kobielus, principal analyst for data management at Current Analysis. "It obscures more than it elucidates from a business standpoint. Even technical folks can't agree what [SOA] means," he says. The acronym SOA comes off as a little too technical and is beginning to suffer from backlash, agrees David O'Connell, a Nucleus Research analyst, who recommends using the word only with "SOA sophisticates."
Some experts don't see the issue as this black and white. Business users will understand the phrase if it is explained well enough, says Mike West, vice president and senior strategy consultant at Saugatuck Technology. "They've all learned what a disk is, what a file is. Why can't they learn what SOA is? Of course, they can; it's just how you present it to them."
Kemper's Sievers agrees. Using the term SOA with business colleagues hasn't been an issue for him, because he focuses the discussion mostly on such business metrics as time to market and cost-cutting, he says.
3. Seek out places where SOA can automate manual processes
Talk to users about their principal gripes and wish lists, then figure out which problems are caused by incompatibility among systems. For example, you might find users are meeting a particular business need by moving data manually from one database to another, or from a CRM to an ERP system, O'Connell says. This is clearly a technology problem, and solving it would make a good SOA project.
Finding which problems have their roots in technology is just the starting point, however. Next you've got to figure out which of a problem's possible solutions can be replicated throughout the enterprise, O'Connell says. You don't want to undertake a project that would help three insurance company managers when another would benefit 500 underwriters. "Make sure you pursue projects that generate a high ROI, because they let a business unit do something that previous technology kept it from doing," he adds.
4. Transform governance in the light of the new services orientation
As sets of initials go, SOA is bound to confuse users, who want to know how IT projects will benefit the business and not how you're going to make that happen, some experts say.
Enterprises often are loath to formalize governance, but this is one of the most crucial tasks within an SOA project. Because services -- and expenses -- probably will be shared among departments, SOA governance needs to examine how an organization initiates and funds projects, Saugatuck Technology's West says. An enterprise needs processes to decide, for example, which departments be billed for which services, and whether to alter a service when one department wants a change and another does not, adds Ashish Mohindroo, an Oracle product director. Oracle offers SOA governance tools to help businesses manage service changes and service-level agreements and perform tasks related to managing metadata repositories and SOA applications.
West recommends having a center of excellence, an IT executive steering committee that includes business users, an architectural review board and a chief SOA architect. "For SOA to be business driven and reach business goals, it will require a transformation of various elements of IT governance . . . including the management of assets, and acquisition policies for software and hardware," he says. "All of this has to be redefined through the lens of business-driven SOA."