 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA All-in-One Guides > SOA Implementation > SOA Runtime > Lessons learned > How The Hartford does SOA |
| |
|
|
|
||||||||
| All-in-One Guides: SOA Implementation: |
|
|||||||||
|
||||||||||
|
||||||||||
|
||
|
SOA Runtime
 Lessons learned
|
|
| |
|
|
| |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
At the end of this decade, The Hartford Financial Services Group, Inc., which was founded in 1810, will celebrate its 200th corporate birthday and it will also be a 10-year milestone for its in-house SOA practice.
SOA is more than standards, technology or vendor products, including ESBs, said Benjamin Moreland, director of foundation services in the enterprise architecture group at The Hartford. Having worked more than five years on the design of SOA applications that are now serving the needs of the company and its independent agents, he shared his experiences, perspectives and recommendations at the Burton Group Catalyst Conference earlier this month. "What we have learned at The Hartford is SOA is much, much broader than standards and technology," he said. "Our emphasis is on enterprise architecture. We have never done SOA for the sake of doing SOA because it's the next hype from IT. We've always been driven from a business perspective." What are the business drivers at The Hartford? Number one is the need to lower total cost of IT, Moreland said. The company already is taking advantage of Web services reuse. "We actually have one service that is used in seven different applications," he said. The next business driver he listed is serving the IT customers. The Hartford does not have a field sales force, but works with independent agents. So Web services need to make their job easier by speeding tasks such as assembling the documents the agents need to complete transactions with their customers. One of the first SOA applications at The Hartford focused on services that bring documentation and data together for agents to access from their Web browser. Early in this decade, the architecture group at The Hartford determined that SOA would be the most cost effective way to replace aged COBOL applications, he said. "We have systems that are as old as I am," Moreland said. "[They're] at least 30, 40 years old and they're still working. So, we're trying to retire those." In terms of lessons learned so far, Moreland said, "Don't think that any tool is going to solve your SOA problem." He is particularly disdainful of vendor hype, especially around ESB products. "The enterprise service bus is more 'marketecture' than anything else," he said. "The problem is people think that ESB equals SOA and then they think SOA is a product you can buy. It's obviously not." However, Moreland said he finds that the functionality associated with ESBs, including transformation, routing and monitoring, are important, but he opposes the marketing buzzword. In another presentation, Chris Haddad, senior consultant with the Burton Group, explained that view. "Burton doesn't use the term ESB because the term has been co-opted by vendors with everybody claiming to have an enterprise service bus," Haddad said. Anne Thomas Manes, vice president and research director for the Burton Group, has coined the term "managed communications infrastructure" for what others call ESB. Moreland clearly preferred that term because it fits with his experience that SOA is a product of architecture and not a product of marketing. While the architects at the Hartford have had long discussions about tools, he cautioned the IT professionals in his audience from rushing out and buying SOA tools before they take an inventory of what they already have. "You probably have many of the tools you need to do SOA," he said, "you just haven't thought about them that way." Instead of listening to vendor sales pitches, Moreland urged his fellow architects to start their SOA implementation by "thinking strategically, but acting tactically." "You need to have a vision of where you're going," he said. "But act tactically. Start small. Don't boil the ocean. Focus on architecture. If you focus on the architecture and the organization and governance to support that architecture, then you'll have a better idea of where you need to go." Keeping an eye on the big architectural picture is important because while SOA aims to break down organization silos that have traditionally separated IT from business operations, he warned against the pitfall of creating new technology silos.
"Be careful though that you don't create technology silos as you break down organizational silos," he said. "You can have a BPM solution. You can have an orchestration solution. A rules solution. They all overlap. You've got to have criteria and best practices around how you use each." It is important to see that those overlapping technologies are components of the service-oriented architecture and that SOA is itself a component of the enterprise architecture, he said. After all his advice, he ended his talk with a riff on the old Frank Sinatra standard. "Finally and most importantly, do it your way," he said. "There is no one way to do SOA. If you want to start with portals, start with portals. If you want to start with BPEL, start with BPEL. If you want to start with BPM, start with BPM. In the end you've got to address all of these different issues if you really want to move up and move forward."
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
