Sutor was a member of IBM Research for 15 years before joining its software group in 1999. Today, he's IBM's director of WebSphere infrastructure software, which basically means that he tries to get all the stuff to work together that's needed for Web services.
The IBM veteran is also a proponent of the service-oriented architecture (SOA) terminology, a framework for incorporating Web services across enterprises and between them.
Recently, he has been involved in the effort to get Sun Microsystems to make its Java technology, which IBM has also embraced, open source. IBM has suggested that an open-source Java, particularly when combined with Linux, would make it more competitive against Microsoft.
As a member of several standards groups related to Web services, Sutor would be in a key position to help drive a Java open-source initiative, though Sun is reluctant to go along with the plan.
Question: The theme that seems to be emerging these days is software as a service, as opposed to that of a few years ago, when you were supposed to rip out everything you had and build a whole new infrastructure.
A: When you look at enterprise software, it may have sounded exciting in 1999 to rip everything out, but everyone was a little crazy back then. Right now, people are very much saying, "Look, I want to make all the stuff I have--all the facilities and information--available to the right people. But I've got to keep my critical business processes going. I cannot bring them down, so you have to show me how to extend what I have already."
It seems like IBM would be very well positioned in this "software as service" world.
When services are outsourced, there are basically two things that you want to do. You have to understand how you talk to (the service), so you have to understand the interface, how to tell it to do things. And then you have to understand the quality of that service.
For example, it is fine to say, "Give me a list of all the customers who have bought more than US$100,000 worth of product last month." But then, you have to decide how quickly you want that response and who will get that information. Making it available reliably with the right performance and the right security is very, very important.
Is Web services still really vendor-driven--with you going out there and saying, "This is the solution," and customers accepting it? Or, after four years now of having Web services out there, are they starting to push back and say, "This is how we would like it"?
Let me bring up SOA, which is the larger picture. It is distributed computing with characteristics around liability, security and manageability crossing enterprise boundaries.
The world has changed a lot, and we no longer have control of all the things we are running. It turns out that Web services is by and large the best way we are going to do this today, because it also involves things like Java. So therefore, Web services in terms of being adopted is early mainstream. Gartner thinks that slightly more than 50 percent of companies are showing signs of doing Web services today.
I would tend to agree with that, but when you talk to customers about SOA, they almost all say, "Yeah, we're doing it." They understand this notion, because they are driven not just by these internal concerns but by mergers and acquisitions and having data centers that are widely distributed--about having the best design for how they connect to the rest of the world.
Let's get back to service-oriented architecture. What does it mean, exactly?
SOA has been around a long time, since the client server in the '80s. As a subset of object-oriented programming and design, SOA was clearly in there. And there was a glimmer of this a few years ago, when Java was coming out. Certainly, everyone in the universe used Java. But it was the Internet and XML that made this fully possible, so today, it is characterised by saying it is distributed computing. It is loosely coupled, which means that you have very little knowledge about the actual construction of the services.
It is defined by standards that have actual descriptions of how you talk to it and how it talks back to you. You use the same language to talk about all these interfaces--specifically, this is Web services description language, and that means that you can start leveraging common registries for services.
You can look up, "How do I talk to this version of a particular thing?" Tools start becoming much simpler, because if everything you want to use is described in the same language, you can start dragging and dropping these different things and threading them together much more easily.
So give an example of how SOA is being used.
Enterprises need to have a view into all the information they need from top to bottom. Let's look at a company that's going to contract with another company to handle credit card transactions and fulfill online orders from their catalog. The first company decides that it wants a 98 percent success rate for transactions, which seems reasonable. But does it make a difference to them if it were to discover that the 2 percent failures were the largest orders attempted?
If it's only failing 2 percent of the time, but it is your biggest customers, that is important information to you, as a manager. So there is a new relationship between information you might have from these services and what it actually implies for your business. There's the information gap that we are now able to bridge.
Let me ask you about what's going on in Web services consolidation. There has been a lot of talk that if Oracle can't get PeopleSoft, which now appears likely, then BEA Systems is the next target. So what would that mean for IBM?
It doesn't change anything that we do fundamentally. We have been competing against both of them very successfully. If you look at the breadth of our product portfolio, we do not just do application servers. We do not just do what is frankly the relatively simple integration, and we also simply do not just do databases. So we already have what is essentially a far broader portfolio, excluding the Oracle enterprise applications.
You mentioned the ubiquity of Java. Now, obviously, IBM would like to see Java made open source, as you indicated in a letter to Sun. But what's in it for Sun--why should they do it?
What it boils down to is: What is Java? What is actually Java has been built by hundreds of people and hundreds of companies. I think sometimes when people read press releases, when Sun announces a new Java version, "Well, Sun did not write all of it. This was done by many, many people."
JSR-109, a Java specification for enterprise Web services--IBM started it, IBM led it. BEA had a big role in many of these things, too. So, fundamentally, it is a mistake thinking that Sun equals Java, Java equals Sun. It is already a community effort. It has evolved, and there are bits and pieces here and there, but there is no one complete Java solution available from anybody that is open source that you can count on.
We donated US$40 million worth of code to Eclipse, the open-source Java effort IBM founded, and then Eclipse became completely independent. So we have this model in which the value is to create the ecosystem and let lots of software developers do lots of good things. Let us just try to produce a situation in which we can work together to get the best possible common distribution so that we can put our resources to work individually.
It is not that we are looking to make more money off the platform. It is just that we are looking to accelerate the adoption of Java and the building up of it for all of us. Sun can reapply the resources to other places. Sun can create great products. We can create great products with open-source Java.