IBM's Grady Booch on solving complexity

With IBM's acquisition of Rational Software, Grady Booch -- one of the original developers of the Unified Modeling Language and a thought leader in the area of architectural software -- has become the proverbial kid in the candy store. In his role as an IBM Fellow, Booch will help invent IBM's software future. He believes IBM's large cash reserves and a close working relationship with the high-voltage brain power of IBM Research will significantly quicken to market a range of technical innovations in the area of tooling.

As he prepared for his keynote at the EclipseCon show, Booch talked to Ed Scannell about the joys of eating all the technology candy you want, what's going on outside of the battle between Java and .Net, and programming trends among large-scale systems.

Q: As IBM's designated Free Radical, what havoc you have been able to create?

Booch: A number of things. The real cool thing about working with a large organization is -- and (IBM) is two orders of magnitude larger than what I have been used to -- there are so many bright people doing great things. It is interesting to connect the dots among them. One area where I have been helping to connect the dots is in the area of patterns. Patterns are perhaps the greatest thing to come along in software engineering in the past decade. They are part of the atmosphere of most good development shops. But the issue is, as I build systems, there is this vocabulary of naming these societies of classes that work together well with each other. With that practice now embedded in most shops, there are real opportunities to raise the level of abstraction again. (We) are starting to look at vertical architectural patterns, opportunities for that sort of commoditization.

Q: Any real-world examples you can point to?

Booch: The insurance industry is doing that already with its insurance application architecture. State Farm tells me 85 percent of that market now uses a common framework to some degree. The auto makers in Europe have banded together around BMW. Others are saying they need to come up with a common architecture for in-car electronics so they don't have compete with one another with these proprietary systems but instead build on top of each other's. So things are emerging. But as I go about being an architectural mentor, I realize people are reinventing the same patterns over and over again. I have been working with Grant Larsen and Jonathan Adams, for instance, and together we are trying to connect the dots on assembling the larger body of experience, especially within IGS (IBM Global Services) to see if we can codify them and then provide some higher degrees of automation with them.

Q: What sort of experience has it been working with IBM Research?

Booch: Two things. First, I feel like a kid in a candy shop. Second, IBM Research really is Rational's secret weapon. I feel like a kid in the candy shop because prior to Rational joining IBM, IBM Research was certainly doing things in the space of tools, but it wasn't like the software group really had a central place to catch all these things coming out of there. Well, now they do. For the last year it has been this wonderful opportunistic romp through research to say "Hey, you guys are doing cool things, come join us. Let's take what you have done and see if we can bring some things to fruition." In fact, this year we are spending a large number of millions to fund a number of research projects that are focused on just the tooling effort. This is something Rational has done on a smaller level in the past, but now we can do it in a big way.

Q: Everyone is focusing on Java vs. .Net. What are some of the more interesting things people might be missing out there?

Booch: Even though patterns are very much part of the atmosphere, I still think it is a market that has tremendous opportunity for growth. It goes back to my premise that building systems (is) really no longer just about language; that is only the stuff we use for the vocabulary of what we are doing. The real hard problem is, how do I come up with the right kind of components, the right designs, and how do you syndicate those kinds of things? That is what patterns are all about. In fact, if you look at things like IBM's patterns for e-Business and Sun's J2EE patterns, what these folks are telling us is, these platforms are good but they are still very complex. The way to bridge that complexity is by building patterns on top of them. That's the best kept secret inside the marketplace right now.

Q: You are a big believer in grid computing. Why?

Booch: I am a big fan of it but I don't think it is as revolutionary as it is evolutionary in that the economic, technical, and business planets are starting to align right now to make grid reasonable. I remember back in my DOD (Department Of Defense) days we were dealing with large distributed systems, which could be considered a grid, but by no means were we sophisticated enough to deal with any of the autonomic stuff that is going on now. The basic problem now is this: As I build in the enterprise space, it is getting hard just getting the business logic and the presentation logic right. So what we see happening in the grid space is, we have virtualization of the problems that can focus square on with scalability. In the past, I had to worry about those as an architect from the very beginning. But given where grid is now, it becomes more of an implementation issue for me as an architect because now I can view the topology upon which I build as something that is scalable in a number of dimensions without my architectural intervention. It feeds further into my mantra of raising levels of abstraction.

Q: Grid computing looks to be an important piece of IBM's On Demand initiative, technically speaking. What input are you having there in terms of shaping and directing the overall effort?

Booch: I have had conversations with people really driving things there. I would not say I am nudging things in a different direction, because these guys are absolutely on the right path. But from a patterns perspective what we are trying to catch is, what are the architectural patterns that are emerging for us to be able to exploit on top of grids? Flatly, that community has a number of one-off experiences of applying grids in certain places, and we are trying to harvest that experience to see what we can learn about providing automation to it. I am not so much an influencer of what they are doing, as I am a respecter of their work in trying to build on (it).

Q: What you mean when you say "solving complexity by raising the level of abstraction"?

Booch: Think of it this way. Imagine today building a Web-centric system but having to do it in Assembly language, which has an impossible semantic gap. What has happened over the years is languages and tools that raise the level of abstraction from worrying about individual Assembly language lines that drive the bare machine, up to the next level that says let's instead deal with algorithmic abstractions. So now I can talk about variables and algorithms and the like. The object-oriented realm said "Let's bring data and algorithms together into one thing called an object." That is what Java and C Sharp and C++ are all about. Each one of these things moves me further away from the bare hardware and actually allows me to express things where once I had to expand them out and through the bare hardware by many orders of magnitude. This allows me as a human to start addressing the problem further away from the machine and closer to the problem area. That is what moving up levels of abstractions is all about. The whole history of software has been that. We see that especially in our languages for Assembly, to structured languages like C, to object-oriented languages and who knows what is next.

Q: Is this progressing as rapidly as you would like, or more slowly?

Booch: It goes in fits and starts. If you look at the history of programming languages over the last three to four decades, you have seen what the evolutionists would call "punctuated equilibrium." There would be periods of incredible innovation and then points of stability. For example, in the early days of procedural languages there were languages like FRED and others you never heard of, but the marketplace said, "Oh, let's bless things like Cobol, Fortran, and C." We saw the same miracle happen with object-oriented languages. We counted upward of 100, maybe 200 languages with only a few surviving. Some of the dominant ones now are Java, C++, and C to a lesser degree. We are currently in a period of reasonable equilibrium, but you can see the furnace starting to heat up. And it is not the traditional languages doing so but instead XML, WSDL, and variants of XML. So all of a sudden we can see in the non-traditional programming language space a whole flood of languages popping up. We will see a period of equilibrium among them in a few years.

Q: With so much focus on Linux and open source code in general, what has impressed you the most in that space technically? What do you think the biggest contributions to programming have been?

Booch: Good question. I can't give you a technical answer or an emotional one -- and believe me there are some that are far more emotional than me on this issue. But I can give you an economic one. The economic argument says that in a number of dimensions, open source was absolutely inevitable because it represents the maturation of our business. There are some things that become commodities because they become so pervasive and there is then no economic incentive to innovate in that space any more. But there is actually value in making the marketplace larger by raising the level of abstraction for us to all agree upon a common platform. That is what is happening in the tooling space and in the platform space. We see a commoditization today of operating systems because we have a large body of knowledge around what an OS is and so it becomes hard to innovate within that space. So the battleground has moved from operating systems to middleware. I expect, however, that middleware will become a commodity over time. That will put lots of pressure on IBM but, at the same time and from a capitalistic viewpoint, this is great stuff because it means that with the eroding of the lower end of the marketplace, it forces those who want to be vibrant in the marketplace to continue to innovate and raise the bar and value.

Q: What do you see as the future of middleware? Is it an endangered species, not just through commoditization but through the competitive efforts of Sun and Microsoft, who say it has little value to corporate shops?

Booch: From IBM's perspective, middleware represents another virtualization of the machines as well as the pervasive devices upon which we build. In many ways the middleware is more important than the operating system, which is becoming increasingly commoditized. It is the middleware that provides the developer environment, and not so much the operating system. Again, (it) has to do with raising the level of abstraction.

Q: With so much attention paid to lower and mid-range-environments, is there anything interesting going on in large systems programming right now?

Booch: There is some really interesting stuff to be learned from the deep computing community. These are the really computationally intense massive tera grid things for predicting weather and doing simulations on a massive scale. It is a relatively small community, but in a number of ways it is telegraphing the issues that the global enterprise is starting to address. This is why I am so interested in the whole patterns space because this is a community that I am engaging with to see what I can learn about those patterns that we can apply to large enterprise systems. Things like how do I deal with tens of thousands -- if not hundreds of thousands -- of devices all collaborating with one another? How do I program those things? Service-oriented architectures represent another piece of this punctuated equilibrium, if you will, for how to address that level of complexity. We are in the very early stages. We do not have a lot of best practices for how one builds truly service-oriented architectures.

Q: How about starting with Web services?

Booch: Precisely. You start with Web services and you start with good solid object-oriented architectures. Why? Because the fundamentals of engineering like good abstractions, good separation of concerns never go out of style. Just because we have yet another set of protocols does not mean those things get thrown away.

Q: Good blocking and tackling.

Booch. Yes. It all goes back to the fundamentals. Despite what the latest statistics say, good engineering is always in style.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about BMW Group AustraliaEquilibriumIBM AustraliaMicrosoftQuickenRational SoftwareTera

Show Comments