A New Blueprint For The Enterprise

Enterprise architecture is not just about mapping and standardizing hardware and software anymore. Now it's about services, events and-get this-good old ROI.

1 2 3 4 5 6 Page 5
Page 5 of 6

"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 1,000 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 website 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, auto 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 (cell 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.

Related:
1 2 3 4 5 6 Page 5
Page 5 of 6
The CIO Fall digital issue is here! Learn how CIO100 award-winning organizations are reimagining products and services for a new era of customer and employee engagement.