Verizon goes back to the workbench

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.

Getting these 500 Web services built required deploying SOA not just as a methodology, but as an IT governance principle. "We implemented a process whereby all development projects would have to go through a strategic architectural assessment session to get approval before they were started. If any of the functions were one of those 500 core business functions we had identified, or we found another suitable business object, the team would have to implement it as a Web service. Once the project was completed, it would go through a tactical architectural assessment session that would verify the Web services were built before giving clearance to go into production," Zafar says.

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.