Interview: Jeanne Ross on the New Alignment Target

By Edward H. Baker  |  Posted 12-28-2005

Interview: Jeanne Ross on the New Alignment Target

Jeanne Ross likes to tell a story about an enterprise architect at an investment bank. "He proudly told me that despite the bank's propensity for building siloed applications, the IT people were able to wire things together so that every single transaction was end-to-end. No human being ever touched a transaction. Then he paused and said, 'It's a miracle it works.' The mission of my research," says Ross, principal research scientist at the Center for Information Systems Research at MIT, "is to help companies understand architecture so that they don't have to rely on technological miracles."

Ross is well-qualified to provide companies with that assistance. She began researching the problem of information architecture and governance more than a decade ago, when CISR helped Johnson & Johnson through a period of enormous cultural change, as the company sought to rationalize its vastly diversified operations. The effort, she notes, "started my education on the critical role of the operating model in defining IT and business process capabilities." Among the fruits of her research was "IT Governance: How Top Performers Manage IT Decision Rights for Superior Results," coauthored with Peter Weill and published by Harvard Business School Press in 2004.

Editor Edward Baker recently spoke with Ross about her latest efforts to understand the relationship between corporate strategy, operating models and enterprise architecture. An edited version of the interview follows.

The mantra for years has been to align IT to business strategy. Are you rejecting that view?

I'm not rejecting strategy; I'm conceptualizing it differently. The problem is aligning IT with strategy, when strategy has all these different pieces: markets, products, prices, competitive advantage. There are so many things that make up strategy that it's very hard for a CIO—or for anyone who's trying to understand the capabilities IT needs to build—to align to it.

The operations view is a way of conceptualizing strategy as a fairly stable, longer-term vision, as opposed to an initiative. You have to separate the development of IT capabilities from every new strategic initiative that comes along because those new initiatives just send you here, there and everywhere. If you're going to build agile organizations, you can't build capabilities around every new opportunity. You really have to be thinking in terms of what's not going to change. What's going to change is unknown. What's not going to change is actually fairly predictable. And a company's operating model has to be aligned with the things you feel are fairly permanent in the organization.

The operating model is about who your customers are. It's about what your service model is. It's about integration standardization. Are you going to be a single enterprise, all marching to the same drummer and doing things exactly the same way, and sharing all of your data? Or do you actually picture how you operate differently?

For example, if your company has a solid customer base, and it looks like they are going to be your customers long term, then you can hardwire things into the company that establish who those customers are. Of course, sometimes when you change channels you change the customers. But being able to recognize what you thought was permanent, and now isn't, helps in understanding the scope of the change. So the operating model is just a different way of conceptualizing strategy.

Story Guide: Picking the Right Strategy for IT to Support
  • Strategic Models to Emulate
  • Gain Foresight, Lose Flexibility?

    Next page: Models to Emulate

    Models to Emulate


    Can you describe the four operating models you've pinpointed?

    Consider ING Direct, the online arm of ING Bank. One of the things that have made ING Direct so successful is that it is so clear about its operating model, which we classify as a "replication" model. The company takes a set of services and replicates it everywhere it goes. Just pull the services off the shelf and put them into the next site. And it can do that organically, or after an acquisition. It doesn't matter.

    You hear about ING Direct and you say, "Well, that's a natural. Of course they would do that. Just like Marriott would do that, or McDonald's would do that." But I was fascinated to read a case about Cemex, a Mexican cement company, and realize that they've chosen that model too. They've said, "Cement is something you produce and sell locally. But if you come up with the best processes for marketing and developing and manufacturing cement, those are absolutely replicable all over the world." You see a cement manufacturer using this model, and you say to yourself, this is an operating model with teeth. This is something that has real potential for other companies.

    Or consider MetLife and its "coordination" model. Here's a company with a lot of different product lines, making a lot of acquisitions, so it's got more things going on than it can manage using a replication model. Still, it has to get everything in shape for its customers. It can have some inefficiencies, and some redundancies in the back end, and they will cost money, but they're not going to kill the company.

    So they got that figured out, and then they said, "OK, all our resources go into making this clean enough on the front end that we can meet our customers' needs." That's a coordination model. It's all around integration. And it recognizes that, as nice as it would be to standardize the stuff in the back end, that's not where MetLife can get the most bang for its buck.

    It's a model that works for a lot of full-service financial services companies. It works with pharmaceutical companies too. Pharma companies pretty consistently have independent companies that are really functions—a marketing company, a manufacturing company, an R&D company. And they have to have very smooth transfer of data, for the Food and Drug Administration's sake, if nobody else's. So they've got to integrate that data. But the companies are totally different. It wouldn't make any sense for them to say that their manufacturing unit has to use the same processes as their R&D unit.

    Thinking in terms of operating models also helps companies understand the limits to their agility. UPS is one of my favorite companies. What it did in package delivery was create the ultimate highly integrated, highly standardized company—what we call a "unification" model. And yet—and they're very honest about this—when they first started getting into other businesses, such as logistics, they wondered how they could fit it into their model. They realized it didn't work. You couldn't attach those new businesses to the very same model. They have a very strong unification model for package delivery. But their enterprisewide model is a "diversification" model that's designed to meet the needs of all their businesses.

    What's interesting is that as UPS evolves as an enterprise, it very well may move into a coordination model. There really is a fair amount of data the company can leverage across its businesses. But right now they're adding businesses, they're testing, they're experimenting. Diversification is the only thing that makes sense.

    What's the role of enterprise architecture in aligning to an operating model?

    Enterprise architecture is an organizing logic focused on business processes and IT capabilities. It identifies the way IT and business processes will meet a company's needs for integration and standardization as it goes to market. And the critical components of an enterprise architecture are very different, depending on the operating model.

    How much of that is technology, and how much of it is business processes?

    Those two are not really separable anymore. You have technology infrastructure based on platforms and technologies. But if you try to look at the technology apart from business processes, you miss the point. This gets back to Nick Carr's Harvard Business Review article claiming that IT doesn't matter. If you look at it the way he did, it truly doesn't matter. But to the extent that we look at the technology as an embedding process in the organization that should reflect its operating model, then it matters tremendously in terms of what a company is and is not capable of doing.

    Every company needs to understand, first of all, where it is trying to go and, thus, what kind of enterprise architecture to build.

    Story Guide: Picking the Right Strategy for IT to Support
  • Strategic Models to Emulate
  • Gain Foresight, Lose Flexibility?

    Next page: Gain Foresight, Lose Flexibility?

    Gain Foresight, Lose Flexibility

    ?">

    Is there a risk of less flexibility in aligning to long-term operating models?

    Yes, it's possible, but I think it's a finite risk. Look at Schneider National, a trucking company in Green Bay, Wis. Schneider had a unification model in the early 1990s that put it ahead of the game. But trucking is a highly competitive industry. And the company felt its profits weren't growing the way it wanted. So it decided to get into logistics, a field that was clearly going to be more profitable.

    So Schneider looked at its technology and said, "OK, this is cool. We have very low-cost technology, and we can squeeze every ounce of value out of it." But logistics isn't about standardized data and processes. It's about putting a computer at the customer site and customizing to their needs. The whole model's different. So they had to build that capability.

    As a company, Schneider moved from a unification model to a diversification model that built a parallel capability, and it didn't slow them down at all. Over time, in fact, the company was able to leverage some things from their logistics business in their trucking business.

    I believe they've become far more agile because they're now capable of recognizing that the next strategic opportunity either leverages what they've got in place, which is their lowest-risk, highest-return opportunity, or that there just aren't enough of those opportunities anymore. And then they'll say, "Well, what are we going to do instead?" Then, instead of trying to latch it on to a capability that wasn't developed for that purpose at all, they will just build the next capability. They may do it by buying somebody, or they may do it by starting from scratch and creating something new.

    Is there risk in this method? Of course, because if you don't have the platform in place, you're going to have to get one, and that's going to take longer, and it will take longer to make money on a new platform. If you're just leveraging what's in place, you can be profitable the next day. But I would say such options are less risky than not making up your mind who you are and what makes you different.

    What is the real risk in building these architectures?

    Lack of clarity. If you don't have good management practices, it's not that the architecture gets too rigid or outdated, but that the technologies themselves could get outdated.

    If you can keep a company vibrant by maintaining the fundamental architecture of what's standardized and what's shared—that probably has a very long life. But making sure your technologies keep up with new developments is harder. You can evolve more power into the fundamental architecture as the world and the company evolves, or as your customer demands evolve. But changing those technologies, that's hard.

    Are there any particular new technologies that you see coming down the pike that are going to make this job easier?

    Everything associated with Web services is going to make it easier.

    But it's not easy to take your legacy technologies and convert them to the latest thing. That will be the big challenge, and that's going to give a tremendous edge to newer, younger companies, because they don't have that legacy.

    A lot of my colleagues who do research in the IT field love to study the newest companies and what they're doing. Yes, that's interesting. But the companies with the really interesting problems are the ones with a legacy. Because they are usually really good companies—after all, they're still around. But they will be very challenged. They're going to have to leverage their size, their brands and other things to compensate for the fact that they're not going to be able to move as fast as the newer companies.

    But I think the really good ones are going to find ways. They always do.

    So should we call this article "Alignment Doesn't Matter"?

    Well, that would be one way of stating it. But a better name might be "Alignment Made Easy." Which, of course, isn't at all true. But how we're going to do it is. In other words, it became possible. We're no longer going to try to align with the daily swings of strategy and market conditions. We're now going to align to a clear understanding of how the company is going to survive and grow. And that's a much more powerful concept.

    Right now, IT too often creates sad surprises at companies. The business wants to do something, and IT says, "OK, tell me exactly what you want to do, and I'll have it ready in two years." Instead, IT should be telling the business, "Now you're capable of doing things that customers would like and in some cases things they haven't even thought about yet. If you think they'd like it, we can start selling it."

    When you are developing an effective enterprise architecture and it gets built into your organization and becomes part of your operational model, you have created a new competency, a very valuable competency. And from that you get happy surprises. I think that's a very powerful way of thinking about what IT ought to be in a company.