Grady Booch | Avoid the 'stupid' SOA approach
Connecting state and local government leaders
A few months ago, when famed software designer Grady Booch spoke before a packed auditorium in Washington, he tried to temper some of the fevered expectations swirling about services-oriented architectures, describing where SOA would and would not be useful.
A few months ago, when famed software designer Grady Booch spoke before a packed auditorium in Washington, he tried to temper some of the fevered expectations swirling about services-oriented architectures, describing where SOA would and would not be useful.He speaks from experience. Along with Ivar Jacobson and James Rumbaugh, Booch developed the Unified Modeling Language, now widely used to design complex systems. He's one of the pioneers of object-oriented programming, and his company, Rational Software, was purchased by IBM Corp.While in Washington, Booch likened software design to architecture: Solid architectural design is the basis for enduring quality, and bad design is a recipe for disaster. While civil engineers have understood this for centuries, he told GCN, software architects are just beginning to get it.Booch: First, there is way too much hype about it. The idea of services is not a means of abstraction. It is simply a mechanism for reaching into systems. You see organizations rushing to [implement] services, but they are really missing the fundamental engineering principles. In about 18 months, they will complain SOA doesn't work. They'll be blaming the wrong thing. They should be blaming their architectures and best practices.I did some work with Homeland Security folks two months ago, and'this is gross simplification'they said, 'What we want to do is cut across silos, plant some services, so we can get into the data and do cool things.'And I told them that that is really a very stupid approach. The wrong approach is to look at the silos, identify interesting data and plant a service on it. The right direction is to lay out the scenarios you want to carry out, and see where they touch silos. A point of tangency is where there might be an opportunity for a service. Services should not be driven bottom up from technology, as DHS folks are proposing, but rather from the top down'with the use cases.This is not to say SOA is a bad thing. Like any technology, you have to approach it in meaningful ways. SOA is very useful for gluing systems together, but it does not address the internal architectures of systems.Booch: It was not like UML came out of whole cloth. In the time UML came to be, there were some interesting forces coming together. People were building larger and larger applications that were typically multiplatform and multiframework. They needed to abstract and reason about these systems in other ways. And thus was born a ferment of work in modeling. [I created] the Booch Method, which was a precursor to UML. Rumbaugh [co-created] the Object Modeling Technique, and Jacobson created the Objectory Method.There were a plethora of other methods proposed at this time, [but] those three were gaining traction. So Rational Software decided to bring everyone together, rather than fragment the marketplace. We hired Rumbaugh, and then bought Jacobson's company a year later. UML's tremendous value is that it allows me to reason about things from a variety of programming languages and platforms.Booch: UML is a graphical language for visualizing, specifying, contracting and documenting object-oriented software systems.My work really began in the federal marketplace. We formed Rational around the [Defense Department's] Ada programming language. Ada [comprised] notions of building abstract data types, which was a precursor to object-oriented programming. It was clear that there was some real value in using objects instead of structured methods. Working with the [Defense Information Systems Agency's] Ada Joint Program Office, I was directed to consider the design methodologies appropriate for languages like that. Thus was born the object-oriented design. I was probably the first to use the term.[C++ creator] Bjarne Stroustrup was also faced with the issues of building complex systems, so he latched onto my work. And that was what moved me from pure defense into [the] commercial sector.Booch: We know a number of circumstances where people are using UML for systems. [IBM Distinguished Engineer] Murray Cantor has been working on a UML specification for systems engineering. Especially with very complex systems, or with embedded systems, one has to deal with hardware and software trade-offs. One of the interesting features of UML is that it has features for documenting systemic issues.
GCN: What are your thoughts on SOA?
GCN: Why was UML created?
GCN: How does UML relate to object-oriented programming?
GCN: What do you think about using UML for modeling things other than objects?
GCN: What things can't UML model well?
Booch: It can't model love. It can't model peace. It actually is a good language for modeling a variety of things, but it is best suited to modeling things that ultimately [lead to] software. It is not appropriate for modeling semantic cognition. There are very academic elements of the Semantic Web dealing with the modeling of cognitive issues. Here we are talking about deep philosophical issues such as modeling meaning. UML is not intended for that.
GCN: What do you do now at IBM?
Booch: I'm a free radical. That means that I'm unmanageable. My role is to worry about the next three to five years. So the things in my head include issues of collaboration and architectural patterns. [The Department of Defense Architecture Framework] is an example of some of the stuff in the architecture space that is germane to the work I am doing. There is some heat and action with using UML to model DODAF.
GCN: So you work in specialized fields?
Booch: The two major religions of the software world'the J2EE and Microsoft .Net platforms'have entrenched themselves and are not going to change very much. The real action is at the layers above that.
What is fascinating is that most architectures live in tribal memory of projects. There is very little cross-fertilization from one group to another. I've had background in the war gaming community, so it is really fascinating to see how some of the computer game companies are now walking through the same lessons [that the Defense Department did] 20 years ago.
You can get so entrenched with one domain. I have the luxury of being able to cut across a lot of domains.
Grady Booch, IBM fellow
Rick Steele
GCN: What are your thoughts on SOA?
GCN: Why was UML created?
GCN: How does UML relate to object-oriented programming?
GCN: What do you think about using UML for modeling things other than objects?
GCN: What things can't UML model well?
Booch: It can't model love. It can't model peace. It actually is a good language for modeling a variety of things, but it is best suited to modeling things that ultimately [lead to] software. It is not appropriate for modeling semantic cognition. There are very academic elements of the Semantic Web dealing with the modeling of cognitive issues. Here we are talking about deep philosophical issues such as modeling meaning. UML is not intended for that.
GCN: What do you do now at IBM?
Booch: I'm a free radical. That means that I'm unmanageable. My role is to worry about the next three to five years. So the things in my head include issues of collaboration and architectural patterns. [The Department of Defense Architecture Framework] is an example of some of the stuff in the architecture space that is germane to the work I am doing. There is some heat and action with using UML to model DODAF.
GCN: So you work in specialized fields?
Booch: The two major religions of the software world'the J2EE and Microsoft .Net platforms'have entrenched themselves and are not going to change very much. The real action is at the layers above that.
What is fascinating is that most architectures live in tribal memory of projects. There is very little cross-fertilization from one group to another. I've had background in the war gaming community, so it is really fascinating to see how some of the computer game companies are now walking through the same lessons [that the Defense Department did] 20 years ago.
You can get so entrenched with one domain. I have the luxury of being able to cut across a lot of domains.
NEXT STORY: TECHNICAL DIFFICULTIES