Reference no: EM131052729

CASE

When technology infrastructure lines up with business projects like musicians in a marching band, you know you have a good enterprise architect on staff. Enterprise architecture focuses on four crucial C's: connection, collaboration, communication, and customers. Imagine needing to manually log onto five different systems to create and track an order, or spending 20 hours to research a project because you didn't know that the information already existed in another department. These situations result from fragmentation and siloed thinking; the goal of enterprise architecture, on the other hand, is to create unity. Enterprise architecture's goal is IT that enables business strategy today and tomorrow, says Peter Heinckiens, chief enterprise architect at Toyota Europe. "The 'tomorrow' part is especially important," he says. The enterprise architect must map, define, and standardize technology, data, and business processes to make that possible. This means that the architect must have both a macro and micro view: It is necessary to understand the business strategy and translate this into an architectural approach (macro view), but also be able to work with individual projects and deliver very concrete guidance to these projects that focus on the suc cessful delivery of the individual project within that macro view. "The enterprise architect transforms tech-speak into the language of business solutions, and he knows what technology is needed to enable business strategy," says Heinckiens. In other words, an architect knows how to bridge silos. An oft-used metaphor compares the enterprise architect's role to that of the city planner, who also provides the road maps, zoning, common requirements, regulations, and strategy- albeit for a company, rather than for a city. And this role is increasingly important as enterprise architecture itself becomes more important. "Enterprise architecture's roots are in the desire to serve what is best for the enterprise versus the individual department or project," says Andy Croft, Campbell Soup Company's vice president of IT-shared services. Croft, who has the enterprise architect role at Campbell's, speaks of the days when incompatible e-mail systems made employees within the same company unable to share information via e-mail. Each department thought it needed its own brand of PC-even its own network or security system. Finally, Croft says, "People lifted their heads and thought, maybe it's more important to be able to work together rather than [sic] me having the 'best.'" Enterprise architecture gained traction from the bottom up. That siloed view on projects may come in the form of "I want to use this package" or "I want to build this application," according to Heinckiens. As an architect, he advises, it's important to take a step back: Try to understand what problem the proposed project will solve. Is there already a solution that covers the proposed area being researched? Does the proposed project fit into the wider picture? "Structurally, business units are silos-and therefore often have a limited view-but the enterprise architect ensures that the pieces of the wider-picture puzzle fit together," says Heinckiens. As an illustration, some projects use data that nobody else in the company will be interested in, whereas other projects use data that are useful and relevant to everyone in the company. It is the enterprise architect's job to figure out how to make the latter type available to the rest of the company, and one part of that task is creating compliance standards. "It is important that this discussion takes place," says Heinckiens. "Then you see other discussions start to happen." For example, who owns this data? Who should receive permission to access this data? What is a customer? For the marketing department, after-sale department, and finance department, the definition of customer is totally different, even though they refer to the same person. In many companies, this process is ultimately formalized. At Campbell's, it's called a blueprint. Before a new project can be started, each technology area must review a proposed project to ensure that it fits into the overall strategy. Achieving that impressive lockstep between business and IT takes time and practice, of course. Not only that, but an enterprise architect must be a voice that many kinds of people can understand, says Tim Ferrarell, CIO and senior vice president of enterprise systems at W. W. Grainger, a $6.4 billion distributor of heavy equipment. Ideally, Ferrarell says, this person "can think at a strategic level and all the way down to the operating level and understand how to move up and down that chain of abstraction," he says. "And know how to deal with conflicts and trade-offs." Is that all? Actually, no. That person also has to gain the confidence of the senior leadership team, he says. Execs must believe that the enterprise architect understands how the company works, where it wants to go, and how technology helps or hinders, he says. Then, effective working relationships can bloom. In 2006, Grainger went live with a companywide SAP project: 20 SAP modules and 30 additional applications that would touch 425 locations. To help guard against what could go wrong in a big-bang cut over, Ferrarell took his team of about 20 enterprise architects off their regular jobs and assigned them to design and integration roles on the SAP project. The SAP implementation was such an all-encompassing program that it made sense to repurpose the enterprise architects into key roles in the project. Their broad business and technical knowledge made them very valuable team members, says Ferrarell. Grainger's senior business-side managers knew these architects and their business savvy firsthand, he explains. The trust was there, which helped get IT the intense cooperation needed during and after the complicated launch. Their architects played a significant role, not only in shaping the need for completion of the ERP project, but in ensuring that its design would enable their business requirements. The SAP project succeeded, Ferrarell says, in part due to the institutional knowledge and business-IT translation skills the enterprise architects brought to it. Other companies, though, have to be convinced of the enterprise architect's criticality. Sony Pictures Entertainment launched an enterprise architect role modestly in 2002, focused at first on technology issues only, says David Buckholtz, vice president of planning, enterprise architecture and quality at the media company. He had to start small: Sony Pictures Entertainment didn't even have a corporate wide IT department until the late 1990s, Buckholtz says. The company grew from acquisitions and other deals that parent company Sony Corporation of America made in the 1980s and 1990s, such as the acquisition of Columbia TriStar movie studio ( The Karate Kid and Ghost Busters) and the acquisition of Merv Griffin Enterprises ( Wheel of Fortune and Jeopardy ). "We're in a creative industry and people made a lot of decisions on their own," he says. Hence, no central IT until relatively recently and no strong belief in the importance of central IT, he says. Buckholtz was hired from General Electric to start an enterprise architecture team because Sony Pictures wanted more efficiency and savings from IT, he says. At first, he concentrated on classifying existing and future technology investments. Categories include technologies in development where Sony is doing proofs of concept; technologies in pilot; current and supported; supported but older versions; those headed to retirement; and those that are obsolete and no longer supported except "under extreme duress," Buckholtz says, laughing. He began this way to demonstrate that IT could be businesslike: investing well, conscious of risk, and planning for the future. "This is how you plan enterprise architecture when you don't have business support yet. We had to build up to that." Once the architecture group has the enterprise IT house under control, it can look for ways to work with different business technology groups to build credibility beyond bits and bytes, he says. One technique Buckholtz used was to install architects in different business groups to work on projects on business turf but using IT's budget. A free trial, in a sense. By 2005, Buckholtz's group had started a high-profile project with the digital media team to map out how Sony Pictures would digitize content for downloading to mobile phones and other devices. He counts it as a success that the digital media group continues to use that road map today. "We identified high-value work and we were all committed to it," he says. "It was not a group off somewhere, passing down standards." As the economy tightens. Sony Pictures must make its distribution chain as efficient as possible, he adds. Movies, after all, are a discretionary expense for consumers, and if they pull back on luxuries, Sony Pictures will feel it. Enterprise architects continuously reinforce to business-side counterparts the expected returns on IT projects as the temptation to cut spending grows. "We make sure we close the loop and quantify hard dollar costs and benefits for the CFO," Buckholtz says.

CASE STUDY QUESTIONS

1. What does the position of enterprise architect entail? What qualifications or experiences would you think a good enterprise architect should have? Support your answer with examples from the case.

2. Consider the different companies mentioned in the case and their experiences with enterprise architecture. Does this approach seem to work better in certain types of companies or industries than in others? Why or why not?

3. What is the value derived from companies with mature enterprise architectures? Can you see any disadvantages? Discuss.