Back when SOA first started getting traction, the goal was simply to make application functionality available as a shared service. Companies made up their architectures as they went along – and of course, they’re still doing that. The difference today is that, in the last couple of years, the business side has a better sense of the strategic value of IT, while IT has learned more about the competitive pressures business must endure. As a result, SOA now offers the possibility of greater alignment between IT and business than ever before.

What business needs is an array of services that can be recombined, resulting in new business processes that support new products or services. Publishing those services and providing a coherent framework within which they can be governed and orchestrated into applications is what SOA is all about. Although many SOA initiatives remain an early phase, the promise of increased business responsiveness is real. And we're seeing an increasing number of enterprises that are pushing toward advanced deployments. The case studies here are prime examples.

Comcast builds its SOA on domain expertise
It’s tempting to start buying ESB, registries, and other tools when you decide to adopt the SOA approach. But that misses the key value of SOA, which is to have a way to align the applications you create and deploy to the business processes they execute, says Tom Adler, senior manager of application architecture and IT governance at Comcast. And starting with the architecture can help ensure you have the right framework to do that – both now and as needs change over time, he says.

“When we started this effort 18 months ago, we resisted the temptation of bringing in vendors. We brought in subject matter experts instead and figured out what we needed first,” Adler says. “All the vendors just wanted to sell us an ESB.” The architecture effort does more than set the framework, he notes: It also begins identifying where you already have redundancies, both in business processes and in applications. That’s key to getting business buy-in, Adler says, because it shows in very real terms where there are opportunities for savings that will help justify the eventual SOA infrastructure and tool investment, as well as show where the use of common services should help reduce maintenance and integration complexities, allowing more responsive development efforts in the future. “It’s the target that lets us eliminate redundant services,” he says.

After developing the architecture – what Adler calls the common domain model – Comcast’s next step was to develop the governance framework for the service development and deployment. “Services need to go through the governance gate,” he says, “otherwise no one will know that the services exist or follow the right policies and procedures.” Only services that pass the governance gate are added to the service registry and thus made available for others to reuse.

One governance challenge that came up quickly was deciding who owned the services. Comcast is fairly decentralized, so the culture naturally supported having the service originators own the services in their domains, Adler says. Common services, such as single sign on, reside with IT – their natural domain, he adds.

One step that Adler now realizes Comcast missed was developing a common data service model after defining the architecture. By not having standard data services to access corporate information and manage interactions across systems, developers have ended up designing their services to get the job done in different ways, leading to inconsistencies that break the SOA promise of allowing an easy mix and match of service components. “We underestimated the value up front,” Adler says, and the price has been reworking some services to impose that model after that fact.