So are we in the near term going to see anything like "verticalized" tools for vertical markets?

Yeah, I think you will. And through the efforts of Grant Larsen, who is our patterns czar for the software group, driving a lot of the interesting stuff in that space, what we realized, especially with IBM aligning more and more of its field to specific verticals, is that there is such a domain-specific language and culture in those verticals that you can get middleware, which covers a lot of horizontal stuff. But now those verticals are where the action is happening. Because, frankly, J2EE [Java 2 Enterprise Edition] and .Net are still too complex for the average developer. So, yes, we see the growth of those particular vertical patterns in all those places.

Do you expect to deliver that?

It's certainly the plan of record for what we're doing in the pattern space. In fact, if you go to the developerWorks site, the intent with the plan of record is to expose a number of those patterns because they're there for the harvesting. IBM already has precedence in things like the Insurance Application Architecture, which is used by some 85 percent of that community.

Frankly, IBM failed in a project called San Francisco some years ago. And I think the primary reason they failed is A) they over-engineered it; and B) they produced those frameworks by creating them from whole cloth as opposed to harvesting. And our experience thus far is the best architectural patterns are extracted from the ashes of existing systems. And that's the effort that Grant has been leading, to do that kind of extraction.

And the MDA piece of it fits in as well, because then MDA represents the automation part of the patterns and now this represents the content piece of this one.

You just did a talk on software archeology. What is that all about?

There are three major points that I made. The first is especially in today's world of building consistently of all these systems, rarely do we start green field, but there's a tremendous amount of activity to look at existing systems and adapt them, reuse pieces of them into what we have. And oftentimes, too, people are parachuted into a system saying go fix this and not having a lot of context.

So there is emerging a body of knowledge about what it means to do an archeological dig, what processes are necessary for us to be launched into a system and intentionally seek out a reconstruction of its design. Because even though we may have the code, there is entropy at play. I have the design here, the code's here at this end, and there's a loss of information as I move it to code. So what can we do process-wise and tool-wise to re-create that kind of stuff. We know today sort of some macro processes how to do that. And that's what I described in my talk. There are some people who have looked at micro processes. There's a great book called "Software Exorcism," which sort of looks at the debugging and investigation process. So good stuff is happening in that space.

As we move to those kind of skills, we recognize there's still one gap, which we as an industry don't have a lot of tools to help us do those digs. As I showed in today's talk, we reverse-engineered the architecture of Eclipse. And it was easy in the sense that we had all the source code for it. Because in many cases you don't have all the source code. And yet there aren't a lot of design documents for Eclipse that lie around.

Most enriching design information is in tribal memory—in the heads of people who actually wrote it. And they haven't extracted it. So what we found in this process is we can reverse-engineer it, we can build some models, but extracting the patterns from those models is very, very hard and it requires human intervention. I think that there are opportunities for some degree of automation to identify patterns from that cacophony of classes. And that's an area of research that the industry needs to spend some focus on. The second point I made was actually mentioning the handbook project I talked about. My intent is to look at 100 different systems around the world and codify their architectures, because no such reference exists for software engineers these days. Architects have to learn by doing, and I'm trying to provide a reference for them. So we're looking at lots of different systems.

And the third point I made was an effort we have with the Computer History Museum to preserve classic software. So we've intentionally gone after a variety of seminal systems that, frankly, our industry has given much to the world; it would be sad if we lost a lot of those artifacts. So the intent is to capture the source code, capture the artifacts around it, interview the people who did it, so it'll be preserved for future generations.

I actually went into some depth about MacPaint. Because the source code to MacPaint fell into my lap about a month ago. Tim O'Reilly has been involved in this effort; he had been talking to Andy Hertzfeld and Bill Atkinson and he mentioned it to them, and Bill and Andy got in touch with me and said: "We've got the code." And actually there's an interesting back story about how they got it, because it had been sitting in Bill's garage on Lisa disks. And he didn't have a Lisa around, but the end of the story is Andy was able to deliver me a CD-ROM with the source code for MacPaint.

And about two or three weeks ago I did an interview with both Andy and Bill, and we have a video interview of this stuff. So it's very cool. And we want to do this for many other systems. So that's a real instance of an archeological dig.

I have in my office the original source code to the Multics kernel. We have one of Bill Gates' original tapes for his first BASIC program. We're looking at a whole bunch of stuff like that. Dan Bricklin we've been in touch with. We'd like to get the source code to VisiCalc.

Next Page: Simplifying Rational's tool set.