SOA expansion sends user scurrying for management tools |
 |
By Rich Seeley, News Writer
30 Jul 2007 | SearchWebServices.com |
|
|
Service-oriented architecture initiatives that start out as small SOA can quickly become big SOA, as Erwin Kersten, lead Engineer at Unive, a non-profit insurance company in the Netherlands, can testify.
|
|
|
|
|
During 2006, we encountered a tremendous growth in the number of services.
Erwin Kersten
Lead Engineer, Unive
|
|
|
|
|
|
|
|
|
|
After deciding to move to SOA in 2004, the provider of insurance for healthcare, autos, homes and life for 1.3 million customers, had its first Web services up and running in 2005. However, by 2006 the proliferation of services began to overwhelm the IT department.
As is often the case, the SOA implementation on the company's Microsoft .NET framework began as a plan to simplify business processes and add agility. The SOA project was in response to new health care legislation in the Netherlands that was going to require ongoing changes to business processes as new government regulations came into effect.
"The motivation for us to use SOA is it is very flexible for making changes, and reusable so you can develop and implement a lot faster," Kersten said. It began modestly with 10 to 15 services running in conjunction with K2workflow.net from SourceCode Technology Holdings, Inc., which is built on the Microsoft .NET framework. Unive uses K2workflow to set the business rules for its insurance applications. The first SOA application provided rate quotes that Unive insurance representatives could give to customers.
"We started small with our SOA," Kersten recalled. "We didn't have any monitoring tools whatsoever. There wasn't really a need at that point because it was really small. We had a few systems engineers monitoring it."
But what began small quickly mushroomed.
"During 2006, we encountered a tremendous growth in the number of services," Kersten said.
The SOA applications grew to include automated insurance registration where the .NET Web services interact with legacy applications, he explained. To prevent errors or fraud applications were also developed for crosschecking to be sure auto policies are applied to the correct license plates.
Those Web services go out to external agencies to check information such as vehicle registration. The SOA implementation also extended out to several more legacy systems running, including those running on Unisys mainframes.
These applications have had a positive impact on productivity at Unive, Kersten said. He estimates that the SOA system has reduced the amount of manual work that employees have to do on those business processes by 60 percent.
But the growth didn't come without some problems as the number of .NET Web services had increased from approximately 15 in 2005 to more than 70 by 2006, Kersten said. The systems engineers found themselves monitoring Web services with at total of 187 end points.
"At that point we lost track of the dependencies," he said. "We couldn't monitor it any more. We were busy tracing problems that were occurring in our environment that we couldn't directly pinpoint. So at that point we started looking for some management tools."
As an example of problems they were having, Kersten said, "We had trouble with the 'client tracing' tool. It was really hard to trace where it was going wrong because it involved a long chain of services. We had to check all those services to see if there were any SOAP faults occurring. That would take several hours."
The systems engineers needed to visualize the dependencies of the services. Not only could the systems engineers not track the dependencies of existing services, but as developers created new services, it was hard to determine which services would be calling other services. The engineers also needed a way to centrally do exception and service level management.
Unive turned to AmberPoint Inc, the SOA governance vendor, and began using AmberPoint 5.1 in November 2006. With the management software systems engineers could quickly visualize where problems were occurring in that chain of services. The resolution time for solving faults and SOAP errors decreased from several hours to a few minutes.
Relating his cautionary tale, Kersten advises colleagues contemplating a small SOA project to start thinking in terms of management and governance early as they may quickly find themselves dealing with big SOA.
|
|
|
|
