To overcome its SOA roadblocks, Verizon had to build an entire SOA operational infrastructure virtually from scratch -- and it has the patents to prove it. "As a technology, Web services are great, but today's standards don't have nearly enough operational infrastructure around them," says Shadman Zafar, Verizon's senior vice president of architecture and e-services. "You can end up with a plethora of Web services but no awareness of which of them are where and provide what function -- and most important -- which have the right kind of capacity and SLA to be usable by what and whom. The result is that SOA risks simply becoming a toy for the developer."
As have many other SOA implementations, Verizon's started after a merger -- in this case, the GTE/Bell Atlantic merger that created Verizon.
"I was tasked to integrate the two IT departments to achieve strong synergy targets," Zafar says. "During our initial research, we found that many of our core business functions were implemented anywhere from five to 30 times across different applications."
Verizon set out to use SOA to reduce support costs by consolidating these core functions from 20 or 30 implementations to one or three, in each case. The first step was to spend months identifying roughly 500 key business functions that were used over and over again for many applications.
"We didn't go through 10 million lines of code. We picked out 500 business functions and targeted them," Zafar says, citing examples such as the credit check service, the telephone number engine that provides new customers with telephone numbers, and the address validation service. "An ordering system might go through four or five of these key components."
Click for larger view.
But as developers began building Web services, the operational roadblocks became clear. "There was a lot of resistance to using the services because of the lack of standards around four essential operational pieces: SLAs, accounting, billing, and capacity management. People weren't willing to entrust their mission-critical applications to each other," Zafar says.
Developers were also very reluctant to expose the code they had worked so hard to produce. In many cases, one developer wouldn't even know what infrastructure the other Web services were using.