Lessons in rogue services prevention from Thomson Learning |
 |
By Rich Seeley, News Writer
06 Jul 2006 | SearchWebServices.com |
|
|
Searching for rogue services isn't keeping Christopher Crowhurst up at night. The vice president and chief architect at Thomson Learning is confident that the SOA platform for the information and education division of Thomson Corp. is not plagued with bad services, so he is not standing in line to buy the latest rogue detection tools.
|
|
|
|
|
But what you really want to point to is that if you do have rogue services, you are looking at a failure.
Christopher Crowhurst
Vice President and Chief Architect, Thomson Learning
|
|
|
|
|
|
|
|
|
|
In his view, if you are buying detection tools, you've probably already failed SOA 101.
"Rogue services detection has become something of interest to vendors as they see their infrastructure stack having an ability to identify the existence of rogue services," he said. "But what you really want to point to is that if you do have rogue services, you are looking at a failure."
He said he understands the need for detection when all else has failed, but he suggests that it will be important to learn from past policy and governance mistakes.
"The technologies that exist to identify rogue services are useful in that it allows you to quickly deal with the situation," he said. "However, you need to deal with the underlying problem of service governance to prevent services from being exposed without having the appropriate policy applied to them."
Thomson Learning, which links Web services in an SOA environment to provide online products including specialized research and other classroom materials to university professors, was an early adopter of SOA starting in 2001, sending XML files over HTTP and then graduating up to SOAP. But early on, Crowhurst realized that if he didn't establish firm policies for Web services design, development and deployment there were going to be problems later on. So he created policies to keep seat-of-the-pants coders from infecting Thomson's systems with what are now called rogue services.
His policies might be a model for how to keep the rogue services fox locked out of the Web services hen house. He starts from the point of view that while software tools may be useful, policy and governance begins with people following procedures.
"There are a rich set of rules for the lifecycle of the service from concept through to deployment," he explained. "We start at the beginning stage of an application so part of the governance model starts from the initial concept of the service needing to be created. It flows through design requiring design documentation to go through an approval process. Then in development there are design reviews, code reviews and threat analysis. Then moving from development into QA there's traceability matrixes based on required reviews of the test cases against the design requirements. Once you're out of QA going into staging there's required threat analysis, threat mitigation. Then when you're deployed into production there are sets of defined rules for cryptography, signature, etc., that are required."
How does he make sure the development teams are complying with the policies every step of the way?
"We have representatives from the architecture team embedded into each project to effectively manage the development lifecycle and make sure our policies are complied with and we don't have rogue services being developed," Crowhurst answered.
And what if I were a lone coder in the organization with a brilliant idea for a quirky Web service if I could just kind of slip around this policy and governance hassle?
"You'd never get near a production environment," the chief architect said firmly.
|
|
|
|
