Thomson Financial automates service compliance
Many companies like the SOA concept because it promises faster development times. But some SOA developers have discovered that a key part of service governance can actually slow down development, stealing that promised speed. Financial publisher and information services firm Thomson Financial discovered this unpleasant surprise early in its SOA journey, recalls Vladimir Mitevski, vice president of product management core services.
“To call it an enterprise production asset, a service needs to comply with several methodologies and policies,” Mitevski notes. Many are very exacting: The names of XML elements can’t be abbreviations and must be real dictionary words, for example, and some items, such as user names and passwords, cannot be hard-coded. When you have just a few services, the enterprise architecture team can usually keep up and also catch any issues, he says. But soon enough, the reviewers become a bottleneck and even begin missing problems due to the workload.
Thomas Financial has thousands of services – fine-grained, coarse-grained, and everything in between – and a small architecture staff, so it quickly felt the pain. “No matter what the granularity, each service goes through this process,” Mitevski says. Only then is it entered in the service registry. Likewise, changed services need to be evaluated for compliance before the new version is registered and thus available for production use. “But the architecture office was a bottleneck due to the scale,” Mitevski says.
Reducing the compliance requirements was not an option, given the critical nature of the applications involved, such as single sign-on services, Web services that deliver financial markets information to analysts and traders, and Web-based financial analysis and charting services accessed through Microsoft Office.
Thomson’s solution to the compliance workload issue was to turn to automation, using policy evaluation tools from WebLayers. “The tools are more efficient and don’t miss violations,” Mitevski says. It did take some time to create the policies that the tools gauge compliance against, and it’s critical that architects review the tools’ analyses to see if certain issues arise repeatedly that might indicate lack of understanding of key policies by developers or ambiguity in the architecture, he notes. “It helps show us what to do better, and some policies do need to be adjusted” Mitevski says, though he has found that most violations are due to developers taking shortcuts. Architects also decide when developers are granted exceptions for any compliance violations, something that happens only rarely, he notes, and the exceptions are noted in the registry for other users to be made aware of.
For Thomson Financial, the results of service compliance automation are dramatic, Mitevski says: “It used to take 20 people in a highly orchestrated process across various groups to go live [with a service]. Now it takes just a single person.”
Jabil Circuit simplifies customer integration
A company that focuses on manufacturing services needs to accommodate a wide range of customer integration, such as for billing, forecasting, and order systems across the many systems in use by its customers. But it’s very hard to manage all those point-to-point communications as your customer base grows and evolves its own systems. That’s why many manufacturers have moved to third-party providers of transaction hubs, called VANs (value-added networks); each supplier and customer worry just about the one connection to the VAN, and for each customer-supplier pair.