Smart Architectures, Architects (Continued)

The Biggest Challenge
Carter: What were your biggest challenges in implementing this architectural change?

Rampalli: Our biggest challenge in this whole conversion didn't involve the United States, but our 350-odd clients across Vietnam, Taiwan, Korea, and China. We had about six different languages to migrate the operating system into and to test applications in. That was hard. The standardization effort there differed from a standard approach to implementing a hundred clients a day in Arizona, which was what we were doing in Santa Clara. So it was pretty standardized in the United States, but once we got into the Asian context with local languages, it became a different challenge.

Carter: What is the process for developing applications at Intel? It seems there has to be some tension between the developers' needs and the desire of IT to keep platforms under control.

Rampalli: Historically, someone from the business side says, "Hey, I need a solution," and the apps guys say, "OK, this is a solution that could work." Then they come up with a requirements document and a design specification, and request some infrastructure that needs to be built. IT responds with what can be done and when it can be done. The solution is built based on this kind of dialogue.

So, it's very much that way—this is what I need, this is when I need it, can you buy these four servers for me? More often than not, the funding process is usually driven from these projects, and the infrastructure essentially gets a part of that funding in response to it. And that has resulted in projects driving unique infrastructures for each application. Then what you have is a mish-mash of local operations in the environment. When you stand back in two years and ask, "Is it best in class in TCO, and is it really the most agile thing I have?" And the answer is, probably not. And this is not unique as a phenomenon at Intel. Most IT shops have been dealing with this process. And thanks to the dot-com bust and the sobering of IT spending, there's a real focus now on where the money is going to be spent and how it is going to be measured in terms of a set of criteria.

Carter: So how have you gone about changing this mode of operation?

Rampalli: The thinking is that the success of the developer community is based on reuse and productivity, right? And the success of an infrastructure is based on TCO and agility so you can upgrade and retool and so on. And for us to be able to implement and maximize both the reuse and the developer productivity, along with TCO, we need a unified process that ties the two criteria together. So there has to be a formal vision of an architecture that takes these groups and the business needs into account.

So, the business framework drives the requirements on data and the technology, and these, in turn, result in a solution that gets implemented. And the solution has an application element and an infrastructure element, which are formalized activities. When we talk about architecture at Intel, we describe it in scientific rigor along the core use of how you consider architecture. If the architecture doesn't have a business framework or data architecture, or a technical architecture, or a solution or infrastructure architecture, then it is not an architecture.

We're also trying to spawn from this architecture a set of generic-usage models based on functional building blocks—the essence of an application architecture—and an infrastructure architecture based on a modular infrastructure of elements. We hope all of these can support one of the usage models.

Anatomy of an Enterprise Architect	Getting Maximum Utilization
Back to Introduction