WebServices dot org

Jake Sorofman, vice president of product marketing for Systinet, believes there is going to be a high rate of failed SOA attempts over the next year or two. That’s because too many enterprises will be approaching SOA from the bottom up, attempting to fuse disparate service initiatives with no guiding set of rules or principles – governance – around impact analysis, change management, policy management and contract management.

Don’t wait until your enterprise develops some “critical mass” of Web services to put governance in place, Sorofman advises. Start now, even if you may only have a few services in production. “There will be SOA projects that fail, and fail in a big way, because companies see governance as something they don’t need to consider until they reach some critical mass of business services. And by the time they encounter problems, it may be too late.” Such problems may have severe repercussions for any future SOA efforts, including performance glitches, and breakdowns in trust on the part of business users.

While most SOA efforts at this time are limited to departmental efforts -- or are just starting to get out of the gate – it’s never too early to start building a well-aligned governance strategy. “The idea that governance or registry repository only starts to matter when you reach some critical mass of Web services or business services is really missing the point,” Sorofman advises. “Number of services is not the right metric. The metric that needs to be looked at is number of consumers and number of dependencies. This may be, to some extent, dictated by number of services, but not always. You can have very few services that are broadly applicable, and widely relevant, and widely reused. That still calls for governance, to ensure that your SOA doesn’t go sideways.”

Conversely, he adds, “you can have a large number of services that have very low reuse, and very limited applicability. In that case, governance can actually be less of a critical consideration.”

Governance has grown as a focal point over the past two to three years directly as a result of the surge in interest in SOA, and the rapid proliferation of Web services and other types of services across enterprises. Sorofman has seen SOA deployed many ways, and is an advocate of the top-down approach. In fact, the greatest mistake businesses are making these days is attempting to rationalize a tangle of services growing from the bottom up, he says. “It’s very important for companies to map their business services to their business architecture and business processes,” he says. “There needs to be a top-down aspect to SOA. It won’t come from just a bunch of Web services that are not specifically mapped to the way that companies do business. The top-down approach is critical to getting early success within a project.”

Such a top-down approach should include “a specific mapping of your business processes, and understanding what services have applicability beyond an application of one,” he explains. “Then, you need to use that as the basis to drive out the definition and priority of business services that you introduce.”

In contrast, Sorofman points out, the alternative, bottom-up approach consists of saying, “let’s take everything we have, and everything that theoretically could have reuse value, and introduce it.”

Of course, the enterprise focus that SOA requires doesn’t stop at design time. “While SOA has the promise of delivering very compelling business benefits, and helping companies to achieve higher degrees of flexibility and agility, it comes with a cost, and that cost is the complexity it creates,” he relates. “That complexity arises from the relationships that are apparent within SOA. You need a way to be able to track and manage and understand all these relationships, to manage this complexity.” Tools such as registries and repositories are instrumental in managing impact analysis, change management, policy management and contract management as an SOA expands, he adds.

That’s why lately, the category of registry/repository, at it relates to SOA management, has become a distinct product category in itself, Sorofman observes. “Registry/repository has clearly established itself as a subcategory of SOA governance,” he explains. “It’s fairly clear that registry repository has become the foundation for SOA governance. And there’s now a healthy ecosystem of specialized vendors that add value on top of the governance foundation in specifics and specialized ways.”

Sorofman’s message is that by introducing governance very early in SOA cycle, just as services are being designed, enterprises can gain “early traction.” SOA can be a tough sell to management, and having a governance process in place early will help “prove the value, justify the business case, and get reuse out of the services you introduce, to get follow-on funding to broaden your initiative,” he says.

“You need visibility to find services, and understand their intended functions, attributes, and characteristics,” Sorofman adds. Trust is perhaps the most essential ingredient to any SOA or Web services rollout. “If you don’t have the trust to generate reuse and to build the good will between consumers and providers, and if you don’t have control over the services to ensure that a change in a service isn’t going to have a business consequence, the project won’t advance.”