Frontier Exclusive Visionary Interview for hardware, software, system related business and and academia



Frontier Journal (FJ): Frontier Journal is interviewing Grady Booch. Grady Booch is an icon in software industry; he is the Chief Scientist at IBM Rational, also an IBM Fellow. Grady, I note that your project is handbook of software architecture. So I would like to know your perspective on the architecture of software architecture, let's say, the DNA of software architecture.

Grady Booch (GB): Well, there are a couple of phrases that come to mind that I think answers your questions. First, we know that every software intensive system has architecture, it's just that most of them are accidental as opposed to intentional. Architecture is born from the tens of thousands of decisions that are made during the development and the deployment, and the evolution of a system. And therefore, for every system that we can come up to and say that it has an architecture that we can name of this particular style. Although, while that system is being created, the developers often don't know exactly the style that they are creating, it's through those many decisions that we put together.

Now, that's both a good thing, as well as a bad thing. The bad thing of it is, its not very intentional and so for new systems, it means there's a lot of discovery, and scrap and rework. For a lot of old systems, it means there are probably lots of inefficiencies therein, that's the bad side.

The good side is that we can actually build from this. And indeed, one of the efforts of the handbook is to do a practical study of a hundred systems that represent the spectrum of software engineering systems, and try to extract those common architectures so that we can begin to name them. The patterns community has done an excellent job in cataloging design patterns, and one of the efforts that we all are doing here, is to begin to catalogue architectural patterns. So, in a sense, it's a naming of that DNA.

FJ: Thank you. So, you mentioned the software architecture, so lets do a follow up question on SOA. SOAs pack the entire software engineering challenges from the perspective of business use, instead of technological use, what we call design use. So, my question is how to bridge the gap between business use and design use. Because I'm sure there are levels for business use is the first level, the service level, and the components level.

GB: Well, lets talk about the newest trend for the moment, because there are a number of merits behind it, and then I'll lead you to the issue of Service-Oriented Architecture itself. On the economic side, reality is that there is a threshold one must cross before the reuse of some entity becomes sensible. If I'm dealing with individual line decode, cutting and pasting them, as many do, by looking on the web and saying, what do I need to do here, I'll all cut and paste it from a script, that's reuse in a sense, but that's not economically very compelling. At the other end of the spectrum there is the reuse of an entire system, and that's compelling because there is tremendous functionality add a modage issue. Therefore, where is the threshold in the middle for which the economics of reuse makes sense, and the answer is probably at some component level, if we're very loose about what we mean as components. And certainly, using parts of system as we can do, be of services is economically viable, and using patterns is also economically viable. The latter less, because it transcends the individual line decode that we cut across. So that's the economics of software. In to some degree, mostly to a large degree, that's what's driving a lot of service-oriented architecture, because this gives us an ability to bolt together systems that we know are relatively affective, and tie into them these services and reuses them, so the economics makes sense.

Now, that leads us to the service oriented architectures in general. I have kind of a jaded view of service-oriented architecture versus others perhaps, because for me, a service-oriented architecture is just an architectural pattern with a particular instantiation, the pattern being a simple loosely coupled message passing system. And the technology incarnation being either web services, which I call services of the big S, or other kinds of services, services of the small S, the RPC, you know kicks, those kinds of mechanisms. But nonetheless, it all represents a common kind of pattern, which is this message-passing thing.

Those organizations that seem to be successful in moving the service-oriented architectures, and by successful I mean, they have a key some interspacing degree of reuse. These are the ones who have already some attention upon architecture, and therefore, can understand best where to place those services. Organizations that say, I just want to get me some SOA and start slapping services around their systems will generally can't get the economic benefits.

FJ: Thank you. Okay, in terms of software engineering, you've been working on Zair for many decades. Now lets talk about something like, nowadays we have Meta-model, Meta-language, Meta-data, a lot of Meta, so what do you think about Meta. Where is Meta in software engineering? They sometimes have Meta systems.

GB: I understand. We know that we software developers are ultimately dealing with artifacts that have a great semantic density to them. And we can only do meaningful things with them, if in fact we understand the semantics of the system themselves. Therefore it's understandable why we see this drive towards more Meta things.

FJ: I see. You mentioned about Web Services in your previous answer, so lets talk about Web services a little bit and about the future success of Web services. It looks like, you know, its all the simple stuff works best, because the concept of web services has been there for near a decade or so. But it is very competitive, so its all looks like to not work well, and the wide adoption looks quite slow, in term of web service.

GB: I think its slow because the infrastructure that most organizations have in their developer organizations are not well suited to deal with the delivery or use of services. They're more used to stovepipe kind of thing, and simply, they are not institutionalized to do the services well.

FJ: So, during our previous interview, I asked you what's your perception of programming paradigm shift. The interaction between programming languages and program paradigm. I would ask a question about the relationship among computation model, program languages, software process, and a little bit of other things. You know, in 1970's, it was basically mainframe scene. And later in 80's, client/server, dominated by , client/server. And in 90's, it was server based computing, which was Internet based kind of computation model. Now in this decade, its web services based P2P, or some thing like that. So the computation models have been changing. What kind of impact does that have on software developing methodology, and also, programming paradigm?

GB: Well I think there are a couple of obvious changes, and I'd like to offer, when I'm done with those answers, what I see coming next. The obvious one is the move towards the architecture that are by and large loosely coupled distributed systems. This is what is pushing us to SOA in particular. We know from the work of Herbert A. Simon and the others, in his book "The Sciences Of The Artificial", that complex systems that are loosely coupled tend to be most resilient to change, and we certainly see this in large-scale software systems. It's can also be said that this has therefore led to more agile kind of methods, the notion of evolving a system's architecture to the successive refinement to literature and incremental releases. Now agile is not that new to us in Rational, because that's the embodiment of the Rational Unified Process. But this is a notion that has taken on elsewhere.

Now that's the present day forces that people are dealing with, but we can see the writing on the wall for what's happening next. This is where W3C is working on the Semantic Web, again it's the whole Meta concept of exploiting the semantics of this information that we're passing about. And it is completely out of the spectrum where most people are watching. The issue is, the rise of multi core processors, where we're having to deal with intimate concurrency, and we're ill suited in terms of languages and processes to deal with that.

FJ: I understand. So in terms of the most aspects of software engineering actually is a kind of art instead of science. So what are your ideas, indeed it is harder. You said yes to actually its typically incremental development based software processor and it protects, seems to works well in reality.

GB: Yes, it truly does.

FJ: As you mentioned software architecture finishing patent harvesting, when and which kind of level will as harvesting is also difficult. I would like to know if that is possible or if it is happening, software architecture itself can be evolutional, and also, self-adaptable, as time goes?

GB: I would agree with you that systems architecture do evolve all the time. One of the things that I've learned in my handbook work thus far, is that every economically interesting system appears to have major periods of architectural stability, and then disruption. There's a large auctioning system I've been working with to tell me. They've probably gone about 5 different major architectures, and that number of architectures is not unusual for systems of that size. The difficulty for them and others of that area, is that there are many forces upon them at the moment, they're at the point where there's such an inertia to change, it is difficult for them to change the architecture out. They can't blow it up and start over, so they're truly in a period of continuous evolution.

FJ: So what your biggest achievements at Rational, was UML. My next question is, by laying a new lab, we are able to deal with system complex models initials, and there would be model refinement, where it is automated or manual. So in operation especially, there is a key for work. I would like to ask you, we have compiler for code compilation or model compilation, model generation, and we have compilers' compiler. For example, Lex/Flex and Yacc/Bison, or some kind of things. Help us to generate the compiler. Is that possible for us to have compilers' compilers' compiler, which can generate model, or even sometimes generate architecture? Of course we can generate code for future generation of software architecture.

GB: Indeed what you're beginning to speak of, by the way I must commend you, because you are asking me some very good questions, you're a good interviewer, but what leads to mind, is the notion of, what we call 'generated pattern languages', the idea that one can have a pattern, that leads you to other patterns and other patterns, based upon the forces around it. So, there are a few groups I'm aware of, who are beginning to look at pattern composition systems that way. But we're a long way from there because, for one, the platforms upon which we run these things are not necessarily very codifieable. And on the other hand, we also haven't really codified a lot of the patterns that are bringing these things together. So on both of those points I should mention, in the handbook, we have catalogued about 2,000 design patterns, and the fact that there are so many, really speaks well for the vibrancy of that community.

FJ: So you say that pattern generation will make a pattern discovering harvesting almost automatic?

GB: Well, for certain domains. I wouldn't go far as I have control over the platform, then it may become easier for me to do so. Theoretically yes, but pragmatically, it's still pretty hard to do so.

FJ: Good, good, this is a very good direction to go. We discuss something cool, actively involved in life, like presentation, for you know, product making, a lot of things because you are very busy in terms of schedule. So do you think, in the near future, our signal life will replace the most part of our first life. So that we don't need to travel.

GB: Actually, virtual world has already probably saved me at least a dozen trips, and so I have saved IBM money, by doing this. In fact I have the next lecture I'm giving in Second life, I happened to be London at the time, and I need to give a presentation in Brazil, and so, rather than jetting down there, I'm just gonna find a quiet room and do this. It has saved time and money for me. And probably the most important thing for me is it that it's allowed me to be, what you call in the military world, a force multiplier. I can be in more places than one. Plus, also much importantly, I'm much better looking in SecondLife.

FJ: yeah, so you have multiple viewers...

GB: Yes, correct.

FJ: So in terms of software productivity, I have this following question. For example, we have many programming paradigms, many programming languages. Software processes. and we have lots of software architecture, what do you think which is the most vital? Which has the most significant impact of software productivity, if you can pick one?

GB: So I'm hearing you ask is, what are the things that have most impact on software productivity. Well, the most important one is people, because all things be equal, I'm sure one thing that I'm an experienced, qualified person than anything else. They have no, or not a lot of control over skills, which they can bring into their groups. Its point of friction. And there's a paper that's on my website, they talked about the problems of collaborative development. In there I note what I called the points of friction of development. It's largely, because there are not technical issues, but their social issues. Its primary too, it's the cost of communication, and it's the cost of retention of memory of the organization. So just think about the issues of communication, I make a change and somebody later on is gonna use the change I've done, and yet I'm not around to talk to them, how do I communicate with them the intent of that change. And there's a cost in doing so. Its also the case of trivial memory, in this I may be the best architect, and I do these things, and yet, code is the ultimate truth but its not the whole truth, because it does not embody the Rational design pattern and so there's a loss of that trivial memory in the code itself. Those are the things, that over time are the most costly that cause the most friction. Therefore it makes more sense to say, what are the things that we can do to agree to make the automation and those design decisions are made part of the artifacts of the system itself, so that it could be saved on, and this is where we're trying to head with jazz to some degree. And also in so far is that Rational is there, then that information can be passed on. It can be passed both by tools, and the processies that grow that software over time.

FJ: So, what you mean is corroboration is very important, and knowledge of accumulation, knowledge of creation, and knowledge of sharing are also very important. You're point of view is actually that people are the most important, and other things are mostly secondary. I have one more question to go. That would be excellent. What's your perspective of innovation in software engineering? Let me give you an example, most of us, or most, understand that innovation in operating system with most response with the reason to success are we, and where suddenly is the concept of global market through computing, computation. So, which means is innovation back in OS domain? So what is your perspective of innovation in other sectors of software engineering, especially software architecture design methodology, etc. Do you expect anything new and exciting within 3 to 5 years?

GB: Well, 3 to 5 years is a good observation, because that's the time frame that I worry about.

And I would say yes, I think that there are some exciting things in a sense of software intensive systems, although I tend to be one to believe in evolution, as opposed to revolution. That is, I look back at the innovation in software engineering in the labs, you know, 2, 3 decades, which is in my career, that get you to really think that the public may consider revolutionary, but you can see the little bits and pieces that may come together. I mean, what Tim did with the web, there was a lot of experimenting at that time that made what he did possible. I think the same is true right now. I think my predictions are, that there will probably be some disruptive technologies, of course one can never predict disruption. But these are things like, what's happening with the Semantic Web, web protocols amass space, the evolution of digital paper, which means we'll isolate what we didn't have yesterday, and that's going to pull a lot of innovation. And I mentioned earlier also, the problems of the multi-core development. We know that to get out of the Moore's Law issue right now, because we're dealing with raw physics problems that are limiting factors. Then moving from single core to multi-core is the obvious next step. And we don't know how to harness that yet, so I think there will be a lot of interesting developments in that space. FJ: Grady, I appreciate your time. Thank you.

GB: You're very welcome. And again I must commend you. You have asked some excellent questions.

FJ: Thank you, bye bye.


Back to Home Page