Transamerica's SOA transformation |
 |
By Rich Seeley, News Writer
16 Mar 2006 | SearchWebServices.com |
|
|
When considering SOA projects, it's easy to get caught up in the details of the various standards. How will SOAP work? What about WSDL? Where does UDDI fit in? Should we use XSLT?
It is also easy for developers to focus on one project that one department needs really, really badly and really, really quickly.
|
|
|
|
|
You need to paint a clear picture of the relationship between business strategy and SOA or you'll be dead in the water.
Jeff Gleason
Director of IT strategies, Transamerica Life Insurance
|
|
|
|
|
|
|
|
|
|
But concentrating on the standards and technology or zeroing in on a single application misses the point of what SOA is all about, says Jeff Gleason, director of IT strategies at Transamerica Life Insurance Company's Annuity Products and Services Division. It is a case of missing the big picture and forgetting that the last word in SOA is architecture.
Gleason, who once worked in the trenches as a Java programmer, has been at Transamerica since 2003 working to establish a larger vision of what service-oriented architecture can do for the company. Chief among those lessons is that SOA, if done correctly, is a bigger project than just developing applications communicating via XML standards, important as that technology may be.
"SOA is less about technology and more about architecture and design," he says. And that requires more than writing new code.
When he started work at Transamerica, he spent three months studying the existing systems and how they supported business processes and identifying gaps in those systems and processes. Then he began looking at how SOA could fill those gaps.
In an SOA implementation that began in early 2004 and is ongoing, Gleason and a team of four architects worked to develop an overall design that would take into account the way one isolated business process, such as receiving a premium payment, may interact with other processes throughout the organization.
This is where it is important for developers not to get caught up in the demands of one department that may need a specific payment processing system. Gleason knows the problem coders face. With his background as a Java programmer he says he understands developers like to get code written and projects completed since that's what they get paid for.
That is why he advocates looking at SOA not just a business computing technology but as a strategy for changing organizational behavior. Starting with the CIO, he got IT and executive level buy-in for the business advantages of building applications on a larger framework that made the most of the agility and reusability made possible by SOA. Making his case included doing an ROI analysis to show the bottom line advantages to the company.
"You need to paint a clear picture of the relationship between business strategy and SOA or you'll be dead in the water," he says.
He stresses the importance of having a strong SOA evangelist in the organization who can make the case for the business advantages of reusing components and explain that if organization doesn't have an overall SOA framework, it won't be able to identify those components. A reusable component hidden in a jerry-built architecture to the point where it can't be found defeats the purpose of reusability.
The evangelist also needs to make the case for the agility made possible by separating the business rules from the code, so when a market changes or government regulations are re-written, processes can be modified quickly without re-writing code. Here again, Gleason warns against the developer's temptation to speed up completion of a single project by hard-coding business rules into the application.
Finally, once evangelists succeed in convincing the organization of the business advantages of taking the long view of the SOA implementation, their job is not over. The reality is that the evangelizing is a never-ending task. There will inevitably be requests to just this once go outside the framework and do this one-off project and those requests must be resisted to maintain the architectural integrity that supports the overall business goals.
To make sure everything holds together, Gleason advocates implementing SOA on a established developmental framework. Transamerica chose the Integrated Composite Application Network from SeeBeyond Inc., now part of Sun Microsystems Inc.
"Without a framework," he says, "I question whether you can do SOA."
|
|
|
|
