I’m honored to have received the following endorsement from a top software architecture expert from the Software Engineering Institute. Paulo has been reading drafts of my book, Just Enough Software Architecture, over the past few months and provided essential insights that have improved the book greatly.

This book reflects the author’s rare mix of deep knowledge of software architecture concepts and extensive industry experience as a developer. If you’re an architect, you will want the developers in your organization to read this book. If you’re a developer, do read it. The book is about architecture in real (not ideal) software projects. It describes a context that you recognize and then it shows you how to improve your design practice in that context.

— Paulo Merson, Visiting Scientist at the Software Engineering Institute, and practicing software architect

My friend from CMU (now at Microsoft), Jeff Stylos, mentioned in a presentation that the .Net framework was so big that its documentation was bigger than, well, I’ll let him tell you (excerpted from an email with permission):

• There are more than 13,000 classes and structures and hundreds of thousands of methods in the .NET Framework.
• The documentation is three DVDs worth (~10 gigs) of compressed, textual documentation, compared to say the Pascal reference (~200 printed pages) or the complete works of William Shakespeare (2 megs compressed, 5 megs uncompr

People used to say that nobody ever got fired for buying IBM. IBM mainframe systems dominated the market and the assumption was that choosing an IBM system was reasonable. Today, many domains have a software architecture that dominates the same way that IBM mainframes once did. These are presumptive architectures.

A presumptive architecture is a software architecture (or a family of architectures) that is dominant in a particular domain. Rather than justifying their choice to use it, developers in that domain may have to justify a choice that differs from the presumptive architecture. Incurious developers may not even seriously consider other architectures or have the misapprehension that all software should conform to the presumptive architecture.

InfoQ has posted an interview with Philippe Kruchten from SDC. In it, he talks about agile, architecture, and process among other topics. Here are some bits I found interesting with some commentary.

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