Verizon goes back to the workbench

Convincing developers to embrace SOA meant extensive custom development

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."

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.

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.

To address these issues, Verizon built IT Workbench, an infrastructure layer that houses the Web services directory but also adds management capabilities. For example, if one development team built an address-validation service that it wanted to expose to other applications, it could download a lightweight agent onto its server that would register the Web service and its capacity and define an SLA inside IT Workbench.

After services have been registered, developers can go to the central directory to find ones with their specific requirements. For example, they can search for a service with the capacity to support 100,000 transactions per day with less than a two-second response time and a commitment to be available 99.8 percent of the time from 8 a.m. to 12 p.m. Accounting and billing are also in place, so the service provider can charge for usage -- another incentive to use SOA.

"It started with onesies and twosies," Zafar says. "But when it hit 10,000 transactions per month, [SOA] suddenly took off with exponential growth. Now it's used in almost 10 million transactions per day."

What's more, any reluctance to expose code has virtually disappeared. According to Zafar, developers are now competing to get others to use their services, as a way of gaining recognition within the company. The most-used services are listed on the IT Workbench portal with the author's name and photo.

"Before, people would say, 'This is my code, use your own,' " Zafar says. "Now they're reaching out to each other over the weekends, saying, 'Why don't you use this service I built,' so they can be more popular on the IT Workbench portal. In fact," he adds, "developers are trying to push applications as Web services that are not suitable because they have few or no logical consumers. It's an interesting social phenomenon that I never anticipated."

Copyright © 2005 IDG Communications, Inc.

How to choose a low-code development platform