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 4
Page 4 of 6

CIOs we spoke to are divided about whether the traditional architectural exercise of mapping every server in the company is worthwhile. Indeed, for some companies, especially big, decentralized ones, it may be impossible. Mickey Lutz, CIO of one of those large, decentralized companies, Cendant Travel Distribution Services, is "not a fan of the big, broad mapping exercise." His compromise? Map only as projects demand it. "We had a segment of the business that did the mapping exercise for their area, but it was project-driven"; they were creating some Web services and needed to know where all the applications and data were. "Architects can't be seen as sitting in an ivory tower," says Lutz, a former architect. "You have to get out into the project teams and do the mapping as the business needs it."

This kind of sensitivity to the needs of the business is what separates the new, more effective EA implementations from the old, IT-centric efforts. "In the old days of our enterprise architecture team," says Godfrey, "there was a view that you want one billing system across the company, no matter what. But it doesn't always make sense to force everybody onto one system. The enterprise architects need to know when to compromise and when to put their foot down."

At Cendant, which provides approximately 47,000 travel agencies with schedule and pricing information, Lutz and his architects have learned when to compromise. If, for example, speed to market is critical in developing a new product, Lutz's architects will skip the review process. New ideas will sometimes get a pass so that project teams can feel free to make frequent changes. "We are not rigorous on architecture for architecture's sake," he says.

Pushing the business in a direction it doesn't want to go can kill an EA team. "You have to create influence, not just authority," says Jeff Gleason, director of IT strategies for the Financial Markets Group at insurance company Aegon USA.

To build that influence, architecture groups need to connect with the business strategy of the company. One way to do that is to create a higher-level enterprise architecture committee (with business representation) that oversees the enterprise architects. Another is to devote a portion of architects' time to consulting with businesspeople about the IT projects they'd like to see. Whether through formal governance mechanisms or informal meetings with businesspeople, the enterprise architects are the CIO's strategy research group. The CIO gathers the feedback from the architects and uses it to build links between IT and the business.

And the biggest of those links is services.

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.

Related:
1 2 3 4 5 6 Page 4
Page 4 of 6
NEW! Download the Fall 2018 digital issue of CIO