Once I am done with this book, I have good intentions of creating a Slashdot-like site devoted to software architecture. I’m frustrated with how hard it is to find interesting material and I hope others would be willing to help me feed the site. Until then, here are some interesting links I’ve come across:

• An overview of cloud computing.

I’m speaking at the SATURN conference in Minneapolis next month. If you are thinking of going, now is the time to register so that you can get the $650 registration (instead of $950).

An old friend called me up last week to have lunch and pick my brain on software architecture. We’ve worked together building software in the past but he’s been tempted by the dark side and is now the CEO of a startup company. He needed his engineers to build an architecture model of their running system ASAP. Fortunately, I had some materials ready for him to glance over.

After he and his engineering team read over my book, they drew up a model of their system and I reviewed it with them.

I’ve been quiet on the blogging front but that is because I’m in the final push on the book, which should be going to the publisher in about a month. If any of you would like to review a chapter, please let me know and I’ll send it off to you. At this point I’m not looking for wordsmithing/typo feedback, but things like missing references to related work or arguments that need to be strengthened. There are already a couple chapters posted for you to get a taste of what the final book will be like.

Why am I the last one to learn these things? :-) This from the IFIP page

WICSA 2011 will be held June 2011 in Boulder, CO co-located with CompArch.

Even if they’re not here because of me, I’m happy.

I will be speaking on 6 May 2010 at the Denver IASA IT Architecture (ITARC) Conference. And yes, I have the coveted 5:30-6:30pm slot :-) The talk will be about Architecture Haiku: One-Page Architecture Descriptions.

You can’t say anything in one page — or can you? An Architecture Haiku is a one-page, quick-to-build, uber-terse design description. No agile project wants “shelfware” documentation, but many must communicate their design to others. Brevity is hard — what would you say in one page?

20 years of architecture research suggests that tradeoffs, quality attribute priorities, architecture styles, and constraints are short yet valuable. This tutorial teaches a new agile design practice that helps your team understand its design and communicate it with others.

Normally, when someone starts talking about architecture, they can go on forever — it seems like almost anything can be considered architectural. One interesting thing about constraining the description to one page (an architecure haiku) is that it 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.

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.

The conference is cheap — just $150 if you join IASA ($50) and register in early April.

Edit 9 Aug 2010: Slides from Architecture Haiku talk

In case you were wondering what my book on software architecture will be like, you can now see the video that describes its basics. This talk was given at a joint session of the Denver IASA and the Agile Denver groups on 16 November 2009. The topic is the Risk-Centric Model of software architecture, which helps you answer the question, "How much architecture/design should I do?"

The first 17 minutes of the talk are a quick summary of software architecture; the remainder describes the Risk-Centric Model.

Here is a direct link to the video, in case you cannot see it embedded here:
An Introduction to Software Architecture and the Risk-Centric Model from George Fairbanks.

Here is a short excerpt from my forthcoming book on software architecture

——

Over time, a team understands increasingly well how a system should be designed. This is true regardless of which kind of process a team follows (e.g., waterfall or iterative processes). In the beginning, they know and understand less. After some work (design, prototyping, iterations, etc.) they have better grounded opinions on suitable designs.

Once they recognize that their code does not represent the best design (e.g., by detecting code smells), they have two choices. One is to ignore the divergence, which yields technical debt. If allowed to accumulate, the system will become a Big Ball of Mud. The other is to refactor the code, which keeps it maintainable. This second option is well described by Brian Foote and William Opdyke in their patterns on software lifecycle.

Refactoring, by definition, means re-design and its scale can vary. Sometimes the refactorings involve just a handful of objects or some localized code. But other times it involves more sweeping architectural changes, called architecture refactoring. Since little published guidance exists, architectural refactoring is generally performed ad hoc.

Yes, embedding a Dilbert cartoon is just too easy — but it provides a memorable lesson about why quality attributes, by themselves, are not as good as quality attribute scenarios. Before I bore you, the cartoon:

Perhaps it is important for your system to have security. We could all guess what that means, but we’d all likely guess slightly different things. I might guess it means that bad guys could not retrieve info. You might guess it means bad guys could not alter info. And someone else might point out that there is no currently known way to allow good guys to retrieve and alter info without a dedicated bad guy having some chance of access.

I will be speaking about Design Fragments and software frameworks at the University of Colorado (Boulder) computer science colloquium on 4 March 2010 at 3:30pm.

Edit 10 March 2010: Now with video:

Presentation on Design Fragments at the University of Colorado Boulder.