Hey there, human — the robots need you! Vote for IEEE’s Robots Guide in the Webby Awards.

Close bar

Evolving R and D at IBM

7 min read

IBM Corp. lays claim to one of the world�s most well-funded, productive research and development organizations, with eight laboratories around the world. One of the most fabled is the Zurich Research Laboratory, which sits nestled in the picturesque hills overlooking Lake Zurich, the Swiss Alps towering in the distance. The lab is home to back-to-back Nobel Prizes: the scanning tunneling microscope (Gerd Binnig and Heinrich Rohrer) in 1986 and high temperature superconductivity (Georg Bednorz and Karl Alex Mueller) in 1987. Krishna Nathan took charge of the lab on 1 August 2002, following research work in pattern recognition and two executive positions at IBM. IEEE Spectrum senior associate editor Harry Goldstein went to Zurich to speak with him on 4 February about the changing nature of research at IBM.

How has research evolved at IBM, and how is the company refocusing R and D today?

If you look at how we did research in the 1970s, it was a corporate-funded model. In other words, a corporation said, you have a hundred dollars of money, go do what you want to do with it, come up with stuff, important stuff, and then the product divisions will take it over. And it was--you could call it an ivory tower model--but it was what corporate research was about. And we weren�t the exception; this is how most places worked.

Herr Direktor: Krishna Nathan leads IBM's famous Zurich Research Laboratory.

And a lot of good things came out of it: FORTRAN compilers, relational databases, single-cell DRAMs, which is basically the building block for memory today.

However, we also found that the time it took to take these from our labs into the marketplace was just too long. And as time to market became more and more important, this model of doing something in research and then handing it over was suboptimal.

And was that because the researchers were taking it to a certain point, a concept or a prototype, and then leaving it to the developers?

This is a good point. There are several reasons for that. One is very simply that if I work on something and then I give it to you, your first reaction is, what in the world is this, right? Because you haven�t been part of the process. So I have to sit there and, first of all, convince you that it�s a good thing. You�re out there selling something or developing something today, so the first thing is I need to tell you, listen, this is really better than the thing you have now. And you say, no, because you�re used to the product that you�ve been developing. So there�s this constant it�s-not-invented-here syndrome, right?

Another problem is that you have to redo a lot of thinking in the development process, because there�s this big long innovative step to make from a research phase to a real product. You have to worry about simple stuff that you don�t think about in a laboratory. There are just some very fundamental issues where we didn�t always work on what customers wanted because we weren�t that connected with them.

So we started shifting toward a model where we were much more receptive to what our businesses wanted. And we established something research called "joint programs." Now these joint programs are fundamentally between those of us in research and people in our business units.

And this shift started in the late 1980s?

It probably blossomed in the early 1990s. And this is, I think, one of the biggest changes we�ve made, and it�s been successful. Fundamentally, it says that if you�re the software group and you want some work done, you come in and you give me a dollar to do it, and I, out of research, match a dollar. So you get two dollars of work done for one dollar you put in; that�s the first thing.

The second thing is I work on a problem that�s of interest to you, but you�re a business unit. You�re not interested in ivory tower stuff. You�re interested in what you can do that will help your next-generation database product or your next-generation messaging product, in a software case. Or if it�s a hardware case, what do you need to do to leapfrog [Sun Microsystems] in microprocessors, right? That�s what you�re interested in.

So right away the research becomes more customer-driven, because you�re telling me what to do. Then also, it�s very much of a joint effort. People from research go over to the product division for a while; people from the product division may come work in research. So there�s much more cross-fertilization. The transition from lab to product is much less problematic because sometimes--often--the same people work on finishing it up.

And so I think fundamentally that this model has been the reason why IBM research has been so successful.

What metric are you using?

I�m measuring by patents, by the size, by the output, by the impact on the business. When I was coming out of graduate school and going through the usual thing, I�d ask, do I want to teach or do I want to do research. I was looking at several research institutions, right? And they were fantastic institutions: Xerox PARC or AT and T Bell Labs. These are places that 10 or 15 years ago were fantastic repositories of talent and intellectual capital.

But these institutions have now faded because the mother corporation could never extract value out of them. Not because they were not good institutions, not because the people there weren�t top-notch people. And I�m sure you�ve heard all the stories of Xerox, you know, where they came up with the mouse and the Ethernet and all these things, [but people were asking], so what?

At IBM, what we�re very proud of is that almost every product that�s out there has some research contribution, right. So it�s that connection that we�ve been able to forge, I think, which is responsible for the fact that we�re still 3000 Ph.D.s and researchers, not counting programmers or staff.

What�s the role of basic research today?

Two-thirds of our work is basically directed at research for business units. And then a third is what we call base funding. It�s things that don�t have relevance to a product. This is us looking into the future.

We do work here on photonics, which is, how would you use light to switch instead of the electrons we use today. Now, I�m not going to tell you that we�re going to have a photonic computer next year or the year after. This is something that if it happens, will happen 10 or 15 years from now. And it�s not funded by the server group because they--I don�t want to say they couldn�t care less--but they certainly may not because they don�t see it impacting their [profit and loss statements] any time in the near future.

IBM is putting more and more weight behind its consulting businesses. What are the implications for the Zurich Lab?

If you were to draw a timeline, it would start from where it was just sort of corporate-funded research, and then go on to something that was a joint program.

Then we said, well, this is all good, but we�d like to better understand what our customers want. Not through our partners, but we�d like to understand what our customers want themselves. We want more direct interaction.

So then we started directly with customers on selected projects. We�d go up to, let�s say, UBS [an international bank based in Switzerland] with a proposal for something we actually would call a first of its kind. We�d try and understand what their problems are. And then they�d come back to us and say, yeah, we think we�d like you to pilot this.

Then we�d put this together to help them try and solve their problem. And, you know, it�s not altruistic. Our goal is to learn what their problems are so we can make our solutions better, and then we�ll take it to the next customer, right?

And this sort of customer-oriented research has become just that much more important since the acquisition of PriceWaterhouseCoopers?

Services is a bigger and bigger part of our business, 48 percent of our revenue. Now we need to pay as much attention to getting research content into our services business as we have into the [products]. So we established something called ODIS, called On Demand Innovation Services. The thinking here was that researchers would work hand in hand with our services practitioners from Business Consulting Services, BCS, the ex-Price Waterhouse people. And they�d work together in customer engagements.

The ideal situation is something like this. The customer is looking for a solution. You can�t get it off the shelf. BCS doesn�t have it. The competition doesn�t have it. But research can fill in this missing piece. And then the researchers act as consultants, so they work together as a team, and [the researchers] go understand the problem, sketch out solutions, come back, work with them. All the same things I said earlier about understanding a customer so the researchers can come back and learn how to solve their problems still holds, right? It also provides a huge differentiator for our services business, because we have some very talented people who can bring certain points of view to the problem.

Are all researchers available to lend their expertise to ODIS, or are some sheltered, off working on things like photonics or really basic stuff that the customer isn�t going to see for 10 years?

No, it�s not that they�re sheltered. The high-level answer is everybody is basically available for everything. But then that�s not practical, right? There are people I wouldn�t put in front of a customer. There are people who are not comfortable doing this. They may be brilliant physicists or mathematicians, but I wouldn�t let them get close to a customer. So those people you don�t want to be in those practices.

So people are putting themselves forward for projects, or are you looking down a list and figuring out who matches, or a little bit of both?

It�s a little bit of both, because it also has to do with expertise. Everyone�s not fungible. I wouldn�t take a person who�s a solid-state physicist and ask them to go design a security system for UBS. So it�s not like you throw a dart on the wall and you come up with a John Doe and, okay, you drag him kicking and screaming to the customer, right? That wouldn�t work.

It�s not like we say, okay, here are all the people in the lab in Zurich and only these guys have ODIS marked on their forehead. It�s not that way. Perhaps de facto for some people if they�re really good at it, it becomes that way, right? They go make one deal; they�re really interested in it. And they build contacts and they go on to the next one. And, yeah, de facto that�s what they�re doing. But if they came up to me and said, "Tomorrow, Krishna, I want to go work on something else," that�s not a problem.

This page was updated on 5 March.

This article is for IEEE members only. Join IEEE to access our full archive.

Join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum’s articles, podcasts, and special reports. Learn more →

If you're already an IEEE member, please sign in to continue reading.

Membership includes:

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions