Last week was an exciting one as the CompArch/WICSA conference came to my hometown of Boulder. I was one of the conference chairs, the one in charge of the unglamorous task of organization, but the good news is that everyone was delighted by that! We had a great mix of folks from two different backgrounds and there was lots of mingling and ideas shared between them. The reception dinner at the Red Lion Inn on the Boulder Creek (swollen with snow melt runoff) was really great. (And yes, that restaurant choice was Judy Stafford’s idea!)
I presented a tutorial on the idea of an “Architecture Haiku”, which is a super-short architectural description suitable for use in Agile projects. Architecture Haiku tutorial slides PDF. Here’s the description:
You can’t say anything in one page — or can you? An Architecture Haiku is a one-page, quick-to-build, über-terse design description. No project wants “shelfware” documentation, but many must communicate their design to others. Brevity is hard — what would you say in one page? With no page limit, experts suggest documenting everything but the kitchen sink. The one-page limit forces you to convey the essence of your design using compact language and concepts.
Normally, when someone starts talking about architecture, they can go on forever — it seems like almost anything can be considered architectural. Constraining the description to one page (an architecture haiku) forces people to make choices. Consequently, they have to be direct and use the most compact language possible. Another interesting thing is that it clearly isn’t BDUF (Big Design Up Front).
Most folks who are asked to write their architecture on one page have a hard time. The point of the tutorial is to demonstrate that it is hard — hence asking the participants to do it themselves — but also go give a whirlwind tour of the essential ingredients of an architecture description. E.g., modules vs. components, viewtypes (module, runtime, allocation), quality attributes, tradeoffs, drivers, architecture patterns (map-reduce, client-server, n-tier, …). These are elements that aren’t directly expressible in programming languages (i.e., bigger than classes), so most developers won’t have a crisp idea about them.
This tutorial’s direct objectives are to teach the participants how to tersely describe their architecture. This is desirable because few developers want to spend much time on architecture descriptions and one-page descriptions cannot take too long. The indirect objectives are to teach the canonical basics of software architecture including its terminology and standard abstractions. This normally dry subject is made interesting and relevant through the artificial one-page limit. Just as design patterns enabled compact, efficient communication about object- and class-level designs, software architecture concepts and terminology enables efficient communication about larger design ideas.
I also moderated a panel discussion on Agile and Architecture featuring Philippe Kruchten, Dean Leffingwell, Ryan Martens, and Michael Stal. In a straw poll of the audience, only a couple of people said they were skeptical that Agile and Architecture could work together – the vast majority thought there would be friction but that they could coexist on projects.
Rhino Research is devoted to improving the state of software practice. We do this by using our industrial and academic roots to give you the freshest and most practical advice in classes and during consulting engagements.
We have taught classes for many kinds of clients, ranging from regular information technology shops, to huge internet shops, to NASA.
subscribe via RSS
