Why Great Services Demand Great EA
Shaygan Kheradpir doesn't get many accolades for doing his job. But when he starts talking about Spider, the Verizon CIO becomes a rock star. "Spider is the one thing I get a standing ovation for in meetings with the business," he says. Spider is a search engine that can find a customer record anywhere within Kheradpir's architecture.
And there are many places to look. Verizon is composed of three different companies (GTE, Bell Atlantic and Nynex), each with its own complex, customized computing infrastructure. But thanks to an initiative he began while CIO at GTE and carried over to Verizon in 2002, Kheradpir found a way to fish for customers in the waters of all three companies. "At GTE, we had a program called 'Oneness' where we were trying to consolidate different systems," he recalls. But Kheradpir's engineers advised against it. "They said we should not do a big-bang consolidation but rather build a common set of Web services across all our systems."
So instead of trying to consolidate all the systems that contained customer information, Kheradpir's engineers built Web services that encapsulated the business rules and could access the right data repositories. The service was difficult and expensive to build, but it had to be built only once. It's wrapped in an interface (also complex and difficult to build) that makes linking with the customer records simple. If a developer builds a new application that needs to link to customer information, he can write a quick, simple Web services-based link to the customer record interface, rather than building individual integration links with all the different systems around Verizon.
"Building something like Spider from scratch would have taken years in a company as big as ours," says Kheradpir. "But because we had the customer record service in place as part of our enterprise architecture, our teams could build it in two months. It's our Google, and the customer service representatives love it."
But there is such a thing as too much popularity. "When the customer record service became available, developers just started grabbing it," he recalls. "But they forgot to tell people on the back end that they were going to multiply the load on their servers by 100 to 1000 times. Finally, we just had to cut it off."
This forced Kheradpir to recognize that his growing stable of services needed the governance inherent in EA. So his architects created a repository on Verizon's intranet where the services are created, published and managed. Anyone can look at the services - such as credit verification or address validation - but to work with them, you need clearance from the EA group and IT, which considers the needs of the project and the load it will place on the infrastructure. The group then negotiates service-level agreements with the business and determines who will pay for the use of the service - no easy feat.
The enterprise architects have incorporated services into the initial architecture review process too. Kheradpir found that project managers were skipping opportunities to build services during the application development and integration stages of their projects. It was viewed as extra work. So Kheradpir made it a condition for the review process. "We had to give incentives to developers to develop the Web services," says Kheradpir. "When they say they want to develop a certain functionality, we say: 'You can do that, but you have to build a Web service also.'"
Though the developers grumbled at first, they eventually saw that everybody wins with a rapidly expanding repository of services. "This is going to be our strategy for enterprise architecture," says Kheradpir. "Now developers can go to the Web site and grab a service and start coding the higher-level application they need, rather than spending so much time at the integration and infrastructure level."
What You Need to Know About SOA
Services require a new kind of architectural thinking. Services are more like software products than they are coding projects. They have to appeal to a broad audience, and they need to be reusable if they're going to have an impact on productivity. According to Frank Barbato, enterprise architect for Lydian Trust, to get developers, who generally like to do things on their own, to use services, "you have to show them who else is using it and the track record; you're selling it to them almost like they were an external client".
Planning - not just with IT but with the business - is critical. The first big issue is what SOA geeks refer to as granularity. Early forms of services were defined at too low a level in the infrastructure - "print" or "save" are simple examples - to interest the business. The new generation of services are being defined at a higher level; they describe a chunk of the business and have value for it too. For example, "credit check" has value not just for programmers who want to use that code in another application, but also for businesspeople who want to use it across multiple products - say, car loans and mortgages - or across multiple businesses.
But defining the right level of granularity is harder than it may seem. At T-Mobile, Moiin tries to start at the highest possible level of granularity, and then work his way down. That way, the first service becomes an anchor and guide to the next level of services. For example, T-Mobile built a high-level service called "send a message". Since then, the architecture team has built more granular services, such as "send an SMS message", to send messages in a specific format to different devices (mobile phones, pagers) that customers use to tap into the T-Mobile network. With this kind of big-to-small methodology, Moiin avoids building services that no one needs.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.