Building the Foundation; Avoiding the Traps
The grail of EA is to create a map of IT assets and business processes and a set of governance principles that drive a constant discussion about business strategy and how it can be expressed through IT. There are many different suggested frameworks for beginning an enterprise architecture effort (see "How to Get Started", page 80). Most contain four basic slices:
- Information architecture: identifies where important chunks of information, like a customer record, are kept and how people typically access them.
- Infrastructure architecture: the jumble of hardware and networks.
- Application architecture: maps the relationships of software applications to one another.
- Business architecture: outlines the company's most important business processes.
This last piece is the most important, but also the most difficult to do. Even if IT can get businesspeople to sit still long enough to go through this exercise, it's often hard to get them to agree on which processes are most important.
And once IT gets the businesspeople to focus, then comes the bad news. EA is expensive - between $650,000 and $1 million per year for four to six full-time architects, and $100,000 for outside consulting to get started, estimates Forrester.
But enterprise architects are the future of IT. Grounded in technology but fluent in business, they should be crack consultants, patient diplomats, and able to provide the bridge between IT and the business that most IT departments today sorely lack.
Value - and Value Only - Sells EA to the Business
When companies form architecture groups, the first thing they should expect is resistance, according to Hossein Moiin, vice president of technical strategy for T-Mobile International, the wireless phone company. T-Mobile's group of enterprise architects reviews projects to make sure they are soundly designed, meet business objectives and fit in with the overall architecture. "It's a challenge to get buy-in," says Moiin. "Businesspeople - and some IT people - see it as a bureaucracy. You need to give examples of the value."
For example, one T-Mobile project was to create a service that would let subscribers customize their ring sounds. The project group assumed that it would have to create most of the software from scratch. But the architecture group found code that had already been written elsewhere at T-Mobile that could be used as the basis of the development effort. The reuse reduced the development cycle time by a factor of two, says Moiin. "Show a few of these to the troops and they become convinced that architecture review is a good thing," he says.
At insurance company The Hartford, the review process helped prevent a new online agent portal from being built in an architecture that wouldn't scale with the business's plans for the system, says Ben Moreland, assistant director of application infrastructure delivery. "We anticipated adding more functionality to the portal and a higher volume of users than the project initially predicted," he says. "By doing the review early on, we were able to scale up the application design before it became a problem."
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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.