Object Lessons in Services

At telecom company Verizon, the service called "get CSR" (get customer service record) is a complex jumble of software actions and data extractions that uses Verizon's messaging infrastructure to access more than 25 systems in as many as four data centres across the US. Before building the "get CSR" service, Verizon developers wanting to get at that critical lump of data would have to build links to all 25 systems - adding their own links on top of the web of links already hanging off the popular systems.

But with the "get CSR" service sitting in a central repository on Verizon's intranet, those developers can now build a single link to the carefully crafted interface that wraps around the service using the Web service standard simple object access protocol (SOAP). Those 25 systems immediately line up and march, sending customer information to the new application and saving developers months, even years, of development time each time the service is used.

Though the productivity savings for IT are huge, the strategic implications for Verizon are just as important. Create enough services and you can start to build a map of the business expressed in technology - a service-oriented architecture (SOA). A SOA is the blueprint that guides the development of the integration layer and its two major components: messaging infrastructure and services. A SOA is the big picture of all the business processes and flows of a company. It means businesspeople can visualize, for the first time, how their businesses are constructed in terms of their technology.

"When I said we have 18 slightly different versions of 'credit check' buried inside different applications in different agencies," says Miszewski, "the agency heads could understand why having all those different versions was a problem, and they could support creating a single version that everyone could use."

Toby Redshaw, Motorola's corporate vice president for corporate IT strategy, architecture and e-business, had a similar experience when he told his 80-year-old mother about IT's central catalogue of business services. "When I was done explaining it, she said: 'Manufacturing broke its work up into pieces 200 years ago. What's taken you so long?'"

When your business has an integration layer containing services, "a change in business policy can be made quickly rather than opening up an application project", explains Randy Heffner, vice president for Forrester Research. Integration becomes strategic, rather than an afterthought. "With business services, you are saying you are designing the business, and the design is too important to leave to ad hoc implementation teams working on a deadline," Heffner adds.

Not only does integration become strategic, it becomes a lot cheaper (at least 30 percent cheaper, according to estimates by research company Gartner) and faster too, taking months off development cycles for new projects. Anecdotal evidence pegs the financial and productivity gains much higher. At Motorola, Redshaw says that in some cases, integration costs have been reduced by a factor of 10. Shadman Zafar, Verizon's senior vice president for architecture and e-services, says that his catalogue of services let him skip forming a project team for the development of a phone-line ordering process, because the services necessary to compose the process were already in place. "With point-to-point integration we would have had a central project team to write the overall integration, and local teams for each of the systems we needed to integrate with. With [the phone-line process], we had a single team that was focused almost entirely on end-to-end testing." That saves time and resources and improves the quality of new applications, because testing is no longer the last hurdle of an exhausting application development process; instead, it's the focus.

If you can do all this, CIOs will be waiting for the business to catch up - not the other way around.