AS THE OVERSEER of IBM's $12 billion software business, a business that spans every major software market from mainframes
to PCs, Senior Vice President and Group Executive Steve Mills must feel a little like that guy on the Ed Sullivan show trying
to keep about 20 plates spinning at once. With one hand the 28-year IBM veteran must make sure the strategies against long-time
rivals such as Microsoft, Oracle, and Sun are spinning in the right direction. And with the other he must direct a raft of
emerging and very different Web-based technologies and all of their associated strategies and political wranglings that go
on in any number of standards bodies and other institutions where political in-fighting rages.
Sometimes sounding much like the hard core technologist he is, and sometimes more like a politician carefully clarifying
his position on the issues of the day, Mills recently sat down with InfoWorld's Editor In Chief Michael Vizard, Steve Gillmor,
director of InfoWorld's Test Center, and Ed Scannell, editor at large, for a wide-ranging interview. Mills gave his thoughts
on where he and IBM stand on such things as the technical and political ins and outs of Java, XML, Web services, peer-to-peer
computing, Microsoft's .Net strategies, IBM's open-source Eclipse initiative, as well as on Web services standards organizations
such as the W3C (World Wide Web Consortium) and the recently formed WSIO (Web Services Interoperability Organization).
InfoWorld: A couple of years ago it seemed like the evolution toward distributed computing would be driven primarily out of
the Java space. But now it seems to be driven more by alliances and deals between companies like IBM, Microsoft, and BEA and
then brought to some other standards body. What has changed about the process here and what's good about that?
Mills: Well we never thought it was going to be driven by Java. And when we jumped on the Java bandwagon in 1995, we saw
Java as something very valuable for server-side development, programming, and interoperability. That was not the message Sun
was delivering, but that was the interest that we had. We saw Java as a logical mechanism to replace the more complex C++
and CORBA-based implementations for system interoperability that preceded what's now emerged as J2EE. That's the way we saw
Java. We've always seen CAD mark-up languages as being useful for high-level data descriptions and normalizing information.
And we've been working on XML and its predecessor technologies for decades. We delivered WebSphere in 1998 before anyone was
talking much about XML with native XML parsing capability because we knew this was going to be the technology that would become
preferred for doing these high level descriptions.
InfoWorld: People talk to us about J2EE {Jave 2 Enterprise Edition] and its support for Web services. But it is unclear to
us what really belongs in J2EE and what doesn't. Not just that, but what's the line between where J2EE is supposed to begin
and end and where some of these other initiatives begin?
Mills: But they're really an apple and an orange. If you look at what Java is, it's pretty clear; it's low-level programming
syntax. I write an application in Java and the application logic is written in Java. Nobody would write an application in
XML. It doesn't make a lot of sense. You want to define data elements and interfaces in XML, it makes things interoperable
by using XML. For example, if you're a bank and you need to exchange funds with other banks and do querying and all the things
that banks do with each other like credit card activity, billing activity. Well then you and the member banks that you do
this with have to agree to formats and structures that permit you to do this with each other. And you've been doing that kind
of interactive interoperable banking before programmable computing came about. So you had ways in which you defined this stuff
on paper. And then you digitized it and you were defining it in a computing sense.
InfoWorld: What I'm driving at is, there's a process today where application servers and J2EE environments, especially WebSphere,
are supporting Web services through the additions that you're making. What seems to have everybody somewhat anxious is that
the standard around J2EE 1.4 doesn't appear to be fully cooked. People are worried about going down a path of working with
this stuff today, only to have to rip it out and tweak it later when the standard gets more fully baked.
Mills: If they understand the technology, they ought to be relatively unconcerned about that. XML, if you know what it looks
like and how it works, it's this infinitely flexible high-level structure where I use a particular compliant syntax to annotate
things and describe what they are. And through the interpretation of that annotation that I can map any piece of information
to any other piece of information that is annotated using the same technique. So you're describing information, is all you're
doing with it, whereas in Java, you're actually writing program logic. You use them for two different things. They complement
each other just as all things in IT have complementary characteristics to them.
InfoWorld: So what you're saying is what J2EE adds in terms of Web services support in 1.4 could be relatively irrelevant?
Mills: Yes. That's exactly what I'm saying. The need for Java to keep evolving will continue. The emergence and the use
of XML in so-called Web services doesn't deny Java in its continuing evolution. It doesn't deny creative ways in which these
things can be combined together for the value that they deliver.
InfoWorld: Nor does it imply though that the Web services support needs to be actually bundled into J2EE, because it's kind
of orthogonal.
Mills: They're different things. If we eliminated all the cute doublespeak, and we were talking about XML and C++, we wouldn't
be having this discussion. You would say, well, C++ is all this, gorpy, low-level syntax, and manipulation stuff that's associated
with writing programs, and XML is a high-level description language. But instead of calling it C++ and XML, we talk about
Java and Web services, then we get lost. This is one of the problems with the IT industry is that it constantly revs names
and terminologies in ways that create confusion. We didn't coin the term Web services, but we stuck with it. Sun named Java,
"Java". If IBM had created Java, we probably would have called it C+.
InfoWorld: Well IBM created about 80 percent of J2EE.
Mills: I think there are informed customers who clearly do understand the differences between these two things. The commotion
around Java is heavily fueled by Sun. And they're concerned one way or the other about whether they're being left out of something.
But nobody has an advantage in the world of Web services. It's not owned by anybody. XML is universally accessible, all the
syntactic mechanisms and expressions in XML are published. They are not owned by anybody. It's a true open standard in that
sense. So Sun can be as big a participant in Web services as they choose to be.
InfoWorld: Where do Web services need to go from here? One of the things that keeps coming up is the sweet spot where IBM
has spent a lot of time, namely the requirement for asynchronous capabilities around Web services. But it is not clear to
us whether there's going to be a standard approach to that or whether it's just going to be everybody's individual product
implementation. Do you have any thoughts on how that emerges?
Mills: What you're seeing evolve today is that the vendors and the customers come together to define the layout, create
templates, formats, and then they agree to an accepted format to do that particular thing. And if it becomes required as a
Web service, it gets labeled as a Web service. What those XML templates run on top of is a matter of what the vendors then
deliver. So the Web service itself doesn't do anything until you transport it somewhere, until you parse it, until you deal
with it at the various endpoints into which these Web services are implemented. So everybody has access to the standard, and
so what the stuff rides on top of will be a matter of what quality of service, what platform, and what vendor you think you
want to work with. So WebSphere provides transportation services and parsing and interpretive services for Web services.
But it won't be the only piece of infrastructure that Web services ride on top of.
InfoWorld: So is there going to be a thin layer in the standard to connect all the different asynchronous messaging transports?
Mills: There will be, just as there are things like JTS {Java Transaction Service] and JMS [Java Messaging Server]. Or Java
implemented interface standards for a common way to express transaction semantics or messaging semantics, just as there's
JDBC [Java Database Connectivity], a common way to issue calls to databases. In the world of XML these types of system level
interfaces will be instantiated in an XML structure that will get labeled in some fashion and be the standard way in which
you do some of these things.
InfoWorld: Take for example the BEA Cajun initiative where there's a framework that encapsulates the mapping between Java
classes and the XML that you're talking about, to provide loose coupled coarse-grained and asynchronous communications. Is
there an analogy in the IBM WebSphere environment to that initiative?
Mills: There's a capability in our product to do that it is one of the native features that's in WebSphere. What happens
in case of all technologies is the vendor level innovation typically is preceding the standardization. For example, before
there was an agreed-to enterprise Java Beans architecture, there was a prototype created by IBM called [Arabica], that we
took to Sun and through the Java community process that resulted in the Java Bean specification, which was later up-leveled
to the Enterprise Java Bean specification. So the vendors play with these things and come up with ways to create interoperability,
cause something to happen inside of their product, and then the standards process typically takes over after that and hopefully
you reach an agreed-to approach to do this thing in a standard way.
InfoWorld: The way that W3C is set up now, do you think it can move fast enough to ratify some of the standards that need
to be done quickly? Or does the W3C have to make some changes to the way it works?
Mills: Clearly we would like to see the W3C move faster. I would not characterize it as being particularly slow in the
context of standards bodies. The more participation you have and the more vetting process that your bylaws call for, the
longer these things tend to take. On the other hand, it's a way in which you achieve adequate airing of all the issues.
It's a way in which you ensure that all the right information and interests are dealt with, and it produces a standard that
hopefully is a result of compromise and everybody signs up for it.
InfoWorld: Is this something the WSIO will do?
Mills: You might misinterpret what I'm going to say here, so let me give you the caveat up front. I am pro standards bodies,
I am pro open standards bodies, I am pro wide participation standards bodies, I am pro customer participation standards bodies.
So do not misinterpret what I'm saying here as being a criticism of standards bodies. The beauty is you get a standard. The
challenge is that it takes time. So how do you find ways to try to speed that up? That's what this WSIO thing is all about,
is how to you create something interim, some final standards initiative, and then the vendor community comes together and
reaches some agreements. Frankly, the participants in the WSIO would be companies that would be coming to the table to drive
most of the evaluation and bring most of the intellectual capital to bear anyway. So can this speed up the process? That's
what we're all trying to do. Having participated in this stuff now for decades, you sort of figure there's nothing perfect
here. At one end of the spectrum, you have a vendor creating something independently and they're done. You go to the other
end of the spectrum, and it's the wide participatory standards body that might take a year to get something out the door.
So how do we shift to something in between a weekend and a year? It's the creation of an intermediate gearbox. And that's
what we're trying to do here with this WSIO effort
InfoWorld: What role might bridge technologies play in terms of bridging J2EE and .Net for Web services?
Mills: I think things always emerge in the marketplace that end up being widely accepted because they're useful mechanisms
that somebody creates. Whether or not they end up going through a standards body then is another question.
InfoWorld: If companies ascribe to the proposed Web services standards faithfully, maybe you will not need some bridge technologies?
Some do debate however, that you will need the bridge technologies if you want deep integration.
Mills: Well one of the things that's been controversial in the world of standards has been the reference implementation
issue. You go back to standards bodies that emerged in the '70s and into the '80s, they put forward an API structure and
published it for the standard, but there'd be no reference implementation that was shared. And so you then end up with a divergence
in the vendor deployed implementation, and have to work on interoperability issues because you had mismatches. So the lack
of reference implementations has been one of the issues in standards processes. I think the vendors are getting smarter about
this and there are more of these standards efforts now that include reference implementation that's been shared with everybody
who wants it.
InfoWorld: So then how do you account for IBM essentially forking the open source development environment by starting Eclipse
instead of joining with the Net Beans environment?
Mills: I didn't know that Eclipse was an anti-Sun movement.
InfoWorld: Certain people at Sun seem to think so. When you talk about reference implementations, that was one of the purposes
of the Net Beans relationship in the first place. It sounds like that effort now is muddied by the fact that there are two
paths for open-source contributions, particularly in the area of Web services.
Mills: No, I absolutely disagree with you. I don't see it that way at all.
InfoWorld: So how do you see the relationship between those two things?
Mills: There's nothing about Eclipse that's proprietary. There's nothing about Eclipse that's not modifiable through the
eclipse.org initiative. And there's nothing wrong with offering up derivative works in an open source full publicly vetted
environment. This is like saying that all invention done in the past is the invention that you're stuck with and you can't
create anything new. Eclipse is not an anti-Sun effort, and it is not a proprietary effort. Eclipse.org has the opportunity
to make modifications, it's not something that lives under some rigid control, my way or the highway.
InfoWorld:You're suggesting that Net Beans is an attempt to provide minimum participation? I'm not sure I understand?
Mills: Yes exactly. What's wrong with introducing new things, particularly if you introduce them in the context of providing
open source, and by inviting dozens of tools vendors to and take advantage of what's there for the purposes of further extending
the tools and workbenches that they currently deliver. Clearly we're interested in seeing an open tool environment that supports
a wide variety of platforms and does not lock anybody to Solaris and Solaris-based tooling. We're equally interested in seeing
the same scenario play out in the world of Intel
InfoWorld: So you're suggesting that was the motive for starting Eclipse, to provide that kind of pervasive environment across
platforms, and that Net Beans somehow did not deliver that?
Mills: Absolutely. Look, I'm a cross-platform software provider. I've got to build applications that run on a whole variety
of systems. I have tools today and I want more tools that support that paradigm of multi-platform, cross-platform. And I'm
interested in not creating an inherent lock-in to which platform you're forced to build on or which platform you're forced
to deploy on. That's what we're doing with Eclipse, that's the whole purpose, to move away from the historical multi-decade
old legacy view that system vendors, such as IBM, only deliver things that provide support from a tooling standpoint for the
creation of applications that run on their system
InfoWorld: Does IBM have any plans to support C#?
Mills: I do not have any plans at the present time to support C#, for the simple reason that I don't need one more programming
language if I can help it. I mean we're collectors of programming languages here, and so one more programming language just
makes my head hurt. On the other hand, if the market votes in favor of doing lots of C#, well, it'll probably lead me down
the path of having to do things in the world of C#.
InfoWorld: What is your opinion of Microsoft's Common Language Run Time included in Visual Sudio .Net, which allows people
to choose the language of their choice here?
Mills: I think that Microsoft created this to solve a problem they had with the gap between Visual Basic development, largely
focused on the client, and Visual C, C++ development, largely focused on the server. And that boundary condition between
client-side and server-side programming I think has been bothering them for some time. They sought to bring about more unity
in their own environment by trying to create a language-neutral run time layer that would allow greater ease in moving back
and forth. Somebody building an application in VB could more readily move that application over into C and get the performance
that they'd be seeking on the server. So they've created this language-neutral layer, which is a pretty complicated piece
of computer science. Going back some years we had the System Object Model [SOM], which we created as a language-neutral intermediate
layer in an attempt to get synergy between the client-side and server-side development environments that we were creating.
And the added path links and complexity, even though you could do a demo and show how you could move back and forth between
languages, the reality of that from a performance standpoint never proved to be all that good. But Java solved the problem
for us, you know. It provides a reasonable degree of neutrality, cross-platform ability to run things to the client or the
server.
InfoWorld: Speaking of languages there are all these workflow language acronyms that sound like they're out of the Worldwide
Wrestling Federation. But you're pushing one and Microsoft has another. Now that you have this organization, is it a priority
to bring those together in some form?
Mills: Yes it is. It's certainly one of our priorities to get agreement on a common Web services flow language, something
that provides a common expression and a way to describe workflows. The need to describe workflows varies quite a bit across
application types, so you get these fine-grained flows, coarse-grained flows. There are a lot of issues here that have plagued
us in trying to reach a conclusion on what the common structure is. Also, trying to get to what could be viewed as a subset/superset
of workflow description language whereby somebody could choose a simplified version but could bridge across to the more complex
one and vice versa.
InfoWorld: Do you plan to do this with Microsoft directly by normalizing the differences, or the common agreement between
WSFL and XLANG and then take it to a standards body? How do you see this maturing?
Mills: We haven't really come to a conclusion on that. We have to close out some of the discussions on WSFL and XLang, and
how to proceed forward from there. But our interest is in coming up with a way to resolve those things, and then promote
a common standard. We've participated for nearly a decade in them. I would hope we could reach some reconciliation of WSFL
and XLang. So you'll have to watch this space and see how it evolves, discussions are underway.
InfoWorld: Large IT shops have been hoping for a while there would be more independence between languages and their platform.
Will the growing popularity of open source programming tools help apply more pressure in terms of speeding up that independence?
Mills: This is very much what we would hope to accomplish long term around the Eclipse initiative. There will be a class
of programmer whose targeted environment is a Windows platform. That's what they intend to do. They're building an application
on Windows for Windows with never any intent that the application will ever run anywhere else, particularly for the lower
end of the market where the deployment environment is always an Intel set of devices attached to a LAN and so on. They're
likely to stay with tools that they're used to using. So much of that business is very simple template-based stuff. There
are developers that build to that environment, so I don't think they are going to get off of Microsoft tools anytime soon.
Then there are other parts of the market who are looking for more flexibility, and for whom cross-platform development and
deployment is viewed as something important, I think they're going to be looking for a more open tool environment.
InfoWorld: Why Sun is dragging its feet here on joining WSIO?
Mills: Microsoft and Sun are having this war of words. We work with Sun on Java and we work with Microsoft on Web services.
On some of this I'm afraid you're going to have to ask them as to why can't they decide to work together. I'm not against
working with either company. I have no problem working with them and competing against both of them. I accept that as the
way the world is. They don't seem to particularly like to work with each other. You try to get [those] parties in the room
and sometimes they don't want to get in the room together. We battle BEA every day in the market, that's an endless slugfest.
It goes on 24 hours a day worldwide. But we've worked with BEA and OMG, we'll work with them in the WSIO initiative.
InfoWorld: When Adam Bosworth [vice president of engineering at BEA] demonstrated an alpha version of Cajun at InfoWorld's
Web Services Conference, he said the features he was showing were not available on any other platform. One of them was ease
of use for developing asynchronous transactional Web services. You indicated that you had that capability inside your product,
but I didn't hear ease of use associated with that.
Mills: We certainly work on polish and ease of use. It's one of the things that we've been focusing on. Our customers are
constantly coming back at us wanting us to find ways to simplify what is a very rich environment. But because it's rich,
it is complex. There are more features there than most people would necessarily take advantage of in a single development
project. We deliver the capability to produce applications that use a very rich and robust infrastructure, whether it be WebSphere,
MQ, multiplatform, distributed transactions, synchronized and coordinated transactions, native context passing of transactional
context between systems, the ability to establish stateful transactions that run across multiple tiers in an environment.
You can do that with our tools and our middleware combined. It's not something you're going to do with the Microsoft tools
and middleware.
InfoWorld: Right, but I'm not asking about Microsoft, I'm asking about BEA. You said that you go up against them on a daily
basis. Do you consider this a threat from them, that they're entering the tool space?
Mills: Well they've been in the tools business for a while. We compete against BEA every day, so I mean everything new that
they do adds to the competitive battle. I do not view BEA as a strong tool company, vis-a-vis Microsoft, who I think is a
very strong tools company. There are other tools companies out there that I think are very good in their particular space.
InfoWorld: How important is it to IBM, that Sun become part of some of these groups, given the fact that they used this IP
issue as a reason to back away from supporting SOAP, for example?
Mills: I think it's important for Sun to participate. The Solaris environment is a widely deployed environment and therefore
important. I think for Sun to participate and represent those interests, which clearly they're best equipped to do, reflect
those interests.
InfoWorld: But given they have concerns about supporting SOAP because of the IP licensing relationship that IBM has with it,
that sounds like a road block.
Mills: I think it's a bunch of silliness. They can join these groups and there are no onerous licensing terms or things
that. Look, I have licensing arrangements with them on Java, as does everybody else in the industry. I don't know what the
big deal is here.
InfoWorld: Good point, it does go both ways. But with Java you call XML an open standard without any restrictions, and Java
clearly is not such a thing.
Mills: There's nothing about these things that inhibits their participation. I think that there are things they decide
they don't like, things that they decide that they want to do in their particular way, all companies have that option. But
there's nothing about what's going on here that prohibits their participation and involvement. There's a certain fanning
of the flames here that's been going on. Everybody's out shagging a few balls and warming up and all of a sudden you're keeping
score. Microsoft's out ahead of Sun in Web services and so it's the latest story with [Sun's] McNealy and {Microsoft's] Gates
on the cover. This stuff is at its rudimentary beginnings. What's to come will go on and on and on for years, for decades.
We're just at the very beginning. Frankly, there'll be more activity that occurs in the world of Web services and XML on the
part of industries, businesses, the banks, the insurance companies, the chemical companies, the oil companies. They will take
all of their pre-existing electronics, like EDI [electronic data interchange], and redefine those things using XML interface
standards.
InfoWorld: Where is IBM going right now with peer-to-peer?
Mills: Our view of peer-to-peer, in the context of Napster style peer-to-peer arrangements, is that we've questioned whether
or not those things really have great applicability in business. Our model is business, not consumer. And businesses look
to deploy controlled environments. And so peer-to-peer computing, inside a firewall or in a closed b-to-b environment needs
to be scalable, secure, reliable, recoverable, and therefore the peer relationships between systems are server based. And
server based peer-to-peer computing has been with us for decades, and that's principally what we do, is server based peer-to-peer
computing.
InfoWorld: Have you taken a look at what Groove has done with its environment in terms targeting it to corporations?
Mills: In enormous detail. Ask anybody who's deployed Groove how many servers they use and how they manage their "Groove
environment". It is a server-controlled environment in which clients participate. There's nothing new there. Clients have
participated in these environments for a long time.
InfoWorld: What's new is that Groove works very well across virtual partnerships and relationships in a Web services type
environment. Conversely, you have a whole lot of Lotus business partners who are very concerned about the [Domino] Notes
code base being deprecated and basically abandoned over time. With Microsoft support of the Groove environment, don't you
run a good chance of losing a tremendous amount of collaborative application development?
Mills: Well Lotus Notes/Domino base is not in decline. It continues to grow. There's no migration from that base to Groove.
I would challenge you to go to the Groove team and find significant deployments of Groove and look at the topology and look
at how they run.
InfoWorld: But I'm not talking about where we are today, I'm talking about the signals that you sent at [Lotusphere] regarding
abandoning of the core Domino environment. I mean, this isn't me talking, this is a lot of business partners talking.
Mills: We're not abandoning that environment. Those companies will get support for that environment for a very, very long
time to come. There's no termination point, there's no end point. Like most things in the IBM company, I expect to be supporting
it for as far as the eye can see. The environment can't remain the same though, it does need to continue to evolve. New technologies
need to be incorporated into it. It needs to become more open, more flexible, more scalable, and so we will continue to evolve
that code base and take advantage of technologies we have elsewhere in the IBM company to move that code forward. If it sits
still, it will go away. If it keeps moving forward, it won't go away. And if some who are used to using it in the current
mode today find these changes to be changes that they don't think they necessarily want to take advantage of? Well, so be
it. I never expect everybody to like everything that we're doing. But against the broader market and the larger set of customers
that we have, measured in the tens of thousands, the changes that we're making are the changes that they're asking for. I'm
not worried about Microsoft in this context, nor am I worried about Groove. I'm not worried about p-to-p. I am worried about
continuing to rev the code base and deliver the scalability, full native J2EE support, XML support, and the data mapping of
XML into DB2, the advanced collaboration function. The explosive growth that we're benefiting from and at the same time in
[Quickplace] to take advantage of that, knowledge management, e-learning, all of the advanced portal technologies that we're
pouring out of Lotus today, those are the things I'm focused on.
InfoWorld: Speaking of Lotus, there's a lot of discussion about portals and how they evolve, and how peer-to-peer evolves
in the portal and how knowledge management shows up in portals. So what is happening with the Notes/WebSphere strategy and
how do all these things manifest themselves?
Mills: Well the long term strategy here is for things that you've seen us do around Same Time, Quickplace, WebSphere portal
server, and knowledge management. Lotus is delivering an ever-increasing amount of technology which is not dependent on the
Notes file system. That is not Notes-centric, it's independent of that base. It can run with relational databases, it can
be inserted into other environments, it's much more flexible in deployment. And that's where we're taking the entire Lotus
portfolio, into a much more flexible architecture. The beginnings of that date back now a couple of years in terms of the
products that we've been delivering over the last couple of years and where we're going with them. What businesses large and
small are asking for is seamless collaboration that can be readily incorporated into the tasks and the activities of the various
user sets that they have in their company. So they want collaborative services to be directly connected to the core application
infrastructure that they have.
InfoWorld: So why is that stuff tied to a specific platform depending on each individual vendor? In your case, it's tied to
WebSphere. And yet, isn't the portal something that you want to be more broadly applicable to than just going through a specific
app server?
Mills: Remember that the application server is a euphemism for a piece of computer science that's been around since the
1960s. So anything that provides in a commercial world, management for a set of application functions, that provides control
of the scheduling of tasks and processes and the attachment of users or threads to those processes, needs a session service
control mechanism to do that. And the session service control mechanism that we have built in IBM is WebSphere, and it's the
one we're using and reusing and will continue to use and re-use, and take advantage of it across all things that we deliver.
It's modular, extensible, it supports modern programming styles, it's very scalable, it's easy to work with. So it's something
we're taking advantage of to deliver the function that we're delivering. It's no more complicated than that.
InfoWorld: What are the priorities that IBM, or the industry as a whole, should be working on in the next year to move all
this stuff forward?
Mills: I think what we see happening out there clearly is a reflection of what the customers want. What the customers have
put a high priority on is interoperability. From the perspective of their business model, what they're trying to accomplish
is to get their processes interconnected so they can create some sort of demand to deliver a straight-through processing environment.
That's what they want, and they want it not just in individual slices that address specific application needs, but they want
it in a horizontally integratable fashion. And this is one of the key things that's driving these standards pushes in the
marketplace. Things like XML and Web services have a lot of interest because customers see the connection. Customers have
become increasingly attracted to these middleware mechanisms such as WebSphere and MQ and the things that are delivered by
our competitors. They're attracted to Java for interoperability and cross-platform. They're attracted to Linux for some of
the same value propositions. So this is one of the key driving forces in the marketplace today
InfoWorld:There has always been the sense that IBM's middleware, specifically MQ, is too complex. So as we move [to] Web services
and that moves us to a more mainstream environment, what happens to those products? What are you thinking about doing with
those products to make them more accessible to people and not be just the domain of 10 experts from the IBM Global Solutions
team?
Mills: Well first off all the products are sold by the 10,000-person sales force that I have, and deployed by that same
team. MQ is sitting with 80 percent of the market share for that class of product.
InfoWorld: Right, but the market could be bigger...
Mills: And the size of the market will continue to grow, because the technology is used to displacing labor. Most of the
energy that businesses put into their IT environments is in doing integration work. Products have been made ever simpler through
time in order to make them more accessible and easy to deploy. MQ stands on its own merits. It has become increasingly easier
to work with and deploy, and it's a relatively inexpensive product. A very large percent of the market uses MQ, and finds
it useable and accessible. It's not the domain of priests and priestesses that have unique knowledge. Customers deploy it
on their own every day, as do business partners. Do we need to make these things simpler? Absolutely. We have decades of
work in front of us in terms of simplifying it, and improving its usability. Over time businesses will want to not want
to see the infrastructure. The infrastructure is something they'd like to know is there, that they can call upon. They'll
pay for it against the quality of service it delivers and the value that it has. They want it to be more autonomic in nature,
self-diagnosing and self-recovering. So the list of requirements is endless here, and simplification being only one dimension
of what's required. But they don't want to lose the function.
E-mail
Printer Friendly
Reprints
