I’ve just finished reading Ford’s, Parson’s, and Kua’s recent book, Building Evolutionary Architectures. Building Evolutionary Architectures is the software architecture guide for the 21st century. The couple hours that I spent reading it was well compensated by what I have learned.
The organisations where I have worked have all failed to quantify the quality of their architectures. I’ve worked hard to get IT departments to measure themselves, and I’ve even devised some ways to quantify the productivity of software architects. Those measures were obviously flawed, but not so badly that they lacked any utility. Building Evolutionary Architectures instead points out that the architectures themselves should be scored. Putting a single score on an architecture isn’t a trivial exercise, but it certainly beats not rating your architectures, or saying that any architecture that is “understood” and not “obviously” “worse” than the “obvious” alternatives, is “good” enough. Now that my attention has been drawn, I can’t even describe that review process without emphasising it many flaws. (I’ve quoted the words which try to conceal those flaws.) And, in retrospect, that flawed qualitative model describes the better run architecture practices where I have worked. It certainly beats the most common model, where the architecture exists only as a document that none of the developers read, and therefore whose existence is only for process compliance.
I recommend Building Evolutionary Architectures, and I look forward to scoring every artifact of the software process. Then I look forward to a cycle of continuous improvement in software documents, whose benefits should rival those of past decade’s advances in software itself.