At Thomson Reuters, businesspeople 'own' all services

'When you press the button, there are no excuses:' business owners are responsible for services through their entire lifecycle, even assuring uptime and availability.

Want to ensure that business gets the most out of the services they request or maintain within your SOA registry?  Then assign the business owners full responsibility and ownership of the service -- even to the point where they are responsible for provisioning enough processing power to keep it up and running.

Such is the service-oriented strategy at Thomson Reuters, a provider of business intelligence information for businesses and professionals, which maintains a stable of 4,000 services that it makes available to outside customers. For example, one such service, Thomson ONE Analytics, delivers a broad and deep range of financial content to Thomson Reuters clientele. Truly an example of SOA supporting the cloud.

I recently had the opportunity to chat with Vladimir Mitevski, vice president product management core services at Thomson Reuters, about his company's approach to service oriented architecture governance.

In many SOA projects, IT takes the lead role. For Mitevski's operation, IT takes a back seat. If a service succeeds or fails, it's up to the business owner, he says.  "We have three types of roles," he explains.  "There are service publishers, QA approvers, and the business owners. If you think of the US government, you have the checks and balances between the House, Senate, and the president, and everyone can override each other at the end of the day.  This is the same concept We adopted." Governance of all services is managed through an HP Systinet registry, which tracks ownership and service status.

Ultimately, however, the service's business owner is responsible for the lifecycle of the service -- from inception to production to retirement, Mitevski says. Prior to establishing this chain of responsibility, when services were the domain of everyone in the company, there was a lot of blame and finger-pointing, Mitevsky points out.  "We had a process where things are just thrown across the wall, and when things happen in production, the product managers they quickly wash their hands of it if something went wrong: 'Oh, I don't know, QA was supposed to test it.' QA would respond, 'You give me garbage, and you never described what I supposed to test all the way. I tested what you provided me.' Then, he adds, 'the business owner was always coming back and trying to blame the lowest guy.'"

By assigning accountability and ownership of services, the buck stops at the desk of the business owner. "We said: 'business owner, are responsible for testing, validating, and assuring that the service is working. Which means when you press the button, there are no excuses."

In addition, Mitevski's team has configured the service registry to be as transparent as possible. Any and all existing service -- along with current status, and whether any changes have been made -- can be viewed by anyone within the enterprise.

"If customer support gets a call about a specific service not acting properly, they can look at it right away in the registry, which is open for anybody in the organization to view it as a read-only." Any changes also include the names of individuals that made them. "Not only that, we also have the application support information and development managers kept in the registry. If there is a production problem, any analyst will know the name and number of the developer, and can give them a call to try to resolve the problem."