"Our business model has changed over the years, and our technology has not kept pace with that. Our business requires the ability to bring new products to market quickly, robustly, and cost-effectively. Traditional development methods and monolithic applications can't provide that," Stuart says.

Great American is three years into the five-year project and has built out more than 100 services so far. "Our strategy is to move to an 'application assembly' mode. By creating a palate of reusable services, we feel we can compose a large set of business solutions quickly from a common set of components. That gives us flexibility as well as increased reliability because we're reusing tested components," says Stuart.

But as with any insurer building out its SOA, Great American realizes it must take care it does not simply swap one type of complexity–the rigidity of legacy systems–for another. Without proper planning, SOA can devolve into the ineffective and difficult-to-manage environment of JABOWS, or "just a bunch of Web services."

"SOA brings flexibility and agility to the business, but it's an inverse relationship to the developer community," Stuart explains. "To get that agility, we have to drive hard for standard components, and that means we need to be more disciplined in our governance."

NOT SO FAST

In fact, despite SOA's value proposition, it remains what Anne Thomas Manes, vice president and research director at Burton Group, calls a "very risky endeavor." As she points out, "You are doing this to increase agility, and if you end up with systems that are actually more brittle, it's a failure."

The potential brittleness comes from the risk of increasing complexity through uncontrolled proliferation of services that are difficult to locate or inadequately constructed or understood. Insurers may see more redundancy of services and greater infrastructure complexity as a result of poor SOA governance. They may find it more difficult to make changes rather than realizing the ability to swap out components as quickly as needed. SOA inefficiency also comes at a price, since building a service to be reusable carries a higher upfront development cost.

Ultimately, SOA failure means companies will not get the return on investment they anticipate, and they even may spend more time and money over the long haul than they would have under traditional development.

In the worst cases, companies "aren't establishing any type of [governance] strategy," Manes says. "They let developers go off and use the tools any way they want. They generate schemas any way they want. As a result, they wind up with lots of point-to-point connections, redundant schema representations of the same information, and they haven't managed to reduce the complexity of their environment."

Avoiding these problems while making it easier to manage the "complexity constant" requires creating and implementing governance processes that control the entire service life cycle: design time, runtime, and change time. "One of our executives is fond of quoting that 'SOA without governance is SOL,'" Stuart quips. "SOA without effective governance will fail, period."

He compares well-governed SOA development to an assembly line. "An SOA factory, if you will, is a mass-production environment where you need parts that are standardized, have standard interfaces, and where you've built receptacles to receive them. You will not get that unless you have an effective governance strategy and process to ensure people are building the right things and building them right."

OBSTACLES TO SUCCESSFUL GOVERNANCE

As with other areas of IT governance, SOA governance starts with processes and people. "It is not a product you can buy. It's about the process, and it's about changing behavior," Manes says. And that points to a fundamental problem of bringing about SOA governance: Any activity that requires changing people's behavior will meet with resistance if not handled correctly.

"Everybody likes governance, but no one likes to be governed," Stuart says. "IT folks are creative, and attempts to standardize the development process often are resisted by IT under the argument of 'you are restraining my artistic creativity.' But we're not creating art, we're creating business solutions."

That's why SOA governance has to extend from IT governance, which in turn is an extension of corporate governance. "It can't be done in a vacuum," asserts Manes.

SOA governance requires involving business and IT stakeholders in the process rather than delivering edicts from on high. "Most insurance companies already understand the benefit of enterprise, cross-silo standards," says John Lucker, principal at Deloitte Consulting LLP, "but there's the age-old problem of communication. You need to make sure everybody knows when these standards are put in place and include a feedback mechanism, since not everybody's voice may have been heard."

GOVERNANCE IN ACTION

Farmers Insurance Group also is in the midst of a multiyear architectural overhaul, driven by an enterprise initiative of parent company Zurich Financial Services. The organization implemented several structural changes, such as creating local governance teams in addition to a global SOA governance board, in order to manage each governance checkpoint–service initiation, function analysis, design, construction, user acceptance, and implementation.

"As part of the process change, we also created an infrastructure center for our developers to cultivate the culture of reusability. You have to do communication to get acceptance," says Partha Srinivasa, CTO and global chief architect of Farmers Insurance Group.

Great American has invested in outside consultants to coach staff on SOA development, has created competence centers to identify and develop best practices, and encourages two-way communication. "We see pragmatically what works and what doesn't. We try something, do a post mortem, and back up. We're still early in the SOA cycle, but believe me, we would not be on this path if we didn't think [SOA] was the right solution," says Stuart.

Communication and education about the importance of governance also require making the case to business management. "You risk compliance violations [without effective SOA governance]. You may not be able to respond to discovery requirements. You may have security breaches. You also have challenges with never being able to figure out what's causing slowdowns in the system," Manes explains.

Still, she admits the payback of SOA governance generally is based on soft returns, and therein lies a communication problem. "Unless there's already a problem, people don't want to spend the money. The business that is paying for an application is not interested in paying for a fundamental core technology the IT team needs to do its job better," says Manes.

Farmers Insurance invested in establishing SOA infrastructure competency centers and developing an SOA road map before spending a single dollar to create any individual services.

"Everyone understood the value [of SOA] on paper, but when it came to putting dollars into it, they said, 'Who's going to pay the first dime?' So, we met with various groups to understand who's going to own the services and the infrastructure, how we could implement SOA across the organization, what functionality services should provide, and how they fit within our existing enterprise architecture. That's when we realized we first needed to define a governance process and framework," Partha says.

Obtaining top-level corporate support and developing a governance funding model not tied to line-of-business units were key to making the initial investment in governance, he adds, emphasizing that IT must continually demonstrate the value of governance to the enterprise.

"Once you have created the foundation–which has no business case dollar-wise–you need to map each [services development] project back to the framework to show the value. It's been just six months since we began rolling out services, but ones we have deployed have seen at least three or four different reuses and already have paid for themselves," reports Partha.

Great American also realized SOA governance was a "must have" that needed to be added to its existing architectural governance, according to Stuart. "We haven't done a full ROI calculation because there are a lot of soft costs that are hard to quantify, such as lost opportunity cost," he says.

"For example," he continues, "if we saw a market opportunity and wanted to put up a product into that space, under a traditional model, it would take many months and millions of dollars. If we weren't sure the opportunity really was viable, we would walk away from it. But what if it would have given us a run rate in the millions? How do you measure that lost opportunity cost? SOA enables us to capitalize on that opportunity quickly and at a reasonable cost due to reusability, thereby increasing the top line as opposed to just cleaning the bottom line."

TIME FOR TECH

Ultimately, technology is needed to manage the governance process. "There's too much to do if you don't have automated ways of validating and managing your governance," says Stuart.

A company needs to begin by identifying and cataloging what services it already uses. "[Services] inventory is a foundation for governance, but some insurers don't have that foundation," Lucker says.

Next is to identify what governance tools a company has that can be repurposed to SOA management in both design time and runtime. "If the organization already has instituted software asset management systems, it could conceivably use those rather than SOA registries and repositories. If you have workflow tools for the development life cycle, you could use those rather than SOA-specific BPM [business process management]. But the reason companies are choosing SOA governance tools is those tools are well designed for the purpose," Manes says.

A registry is the catalog that houses descriptions of services, enables users to search for services, and maintains history as services are published, used, and changed. A repository houses information on service-level agreements, policies, rules, and other data related to the creation and use of services. In practice, the function of the registry and repository are complementary and may be combined. For instance, Software AG's CentraSite Registry Repository is in place at Lenders First Choice, which provides title insurance and closing services for lenders.

Lenders acquired the CentraSite Registry Repository as part of its deployment of Software AG's webMethods SOA development platform, which the insurer used to rebuild a legacy system that processed incoming applications from customers for title insurance.

"We wanted to leverage SOA architecture so we could build the code once and reuse it elsewhere. We also wanted to connect automated workflow and human-centric tasks, so we needed a BPM layer. Therefore, we decided it was more cost-effective to leverage the whole webMethods stack for SOA architecture, workflow, and SOA governance," says Norman Gottschalk, the insurer's senior vice president of software development.

The application system receives requests for title insurance and initiates services needed to underwrite the transaction, such as automated OFAC name-matching, "flip list" (property churn) checking, and transmitting assignments to appraisers. Approved applications generate a service call to Lenders' Adobe-based document production system, producing title insurance documents that are mailed or electronically transmitted to the lender.

The project has enabled Lenders to evolve from a minimum of automation to automating about 75 percent of the processing involved in the tens of thousands of orders it processes each month. BPM was a key component to being able to orchestrate services quickly and put the power of process design in the hands of business analysts.

"That's where we gain the most reusability," Gottschalk says. "Developing in SOA is different than a traditional application, and we've learned over time we now can have business analysts build a process directly in the webMethods framework. They plug objects or services into the designed workflow, and that design becomes production code."

Therefore, governance is critical to ensure services are designed to be reused and can be located by business analysts. CentraSite governs services design by creating attribute documents that determine what a service must have before it can be published, and Lenders also performs code review before new services are checked into the registry. The registry contains information about and a hierarchy of services, enabling analysts to determine what already exists for a new automated process or what might need to be created.

The CentraSite system will pave the way for runtime governance at Lenders. "Our previous system didn't have a true security model as to who could execute what process. CentraSite will allow us both flexibility and control over that aspect of governance by enabling and defining the access external parties can have to services," Gottschalk says.

Great American has leveraged its enterprise service bus from Sonic Software to connect and orchestrate service components and replace the "hairball" of integration points with a centralized system–as a key component of SOA runtime governance. "Service monitoring and management software also enables us to do better business activity monitoring and can handle security better by extracting that function from the application layer," Stuart notes.

Additionally, Great American has built an interim repository for service-related metadata. "Dependency management, configuration management, code compliance with standards, actual response times vs. what's specified in service-level agreements, and dependency impact analysis are critical components of SOA we manage in the metadata repository," he says.

The insurer does plan to migrate the interim repository to a commercial product. "We're looking at obtaining a metadata repository that can integrate not just with the service registry but also with the orchestration engine. We have several tools in our kit right now and several possibilities we're considering, but we don't think there will be a single solution. Some are better suited for design time, some are better suited for discovery of rogue services and other runtime governance, and some are better suited for integration with our SCM [source code management] tool, so that developers can't check something in that violates our policies," Stuart reports.

The fact that one product can't do it all highlights the fact that enforcement of governance changes throughout the SOA life cycle. The registry repository maintains standards and policies and, during design time, is the key tool for enforcement. But during runtime, a services management component–a class of tools that can be either software or hardware–is needed to monitor services, ensure they are meeting SLAs or other performance standards, isolate faults, enforce security, and identify rogue services.

Farmers Insurance uses BEA Aqua-Logic Registry Repository at design time and relies on its local governance bodies to monitor and enforce services standards. "We look at what assets already are in the registry. Can we reuse them, or do we need to develop something new? If someone wants to make a change, what does it impact? You need to have those checkpoints because otherwise people go off on their own," Partha says.

During runtime, Farmers relies on AmberPoint's SOA management system to monitor SOA assets and enforce policy-driven security as well as to provide visibility into the SOA network. "A big value-add has been the business intelligence delivered by the [management] system," Partha indicates.

WHEN TO START?

Ideally, insurers should begin SOA governance before they create a single service. But in reality, many wait until they reach a critical mass of services.

"It's fine to experiment and pilot some prototypes, but once you get the basics of the technology understood, you need to establish strategy for your SOA road map," Manes stresses. "Once you've got a bunch of uncontrolled services and bad design practices, you have to live with them for a long time. If you can establish good governance from the beginning, you set a good example and don't have to worry about breaking bad habits."

Although applying the proverbial ounce of prevention can be a difficult sell to time- and resource-constrained businesses, insurers that have made the investment can attest to the benefit.

"The key to SOA success is governance," Partha affirms. "If we hadn't made the investment in our [governance] model, we would be struggling."