Why Layering Requires Centralized Management

Nothing in IT is ever simple, including the creation of an integration layer. The goal of the strategy is nearly always to minimize redundancy by having as few messaging infrastructures as possible and creating a single repository of services. Therefore, by definition, the integration layer demands centralized IT management.

"Absolutely," says Rick Sweeney, chief architect for Blue Cross and Blue Shield of Massachusetts. "SOA isn't a technology; it's a framework, a blueprint, and if you don't have control over it and aren't guaranteeing that it's being applied across the organization, you'll never have a true SOA. There are probably a million ways to architect an integration layer, but you can't have a thousand different ways inside your company."

For example, Verizon, though geographically dispersed, has a centralized business and IT model, so there was no conflict over the composition of the integration layer or the SOA strategy behind it. Indeed, the original impetus for Verizon's strategy was to eliminate the redundancy of systems that resulted from its mergers and acquisitions of other telecom companies such as GTE and Nynex.

That wasn't easy. When Zafar's team began picking over the remains of those systems in 2001, it combed through every button and drop-down menu in every application it could find - roughly 2900 in all - looking for shards of software functionality that might be incorporated into a service component. From the thousands of function points they found, the team isolated between 200 and 500 functions that are needed for the more than 90,000 business transactions (such as setting up a new landline account) that Verizon performs. Then the team looked across the infrastructures and found five to 25 redundant versions of each function. Zafar says that gave him all the incentive he needed, and all the proof that Verizon CIO Shaygan Kheradpir and other company executives demanded, to approve the integration layer strategy.

The Trouble with Developers

Surprisingly, a services strategy, despite its obvious advantages, may not be all that popular among developers. "Developers want everything to be easy," says Clint Petty, a director in professional services for software and services vendor CommerceQuest.

Services are not easy - at first. Extra work is required to create an interface, the part that describes what the service does in business and technical terms and how other systems access it. Good interfaces are like good friendships: easy on the surface with no hint of the relationship's history of ups and downs. "A good service knows who it is, can describe itself to others and show who wants to connect to it," says Jeff Gleason, director of IT strategies for the financial markets group of Transamerica Life Insurance and Annuity. "The essence of service-style integration is that the interface is intelligent and communicative."

Developers writing links to a good interface need only write the basic communication code that accesses it - a programming version of a handshake and a hello - and the service does the rest. The developer doesn't need to know what the service is composed of, what computer language it is in or even how it works - only what it does in business terms.

But developers need incentives to build those interfaces. "Everybody is focused on getting a new application up and running now," Verizon's Zafar says. "And their primary focus is not on how they can continue to add value to other systems. If they feel pushed to the wall, they won't opt for the best possible design - just the best design to get the job done."

Zafar first created a centralized development methodology and services repository to ensure that services and their interfaces were being developed consistently. He also does architectural reviews at the beginning of a project (to get developers to promise to use existing services and build new ones during the project) and at the end to see if the developers have met their promises. When Zafar began developing a services catalogue (known inside Verizon as the "IT Workbench") in 2001, many did not. "We had to stop some projects," he recalls. "People learned that they had to reuse the enterprise assets."

As the catalogue has grown, more positive reinforcements have come into play. Though the development methodology is heavily centralized, Zafar says he encourages developers to submit refinements and best practices that, if they are good enough, are incorporated into the overall methodology. On the Web site where services are stored, Zafar ranks those that get the most reuse and puts the developers' names beside them. The chances for stardom for individual developers are good, because Verizon also publishes some Web services to external partners. "It's exactly like the open-source model," says Zafar. "People take pride in seeing their code being reused by others."

But before developers outside the company will use services - and before business leaders will sign off on their use - they need some guarantees that the work done by others will not bring down their own applications and businesses. (This could happen, for example, when a service designed to handle 10,000 transactions a day is added to an application that runs 20,000.) Though a centralized development framework may not always be popular with developers, it certifies that all work is done in roughly the same way and to the same standards. To that Zafar adds service-level guarantees, including transaction-handling capacity, transaction speed, hours that the service will be available and an agreed-on price for using it. "Unless you have a framework for development and service and accounting agreements, no one will trust the service on a mission-critical application," says Zafar. "This is why SOA is still a toy in many companies today."