Like a visit to the food court for an impulsive meal of wontons, pizza, soda, fries and a cookie, IT without an architecture to guide it usually results in indigestion and an empty wallet. Handhelds for the sales force? Why not! Oracle for accounting and Informix for customer support? Sure! The temptation to gobble up new technologies with little thought to how they'll work together has resulted in catastrophic maintenance, integration and support costs-not to mention headaches. The average large organisation has a whopping 150 different applications, tools and utilities accessible from the desktop (midsize companies have about 100), according to Giga Information Group. In an effort to stop the madness, many CIOs are developing enterprise IT architectures: Grazing at the food court is officially over.
Architecture came in vogue in the early '90s, after a gluttonous decade of IT spending and client/server disasters forced CIOs to adopt a more disciplined approach. Think of architecture as a blueprint: It defines the direction and priorities of IT in an organisation, linked to business goals. Architecture also establishes standards and outlines policies for the acquisition of new technology -- such as, all systems must support database technology from vendor X in order to ease integration. What architecture isn't is technology and equipment (that's the infrastructure). Pity the poor CIO who starts a discussion about Unix versus NT in a meeting with other vice presidents, only to see eyes glazing over around the table.
How CIOs begin the discussion, develop the plan and sell it to the business can make or break these all-encompassing projects. We talked to several CIOs who are happily leading their organisations down the architecture path and they unanimously agree: Architecture requires senior-level commitment, flexibility and a long-term view.
Needless to say, corralling business people together to listen to what they may perceive as some esoteric plan, much less approve it, is an exercise in patience. The concept is complex, the enterprise even more complex, and IT standards are a bear to implement across large, diversified organisations.
There are cultural issues too. Department heads and IT staff alike balk at the idea of conforming to a set of rules and standards after years of developing and buying whatever their budget allows. Finally, architecture projects can cost millions of dollars upfront for benefits that don't come to light for years.
These benefits include huge long-term savings in support and integration costs in addition to better alignment with business strategy and more consistent IT processes, notes Marc Cecere, senior analyst with Giga, who specializes in IT management and architecture planning. For instance, a company that implements a single Web-based groupware product can more easily give its users access to its knowledge and resources across the enterprise. A stable architecture can also help companies develop new IT-based products and services faster as the business changes. The following five steps are a compilation of best practices from three companies in the middle of major enterprise architecture projects: PG&E , Lawrence Livermore National Laboratory and Toyota Motor Sales USA Start with a Smile and Shiny ShoesBefore you can even worry about selling an enterprise architecture plan to top management, you first have to get support from the people most affected. When Dave Cooper was promoted as the first CIO of Lawrence Livermore National Laboratory in fall 1997, he was dismayed at the lab's disorganized, ad hoc approach to IT. The 30-year veteran of the NASA Ames Research Center made his first goal to centralize IT and develop a common architecture across the lab's 10 major research divisions (called directorates). With so many bureaucratic fiefdoms at the lab -- a world-renowned research powerhouse for nuclear science, energy and biomedicine -- Cooper wasn't surprised when the 10 associate directors recoiled at the prospect of losing control over IT spending.
Cooper explained to the directors that without standards and a process for monitoring them, the lab could not reduce support costs, benefit from volume purchasing on technology or anticipate future needs. "They didn't realise that you need to plan ahead for things like wiring and bandwidth," Cooper says. He then extolled the virtues of having easier access to information by eliminating most of the lab's several dozen legacy systems. Staying nimble and keeping costs down is important for the lab's post-Cold War strategy, as it competes for government funds with other Department of Energy labs including Los Alamos National Lab in New Mexico.
Even after the directors signed off on the idea, they balked at the price tag.
Cooper asked for a budget of US$1.8 million for the first year, to cover staffing costs and investments in new technology. So Cooper gave the 10 directors the hard sell: "I said they were already paying for it, and if we couldn't save some of that $250 million (the lab's annual IT budget) they might as well let me go." The project got approved.
Add Staff
Planning for enterprise architecture is not a one-person job -- particularly if your company has not documented its business processes and goals well. That's a lesson the IT department at Toyota Motor Sales USA in Torrance, California, learned the hard way.
When CIO and Group Vice President Barbra Cooper joined Toyota two years ago she saw an IT organisation that was 10 years behind the technology curve and totally disconnected from the business of sales, marketing and distribution of cars. So she reorganized the IT department, created an eight-person standards and infrastructure group from existing staff, and appointed Architecture Manager Karen Nocket to lead the company's first-ever architecture project.
Nocket attended a Meta Group three-day workshop on architecture planning but soon realised she couldn't make any progress as the lone wolf. After two months of trying to gather information on Toyota's business processes and drivers, Nocket got little cooperation from the business or IT. "I threw up my hands and said, 'I can't do this,'" she recalls.
Humbled but not deterred, Nocket won approval to hire three architecture experts from international consulting firm Grant Thornton to jump-start the process. Cooper says the consultants helped Toyota get organized and communicate and market the concept to the right people, whether within or outside IT. This internal marketing effort helped energize the some 20 IS staffers who then volunteered or were recruited (some part time, some full time) to sit on the architecture team and review groups for different technology areas like networking and applications. The groups spent four weeks taking inventory of Toyota's systems and expertise, and they completed the first part of Toyota's architecture plan, outlining application strategy, in February 1999. The next part (determining strategy networks, operations and platforms) will begin this October. Nocket recently hired a full-time staff person to help coordinate the review process as the plan is updated continuously.
One of the CIO's most important jobs is choosing the right leader for the architecture project: ideally, a superb communicator with a broad technology background and the ability to distill a high-level view of the business, says Anne Lapkin, chair of the international architects workgroup and certified enterprise architect of the finance sector at Cap Gemini America. The CIO's job during the process is to provide "air cover" by helping the architect ward off political land mines, Cecere says. Many companies (Toyota included) are also creating business technology consultant and relationship manager positions: These people attend business meetings and facilitate the exchange of ideas between architecture folks and the vice presidents.
Mix In Intrigue
Sure, executives would rather be inking new deals, meeting with customers or even mowing the lawn than talking about architecture, but they have to be involved in the discussion from the outset. The point of having an architecture is to better support business goals, after all. John Keast has one rule for keeping execs from yawning: Don't talk technology but capabilities-like improved customer service tracking. If technology comes up, keep it simple.
"You have to use words that are understood by the business, like 'Internet technologies,' not 'Java' and 'ISDN,' advises Keast, the CIO of San Francisco-based PG&E, a $19 billion national energy company.
Keast leads IT policy and strategy for the holding company's five business units-four wholesale and retail energy divisions (energy commodities trading, retail energy services, electricity generation and gas transmission) and the regulated California utility, Pacific Gas and Electric Soon after his 1998 promotion to the chief CIO job from divisional CIO of its subsidiary PG&E Energy Services, Keast knew the two-and-a-half-year-old company needed to start sharing data and systems among its unregulated divisions to compete in the burgeoning energy marketplace, where it competes in the newly deregulated world against other energy companies like Enron and Duke Energy So last summer he organised three day-long workshops with his divisional CIOs and two executives from each of the business units. During the workshops, which took place over a period of three months, the group discussed high-level business goals and the existing gaps-for instance, the need to manage risk better in the unregulated divisions. In the next sessions, the group decided what IT capabilities and standards were needed to meet the goals-such as a common customer ID so that the divisions could share customer data. In the final session, they discussed a plan for the timing and coordination of the IT projects. Between meetings, Keast kept in touch with participants through phone or e-mail to revisit and revise the group's decisions, a tactic he recommends to ensure everyone is updated on progress.
To help prioritize projects for the '99 budget plan, the group did a cost-benefit analysis for each proposed project and scored them in an index.
The hard work paid off: The 25-project plan and its budget were readily approved in the fall, since the CEOs of the business units had been pre-briefed by the executives who had attended Keast's workshops.
Ideally, architecture planning shouldn't take longer than six months, because after that the business has probably evolved. In more political environments, like Lawrence Livermore, the process can take longer in the quest to reach consensus. Dave Cooper recruited 40 people from every corner of the lab-human resources to weapons design -- who committed 10 percent to 15 percent of their time to the architecture project.
As at Toyota, the group divided into working groups by technology area and worked on developing 10-year plans for new systems and capabilities. Dave Cooper says the groups were a bit "unruly" at first. "It took them a couple of months to thrash things out and get to know each other," he recalls. The problem wasn't so much bickering but that the groups didn't have a good architecture model to follow and had to create one from scratch, explains Dick Watson, chief scientist in the lab's computation directorate who chaired the architecture committee.
Later, the committee posted the proposed standards on the lab's internal Web site so that all 8,000 employees could provide feedback. Dave Cooper or one of the committee members responded to every comment-e-mail and presentation software were hot topics-and, on occasion, made changes to the standards as a result. For instance, feedback from the lab's strong contingent of Macintosh lovers led to today's dual Mac/PC environment. "People really like the opportunity to be heard," Cooper observes. A month before the plan was presented to senior management, he met with key stakeholders to rally support.
The entire process up to the publication of the final report in July 1998 took 14 months.
While Dave Cooper admits the process was slow, he says the participatory approach was the only way the project would fly at the lab. The directors are like presidents of their own companies, Cooper sometimes jokes outside the office; like many of the people who've been around since the lab was building bombs for the Cold War, they don't like to be told what to do.
A Dash of Flexibility
Even with ample preparation, organisation and business participation, there will always be sticking points about architecture. A word to the wise: Choose your battles carefully. "IT gets stuck in controlling costs related to hard-coded standards, but users will learn to get around your standards," Toyota's Cooper reflects. She says this often occurs when technology-savvy employees use their expense budgets to buy software, like a favorite scheduling system, and install it without the knowledge of the IT department.
During the process, Cooper's job as CIO was to sell the value proposition to the business in terms that made sense to them. For one, having a blueprint for IT would allow the world's fourth largest automaker to respond more quickly to market changes, such as e-commerce initiatives that could easily be bogged down by debates over which platforms and tools to use. "The primary objective is to head off a compounding factor of complexity and spiraling costs across the organisation," Cooper says.
But she also understands that users need some flexibility. Her department introduced a standard hardware and software configuration for the desktop, but users can still request add-on applications like desktop publishing or marketing software. Generally, Cooper says, there has been little resistance to the new standards, but she attributes this in part to Toyota's Japanese-style culture of conformity that shows up even in America.
Meanwhile, over at the lab, Dave Cooper wrestles with people who want to buy "aardvarks" (his term for nonstandard stuff). Users may purchase nonstandard desktop configurations (for engineering, administration and so on), but they will pay higher maintenance costs because these configurations are not covered under the master maintenance contract. "I'm not a policeman here," he says matter-of-factly. "I'm just trying to make things easier for everyone and save money for the lab." However, not all standards are negotiable-like the Eudora e-mail system that replaced several different e-mail packages. More than a year after implementing it, Dave Cooper is still fielding gripes. "I was not a popular guy, but I'm not against making these decisions if it's right for the lab, and this one has been."Balancing architectural discipline with flexibility is more a problem with deeper roots than personal preferences. "It's all about the loss of control," Keast remarks. A decision last year on hardware procurement took four weeks of haggling among the divisional CIOs.
To keep tensions at bay, Keast and his team will standardize only in areas that lower costs, provide greater efficiencies and/or fuel competitive advantage.
For instance, the company has standardized on SAP Financials in order to develop the integrated bill for customers. In others areas, like desktop hardware, Keast doesn't see the value of sticking with one vendor. Choosing two or three, he says, minimizes the risk of relying on a single company and maintains pricing leverage. As a rule, architecture shouldn't be so rigid that it slows down projects or prevents companies from capitalising on new technologies quickly. For instance, Lawrence Livermore's Cooper created an IT group called Tech Watch, whose members keep track of emerging technologies for possible deployment.
Voil! A Recipe for Consistency
Creating an architecture is not a one-time banquet, but a long-term process that needs constant attention. A good way to ensure that people take architecture seriously is to create a written plan outlining the goals, standards and policies-updated annually, at the least, with print and online versions. These documents help communicate and sell the plan to senior management and other stakeholders, and they can be used later as a procurement guide or to help IT with technology decisions during projects.
But a document won't guarantee compliance, much less excitement, for architecture. Keast is considering a bonus and incentive plan for the IT staff related to meeting certain standards objectives. Carving huge architecture projects into manageable chunks is another way to help assimilate big change in the culture: Cap Gemini's Lapkin suggests beginning with a single pilot project in a specific division.
Another challenge that threatens to bog down progress in enterprise architecture is the increasing demand by senior management for ROI. Analysts like Cecere believe that CIOs are going to have to deliver measurable results for architecture. Unfortunately, metrics for doing so are immature, and many large companies have not done a good job of tracking IT costs across the enterprise-which makes comparing the pre- and post-architecture worlds tricky.
A more realistic task is to measure ROI of the resulting projects. Dave Cooper has thrown management a few carrots: an estimated savings of $2 million from standardizing and centralizing desktop systems, another $2 million through volume purchasing, and reduced support costs by standardizing on Netscape's browser.
Beyond saving money, these CIOs are pointing to other, less tangible benefits.
At Toyota, IT is finally getting some respect after Barbra Cooper made it a point to involve the business in her long-term plans. Nocket was thrilled to learn that she has been invited to sit on Toyota's strategic planning committee and says the word architecture has begun to show up on the company's balanced scorecard reports.
Keast says architecture is already making a difference at the emerging energy giant. His staff recently completed a project that allows the company to aggregate financial risk of customers across business lines. Having the standard customer ID previously defined eliminated squabbling between the business units. It's these small wins that keep Keast-and the business-intrigued about architecture: "Business blows hot and cold on this.
You have to keep the business feeling that they're contributing and you're bringing them some value." Put it in WritingThere are no hard and fast rules for writing an architecture plan -- except that it must be legible and digestible for the business people who have to read it. "The document shouldn't be too thick, and it should clearly illustrate the function of each technology in terms of the business it supports," explains Anne Lapkin, chair of the international architects workgroup at Cap Gemini America. Lapkin suggests breaking the report into business areas -- like dealerships, parts and service for a car manufacturer -- rather than by technologies.
Marc Cecere, senior analyst at Giga Information Group , says the business case is the most important piece. This section discusses the current IT environment and problems, shows what other companies have done to solve it, paints a picture of the future environment, and includes benefits and ROI. The business case should also go over potential roadblocks and expectations of management during and after implementation. Cecere includes the following components when helping clients design their plans (examples taken from Lawrence Livermore National Lab's 1998 architecture report): Vision StatementExample: Easy access to the right information, for the right people, at the right time, at the right place, for the right cost.
Business case Example: Reduced support and training costs, increased effectiveness by sharing infrastructure and faster response by IT to business needs.
Principles or guidelines Example: Information is safeguarded on a risk-defined basis.
Standards listed by technology area and service level. For instance, compliance with the "gold standard" for desktop PCs results in a higher level of IT support. Example: Web-based user interfaces for all server-based applications.
Process for getting new projects or technologies approved. Example: All new or revised standards should be submitted to the Stewardship Body (a lab committee of permanent architecture staff and departmental advisers).
Contact information for architecture team. Note: The lab's report also includes a helpful glossary of technical terms like distributed computing and DBMS.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.