Interviews

GM CTO Tony Scott tells how his IT group achieves simplicity and ROI by mapping business functionalities and requirements to its IT systems. But Scott never lets his business peers know it's called "enterprise architecture".

For years General Motors has been working to reduce the complexity and cost of IT across the enterprise, adopting standardized technology wherever possible. Now GM has rallied its IT staff around enterprise architecture, which is as much about business goals and processes as it is about technology platforms. The goal is to turn the lumbering GM giant of the past into a more limber, quick-to-pounce business in which corporate decision-making is informed by timely data, not confused or confounded by system complexity. Leading the effort is Tony Scott, chief technology officer of GM's Information Systems and Services group. In this interview with CIO, Scott explains GM's take on enterprise architecture, how he's leveraging it, and why he doesn't dare call it "enterprise architecture" in front of the company's senior executives.

CIO: Many people think of enterprise architecture as IT standards and platforms that span the enterprise. But at GM you have a different interpretation. How would you characterize it?

Scott: We think of enterprise architecture as the process we use for fully describing and mapping business functionality and business requirements and relating them to information systems requirements. We describe the data, the actors, the places, the systems, the time frame and all the other elements of the business requirement.

There are various levels of enterprise architecture. At the highest level are business functions: We're going to design cars, sell cars, manufacture cars and finance cars. Then at the next level you have, for example, the manufacturing process. You break that down into steps -ordering raw materials, transporting those raw materials and so on. And then each one of those could be broken down further. Eventually you get to a very low level of what a system has to do, which might be, in the manufacturing example, to take an item out of inventory and then decrease the quantity available by one.

CIO: So it's the process of first mapping the business requirements and rules in order to inform IT investment decision-making?

Scott: Yes, but it's not only a process. It's a discipline that contrasts with the customary approach to systems development. Do you know of the Winchester Mystery House in San Jose, California? Sarah Winchester, heir to the Winchester Rifle fortune, built this thing over nearly 40 years, adding on bit by bit. Room after room after room, stairways that go nowhere, doors that open into walls. The house ended up being not very functional. It wasn't for lack of money or highly skilled workers; it was lacking an architectural plan. Well, the information systems in a lot of companies are Winchester Houses.

CIO: Can you give me an example of how the enterprise architecture process at GM eliminated Winchester-like complexity?

Scott: Last summer a situation made us realize that we had more than a dozen SAP systems deployed all over Europe, Asia-Pacific, Latin America and the Middle East. And everybody was on a slightly different template, a different release, and they all were using it in slightly different ways. GM has a goal to have common global systems, so our desire is to get to one version of SAP, with common functionality for all those multiple deployments. Our enterprise architects interviewed the people, looked at each implementation and documented the important elements. They came back in just four weeks with a visual representation of what we had, where we had it and what business functions we were satisfying. From a management perspective, we can now look at this and say: This is our as-is picture. Now how do we walk from this to what we want in the environment? What has to change?

CIO: That should help you reduce complexity, but how will it help GM get to market faster?

Scott: We don't ever want IT to be the thing that holds GM back. And to the extent that you have complexity in your IT environment, you tend to make it more difficult to change or take advantage of new opportunities. Companies that operate without an architectural approach end up like Gulliver, tied down by tens of thousands of Lilliputian strings and wires. If he's going to move, you have to cut 10,000 strings. If the company practises enterprise architecture, you will have fewer strings to cut and more freedom of movement.

One of the best places that we put this to use was over at OnStar. We worked with them, trying to understand the new customer services they were going to put in place. We created a map of the business activities and which IT systems, either current or proposed, would fulfil those activities. Which systems will provide enrolment for OnStar subscribers? Which ones will provide support for emergency calls?

We discovered some gaps where OnStar had assumed that there was already a certain system functionality that we didn't have yet. Then there were also a couple of cases where there were overlaps - where the same function was provided in two different systems - requiring us to choose which system should actually provide this functionality. Without this enterprise architecture process, we would have gone much further down the development road without realizing these problems. We probably would have paid systems integrators to develop those systems, and only when we got to testing or even to deployment would we have discovered these gaps and overlaps. So by engaging this process up front, we got to the goal line faster.

CIO: Has there been any internal resistance or scepticism about this concept?

Scott: A lot of the objections I hear, particularly among more senior leaders, is that enterprise architecture is a boil-the-ocean process: We're going to send people out for training, and then we're going to produce reams of paper, then contemplate our navel - and it will be several years before there are any tangible results. In fact, we're not going to try to map all of GM; we're going to do it in bite-size chunks. In all the architecture projects we've done so far, we've never gone top-to-bottom, left-to-right and mapped every piece of information at every level of detail. We've focused on those areas that we thought provided the highest value to GM. So most of these efforts have been measured in weeks, or in some cases days.

CIO: So have GM's business executives embraced the concept?

Scott: Yes, but they don't know it's called enterprise architecture. They think it's a discussion about how we get common, global business processes and systems in place across GM. We don't go around branding it enterprise architecture.

CIO: Why not?

Scott: The world is sick of big IT things that don't work. There's always some big thing that's coming along that's going to save the world, whether it's ERP or Web services or wireless. People will view this as an IT thing rather than a business discipline. There are IT tools that assist you in doing enterprise architecture, and I worry that people will get the tool confused with the process, or assume that you can only do enterprise architecture if you buy this tool or that tool. And that's just not true.

CIO: GM and your competitor DaimlerChrysler are among the co-founders of the non-profit Enterprise Architecture Interest Group. What's this organization doing?

Scott: This is an awareness activity and also a knowledge-sharing, practitioner-networking effort. We're collecting best practices, methods and tools for enterprise architecture. We've formed a meta-model describing 12 universal, reusable elements of enterprise architecture, including locations and logistics, business-cycle times and workflows. With these, you can build a process blueprint for any enterprise. (Go to www.eaig.org for more information about this organization's activities.)