SOA Governance: How to Manage Development and Use of Services

Mike Bartell, CIO of the Federal Deposit Insurance Corp. (FDIC), knew he was facing a project that could make or break his career. It was a transformation of the way the federal government tracks cash flow among U.S. banks and monitors financial reports and compliance statistics, to ensure the U.S. monetary system remains in good health. The three agencies involved—the FDIC, Federal Reserve Board and Office of the Comptroller of the Currency—had multiple systems to handle the different processes, glued together over the years in what was an increasingly inflexible system.

The challenge: Re-architect those systems into a more flexible whole based on reusable, consistent components in a service-oriented architecture (SOA). The project, which began in 2003 and is continuing, strives for the kind of business value and technical sophistication that wins awards—like the CIO 100.

But with ambition comes risk. SOA’s aspirations of more efficient software development and more agile business execution can’t be fulfilled unless you manage the architecture, the development processes and deployment properly through IT governance practices. “Governance was seen as essential from the beginning,” says Bartell. To ensure cooperation and coordination, the three agencies—which operate under a coordinating body called the Federal Financial Institutions Examination Council (FFIEC)—created a written agreement, signed by all the agency heads, which stipulated a single set of governance components. “The governance [document] served us well in helping us all reach common ground on key decisions quickly and keeping the business functions and outcome goals clearly defined throughout,” adds Bartell.

The stakes for good SOA governance are much higher than in traditional software development, because SOA links development directly to business operations. Under SOA, software components represent specific business activities (“credit check,” for example, or “find customer record”) that can be mixed and matched into business processes and workflows. Good SOA governance means thinking through all the implications of such interactivity and creating a process for managing the components. A badly managed software architecture will ultimately translate to a badly managed business in the SOA era. “Governance in SOA is important because we’re codifying business services,” notes Judith Hurwitz, president of consultancy Hurwitz & Associates. “It is both a business transformation and an IT transformation.” CIOs hoping to succeed with SOA need to put together a plan for governance even before their developers release the first service to the company, because those services will play a crucial role in determining the future course of the most important business processes of the company. Not looking ahead invites a continuation of the complexity and lack of agility that plagues IT-supported business processes today.

Most early SOA adopters, including five of this year’s CIO 100 honorees, understand the value of governance, but they also realize that they won’t have all the answers to governance issues up front—and that’s OK. “It doesn’t have to be tremendous progress, as long as it’s steady,” Bartell says. What’s more important, he adds, is that he has established a single SOA governance strategy for the organization for the future. “All capital projects going forward are under SOA, as well as any end-of-life systems,” he says.

Governance Begins with Process

Most SOA efforts start with the same governance approach: A joint business-IT group is formed to understand the key business processes, create the services that deliver them and enforce the proper use of the underlying architecture. All five CIO 100 honorees involved with SOA efforts—the FFIEC, Hygeia, ING Group, KnowledgeBase Marketing and MoneyGram International—imposed that type of governance at the very beginning.

In the project that garnered its CIO 100 honor, the FFIEC deployed several services for accepting and managing the quarterly financial statements of all FDIC-insured institutions, termed “call reports.” This information is shared and analyzed by the three FFIEC agencies, all of which have different systems with different business processes and data standards. By working jointly, these agencies are defining common business processes such as managing reported financial statement information. The agencies build composite applications from these services that all can share, which reduces duplicative and conflicting application efforts, as well as analysis errors across the organizations. And by having a central architectural review board, they can ensure that all new and redeveloped applications conform to the SOA.

Financial services provider ING Group took the same approach in its CIO 100–winning effort. A centralized architectural group helps identify common, shareable processes among its six lines of business, part of a consolidation effort among its many business units, notes Michael Vincent, general manager of corporate operations and information services. Once the business processes are identified, IT develops services to execute them consistently in all business units. “We have a strong reusability drive,” says Vincent. “The idea is to create building blocks.”

For example, ING found that it could use common services for about 70 percent of its European mortgage-processing application components, saving about $20 million in future development costs. (The other application components are country-specific, but the SOA approach lets them interact with the common services.)

The goal of SOA governance isn’t merely efficiency and reuse, however; it can also be a powerful tool for business process improvement. At CIO 100 honoree Money¿Gram, a payments processor, Executive VP and CIO David Albright has created an architectural review board that seeks processes that are candidates for the SOA. If the group finds several variants of an important process inside different areas of the company, it will service-enable the one agreed to be the best so that the entire company benefits from the best practice. MoneyGram’s first SOA-based component is a reusable service that initiates payment transfers. The service integrates with Money¿Gram’s CIO 100–winning project, called AgentConnect, that lets independent agents initiate various payment services managed through MoneyGram’s payments engine, with a more modular set of applications that allow easier deployment and simpler integration with agents’ point-of-sale systems.

Repository: Shopping for Services

A related governance step for SOA is to create a repository for the components developed so that you can track and control usage. The FDIC has been using a repository for its pre-SOA software components, so Bartell and his FFIEC colleagues know the value of such a system for IT governance. But they also know they don’t yet understand what capabilities a repository will need in the new SOA world. “We haven’t filled in the plan, but when we get more mature, we’ll build that repository,” he says.

At Hygeia, a health-care transaction service provider, CIO Rod Hamilton has begun using wikis, the editable online bulletin boards, to help developers and business analysts track the services available. (The company earned CIO 100 honors for its efforts to create standard, reusable services for its key business processes, such as user validation, document routing and workflow management.) Each wiki contains information on one or more services, which IT and business staff can all easily see and modify, with changes automatically tracked. It’s a quick-and-dirty approach, similar to using Excel for rudimentary databases, but this simple technology works because his organization is small—with a total IT staff of 15. Hamilton knows he’ll need a repository as Hygeia develops more and more common services to implement the standard business processes that handle client transaction data in its multiple forms, as well as for specialty services that handle unique client needs.

For all these CIO 100 honorees, the focus on architectural and development rigor is critical: “For successful SOA, 80 percent of the effort is changing the way your organization manages the process of the application development lifecycle,” notes Dennis Gaughan, research director for IT governance and SOA at AMR Research.

Data and Security Matter

Data management is another key governance issue in SOA. It’s important to capture and communicate a standardized context for shared data across the organization so that the data is used as intended. Data integrity and consistency are critical for CIO 100 honoree KnowledgeBase Marketing, since its business is about managing, merging, filtering and qualifying customer lists. KnowledgeBase has multiple systems for handling data inside the company, and they all perform the same basic functions—data cleansing, list management, consumer matching and data analysis—in slightly different ways, which prevents the company from efficiently combining and analyzing different marketing data for each client’s specific project needs. So, in a CIO 100–winning project, the company has replaced the multiple data-cleansing systems with a single core service delivered through an SOA. Now, every business department applies the same cleansing service to all consumer data, ensuring consistent results. And the service orientation means that as the company develops other cleansing, management, matching and analysis functions, all business departments will get consistent results in what they deliver to clients (who may work with more than one business department), says Brian Camp, senior VP of infrastructure.

SOA cannot emphasize homogeneity at the expense of business performance, however. One of the most important functions of SOA governance is to determine the specific aspects of software components that should not be shared. For example, a software component that performs a credit check may be applicable in many business processes, but those processes may all require different levels of security. Therefore, security has to be thought through in all possible usage scenarios, not just within the context of an individual software project.

For example, at Hygeia, in order to deal with HIPAA rules that require strict monitoring and access control to medical data, Hamilton stores access privileges to the data in databases that are separate from the service software components. Before giving users access to data, the service calls the database to verify access privileges. If the user doesn’t have the right privileges, he can’t access that data or run that service.

Governance Is Gradual

While analysts such as Gaughan and Hurwitz say that tackling governance issues early is the best policy, they know that most organizations cannot afford to wait on SOA until they define governance fully. “It would be nice to define [governance] up front, but that would make the investment hard to swallow,” says AMR’s Gaughan. Instead, SOA pioneers are tackling the critical cultural and political issues around defining the right business processes and then retraining their IT staffs—and the business groups—to design sharable, reusable and extensible services that both save money and allow for more rapid development of new business functions. Governance will come along the way.

The CIO 100 honorees exemplify that reality. Like his fellow honorees, Money¿Gram’s Albright knows what the governance issues are in SOA, but he’s gambling that he can develop them as the basic SOA principles of process design and service development take root in business and IT. Getting the basics right will give him the buy-in he needs to invest the people and resources to figure out the other governance issues. KnowledgeBase’s Camp has a similar view. “We’ll take a deeper dive when we add more services,” he says.

That leap of faith is scary, but necessary, says Hurwitz. “Being timid is not a good thing—people do need to get started now on the processes, understand the stages and develop a road map.”