IBM Rational Chief Scientist Drives SOAs

As the chief scientist of IBM's Rational Division, Grady Booch is helping to fuel the adoption of service-oriented architectures (SOAs) as part of IBM's overall E-Business On Demand Strategy. A driver of the development of the Unified Modeling Language (UML), Booch explains how an emerging generation of software will change the way integrators must think about application and systems integration in an interview with Editor In Chief Michael Vizard.

CRN: Given your history in the business, where do you think the industry as a whole stands today in terms of its overall evolution?

BOOCH: In the last decade, I've been so jazzed by the advent of Patterns, which in my mind is really the most interesting thing that's happened in software engineering in that time, except perhaps the creation of UML, but I'm a little biased there. The reason it's so interesting is because it finally represents a means of reusing designs that transcend the individual specific manifestation of those designs. In other words, we're not necessarily tied to platforms.

CRN: What impact will SOA have on those patterns?

BOOCH: Service-oriented architectures represent just a different technology for good componentization practices that had been well known in the object-oriented community for some time. The best service-oriented architectures generally come out of those architectures because they tend to have good abstractions already. SOA is really a specific instance of a larger trend. If you look at contemporary systems, the problem is increasingly they are system-to-system, so you never turn them off and you have multiple stakeholders who are invested in certain pieces of it. So we spend a lot of time weaving things together. What is going on with modeling is just a recognition that there are certain aspects of these systems that are sufficiently well designed that it makes sense for us, as tool vendors, to focus upon that particular aspect and see what we can do to drive some more automation.

CRN: Does that mean we will essentially see the development of business process modeling tools that manipulate components of an overall system?

BOOCH: In a sense that's correct. When we start talking about business rules, the problem is easier than the problems of business process, because in the case of business rules, they are reasonably identifiable and things that have separate concerns that we can extract out from most systems. When you start talking about business processes, it becomes far more complicated because now we're talking about the human element. When the human element comes into play there, we can provide automation for driving this into the software side, but it still requires the human element to deal with the processes themselves.

CRN: How does all this tie into E-Business On Demand?

BOOCH: The e-business side of all this says ultimately the real value to end customers lies not in the infrastructure. We're trying to raise the level of abstraction so that you can do innovative and economical things to your specific business. The drive toward these higher levels of abstractions or services and patterns lets you align to more and more vertical industries.

CRN: What becomes of middleware as we know it today then?

BOOCH: There will be a day that middleware becomes a commodity, at least middleware as we see it today. We've seen the commoditization of operating systems and, increasingly, we see middleware moving in the direction.

CRN: Does this mean integration will get easier to do?

BOOCH: I'd actually question the assumption that the issues of integration become simpler; they actually become more complicated because as I start weaving together these systems to systems--especially systems over which I have no control and imperfect knowledge--then the behavior of those systems becomes a bit more mysterious and therefore integration becomes a bit more challenging. In fact, one of the Achilles heels I see with services is the following: Service-oriented architectures are great, they really do represent sort of the next technological generation of reuse. But services are not necessarily the only mechanism one should use to weave systems together. Services work well for relatively large grain objects that have low frequency of interaction, but if you're talking about very complicated objects with high frequency of interaction, then services as a transport mechanism just don't provide the performance you need. Services are useful but they aren't everything. In the case of services, they're really wonderful for loosely coupled systems,l and a large class of systems can be built with that, but not all classes of systems can.

CRN: How does all this come together to affect the business models of companies that specialize in integration?

BOOCH: The ones who are taking the high ground are those that can look at existing systems in a reasonable way to move them forward and not slap a bunch of services on top of these things and declare victory--but rather step back from them, harvest some of the patterns from them and look at the scenarios that cut across them. At those points where those scenarios touch existing legacy systems is place where we can plant a flag and say: 'Here lies the place where a service might come forward.' The way an integrator will dominate the marketplace is by being better at integrating systems based upon an intellectual knowledge and doing it faster than anybody else.

CRN: What types of people will build these systems?

BOOCH: Well, the number of people graduating from university with a pure computer science degree is declining worldwide and yet the demand for software increases. I reconcile that by saying more software is going to be built by people who are not "software professionals" but are domain experts who have to use software to do their business. And the way those people are going to advance more quickly and be most efficient is by using decent abstractions. WebSphere, J2E and Microsoft .Net are all wonderful things, but by and large they're still more complicated than the average developer can absorb, especially the average nonprogrammer who is a domain expert. That forces us as platform vendors to keep raising the level of abstraction and moving people more and more into vertical domains where the patterns lie.

CRN: So what should people take away in terms of understanding the business value of SOA?

BOOCH: Services represent another technological way of bringing systems together. The real value proposition is the fact that people have all this legacy stuff and there are all these systems floating out there. The reality of software development today is it's now about building continuously evolving systems. Those organizations that can be really effective at weaving those things together--meaning they understand their developer process, they understand their particular domain and they can leverage patterns--gain a competitive advantage that will allow them to whack their competitors.