Bill Godfrey, CIO of Dow Jones, remembers how his first enterprise architect rode into town in 1999—confident, aggressive; one could almost hear his spurs jingle-jangle. “I started by hiring a chief architect—a sheriff with the big badge and the big chair and all the PowerPoint decks that money could buy,” Godfrey recalls. “It proved to be untenable.” 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.Text
EA “Version 1,” as Godfrey now calls it, didn’t accomplish his goal of creating a unified IT architecture (standardized hardware and software systems) across all of Dow Jones’s business units, with tighter links to the business and its strategy.
It didn’t work, Godfrey says, because he invested too much power in one person who had too much to do. When the architect/sheriff looked for cooperation from the different business units, he got static. They saw him as a cop who prevented them from using the technologies they thought they needed.
“It didn’t get into the information flows of the business enough and was seen as an ivory tower project,” says Godfrey.
So he adjusted. He abolished the chief architect job and, in 2001, designed a federated structure of architects from the different business units, working together to share best practices and coordinate architecture decisions across the company.
Godfrey still wanted the same things, but he replaced the big badge and PowerPoint slides with cooperation and brown bag lunches. That didn’t work either.
The architects were co-opted by the business guys who demanded this, that and the next app for their lines of business. “The architects couldn’t create enough time to work on enterprise architecture,” Godfrey recalls.
Last June, Godfrey, a determined man, launched Enterprise Architecture Version 3.0, which combines elements of both approaches. He created what he calls the Architecture Zoning Board, run by a vice president of IT who reports directly to Godfrey, and three architects and seven senior technologists who manage the still-developing architecture. (For more on managing an enterprise architecture, see “EA Needs Governance,”)
Dow Jones CIO Bill Godfrey notes that “it doesn’t always make sense to force everybody onto one system.”
Godfrey has invested the group with a lot of authority. Anyone at Dow Jones who wants to spend more than $250,000 on a project must get approval from the architecture group. To get the money, project leaders have to submit to a review process in which Godfrey’s architects decide whether the project’s goals and technology fit into Dow Jones’s overall business and technology strategy. Some businesspeople—and even a few IT people—grumble that Godfrey has replaced the cop with an entire precinct, but at least the rules and the goals (reduce costs, increase standardization, speed development) are clearer now. Godfrey says it’s too early to tell whether the third time is the charm, but he’s hopeful: “I believe we finally have the right balance and that 2005 will be the year we get EA to bite into capital planning, project processes and culture.”
In a time when enterprise architecture seems to be on almost every CIO’s lips, Godfrey’s Version 3.0 looks like many other mature enterprise architecture efforts. Most have a small central group (Forrester found that 84 percent of companies it surveyed had centralized enterprise architecture groups of fewer than 10 people, regardless of company size). The groups dangle a carrot (money) and wield a big stick (project review). Their goals are to promote alignment, standardization, reuse of existing IT assets, and the sharing of common methods for project management and software development across the company. The end result, theoretically, is that enterprise architecture will make IT cheaper, more strategic and more responsive.
And increasingly, whether by dint of desperation or by a cool assessment of what’s recently become possible, CIOs—and their organizations—are buying into the theory.
How EA Came in from the Cold
Enterprise architecture has long been the concept that dared not speak its name. Some CIOs go to great lengths to avoid using the term with their business peers for fear of scaring, alienating or simply boring them to death. But companies (such as Dow Jones, T-Mobile and Verizon) that have stuck with it are beginning to reap the savings, flexibility and business alignment that its proponents have been promising for nearly 20 years.
The concept hasn’t changed much in that time: It’s still basically city planning for IT, an overarching plan of the total data, business processes and IT assets inside a company, how they’re used, and how they should be built and shared.
This has always been a big, difficult and expensive undertaking, and its ROI has often been opaque to the business. Standardizing, mapping and controlling IT assets does not make the business obviously more flexible, capable or profitable. As a result, IT architecture efforts often fail or become completely IT-centric.
But now that’s changing.
Advances in integration technology—primarily intelligent and flexible middleware and Web services—are providing new ways for designing more agile, more responsive enterprise architectures that provide the kind of value the business has been seeking. With these new architectures, IT can build new business capabilities faster, cheaper and in a vocabulary the business can understand.
These advances are giving new life to a couple of old concepts that could inspire new EA efforts and revive failing ones.
The first concept is services, better known today as service-oriented architecture. SOA provides the value to the business that in the old enterprise architecture was rarely more than a vague promise.
The idea behind services is simple: Technology should be expressed as a chunk of the business rather than as an arcane application such as ERP or CRM. Shaygan Kheradpir, CIO at Verizon, estimates that he has more than 200 services sitting in a repository on his intranet, ranging from things like “credit check” to “customer record.”
Businesspeople can call for a service in a language they can understand, and IT can quickly link these with other services to form a workflow or, if need be, build a new application. These applications can be built quickly because complex, carefully designed interfaces allow developers to connect to the services without having to link directly to the code inside them. They don’t even have to know how the service was built or in which type of language it was written.
Lydian Trust CIO John Studdard’s architecture allows him to “promise a new system in days or weeks instead of months.”
The second concept currently driving enterprise architecture is events. Pioneered by telcos and financial services companies, this involves using IT systems to monitor a business process for events that matter—a stock-out in the warehouse, for example, or an especially large charge on a consumer’s credit card—and automatically alert the people best equipped to do something about it. Together, services and events are revolutionizing the design of enterprise architecture, providing the kind of flexibility and value that CIOs, CFOs and CEOs have been looking for (but rarely have found) all these years.
Services and events do not define EA, but they can form its new core. CIOs who build enterprise architectures without a services-and-events approach will miss an opportunity to address the two most enduring—and accurate—complaints that the business has leveled at IT: slowness and inflexibility.
“We can now promise a new system in days or weeks instead of months,” says John Studdard, CIO of Lydian Trust, a bank that has built both services and events into its enterprise architecture design.
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. 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
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.
“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.
The Link Between Services and Events
Events are the eyes and ears of the business expressed in technology—they detect threats and opportunities and alert those who can act on the information. If services make enterprise architectures more flexible and responsive, events make them more alert and better prepared to sense problems before they become disasters (and sense opportunities before they’re lost). Using events to drive architecture design brings IT closer to having a direct impact on the business’s P&L.
And, like services, events can be expressed in terms that businesspeople understand. “CEOs and CFOs are event-driven people; it’s how they solve problems,” says David Luckham, professor emeritus of electrical engineering at Stanford and one of the leading lights of event-driven systems. “When problems get pressing enough, they begin looking at the series of events that led to the problems to see what happened and what they can do about them.”
IT needs to begin architecting systems in the same way, say the event gurus, starting with events that matter to the company (supplier shortfalls, long wait times in the call center) and building IT systems that monitor and respond to those problems.
For example, when the system that monitors a credit card transaction processing system sees a $10,000 charge come in on a credit card with a $2,000 limit, the system sends an alert to a credit supervisor and automatically shuts down the account.
Though, traditionally, they have been viewed as separate technologies, services and events are converging. Because service-oriented applications and workflows are so loosely linked, with developers writing links to services whose design and application composition they may not fully understand or control, developers need to consider events in their designs.
For example, Lydian Trust’s enterprise architects designed a service called “get credit” that is used by several different product divisions within the company for different loan application workflows (autos, mortgages and so on). “Get credit” is a Web service that seeks out credit ratings over the Internet from the major credit bureaus.
One day, one of the credit bureaus’ Web servers went down for hours. When Lydian Trust’s “get credit” service tried to make the call, there was no answer. Because the connection to the server was loosely linked, the system didn’t know what to do. “Get credit” hadn’t been built to make more than one call. So while it waited for a response, hundreds of loan applications stalled.
Loan officers had to work overnight to make sure the applications were completed within Lydian Trust’s promised 24-hour response window to customers. Customers never felt the pain, but CIO Studdard and enterprise architect Barbato certainly did.
“There are many more dependencies in a services environment,” says Studdard. “The system has to be able to deal with the existence of certain events—or the lack of an event—in a way that doesn’t interrupt the overall flow.”
For example, “get credit” is now programmed to keep calling the credit bureaus’ servers for 22.3 hours before giving up. If the service hits a snag, an e-mail alert goes to an IT manager and automatically gets sent to a higher authority if that person doesn’t respond. “This is not the kind of stuff that’s available out of the box,” jokes Barbato.
EA Magic
Very little having to do with enterprise architecture is available out of the box. It is a competency that must be built from within, unique to each company and that company’s culture. But developing that internal capability is critical to bridging the value gap that persists between IT and the business today.
Internal IT groups simply have to become faster, more responsive and more flexible to survive in this era of automation and outsourcing. “If I had a wand and I could wave it, I would make everything happen a lot faster in IT,” says Alan Buckelew, president and CIO of Princess Cruise Lines.
Building an enterprise architecture based on services and events is the best wand Buckelew—or any CIO—could wield today.
–Executive Editor Christopher Koch can be reached at ckoch@cio.com.
Don’t miss related articles, white papers, product reviews, useful links and more! Visit our Spotlight on Data Management