What's There Instead

"The real grand challenge for software engineering research is relevance."

I'm not particularly observant at the best of times—it's one of the reasons I don't drive—but even so, I've been kicking myself for not noticing something about The Architecture of Open Source Applications in time to include a note in the introduction. There are over 100 diagrams in the book, only half a dozen of which use any standard modeling notation like UML. Putting it another way, experienced software architects don't believe that a standard modeling notation is the best way to communicate their ideas roughly 95% of the time. It's not ignorance: I'm positive that everyone who helped write a chapter for the book would immediately recognize UML, and could draw a more-or-less legal class diagram or sequence diagram if asked to. And it wasn't laziness, either, or a side effect of them dumbing down their work for a lay audience. Of course, that observation raises a question: what do they use instead? What exactly do experienced designers describe when they describe the "architecture" of their software? I think that AOSA is a unprecedented opportunity to find out. A careful analysis of what its contributors do and don't say (the kind of qualitative study typified by several of the chapters in Making Software) could tell us what modeling notations for software architecture need to include for software architects to find them compelling. It would be a hell of a paper, but I'm not an academic any more, and other things are more pressing. If you'd like to take a crack at it, please let me know—I'd be happy to introduce you to our contributors.
comments powered by Disqus