We (Still) Need Architects

I wholeheartedly agree with Martin Fowler and his on-point paper on software architecture. I find it quite refreshing to see someone who, with expertise, understands our domain.

Yes! Architecture is a shared understanding of how the most important things of our systems are organized, and how they communicate with each other, that only happens in successful projects. Regarding the issue of defining these important things, these things are important because the expert developers say so. This seems arbitrary, even contrary to the perceived view of software as an engineering field, which still kind of is. But it kind of is a social exercise too, because we reflect our understanding of the world, an understanding that most often is achieved through socialization, into programming constructs. Given this, Ralph Johnson totally nails it in the article’s last paragraph: “Software … is limited by imagination, by design, by organization … by properties of people, not by properties of the world.”

The hypothesis of reversibility, or the lack thereof, as a measure of complexity is quite innovative. I haven’t thought of software architecture that way, but it seems quite a natural assertion to make. For instance, as an analogy, the complexity of a legal case is given by how (ir)reversible the proved actions of a defendant are. A life is irreversible, but money up to a certain quantity is less so. Of course, like in life, we need guides advising us into making right choices, or else we face the consequences of irreversible (and regrettable) actions. Similarly, the value of a software architect, as is stated in the article, is a measure of her guidance and counselling.

Just like any social constructs, they are born out of people since, collectively, individuals weave the social tissue. “We have met the enemy, and he is us.” The way we weave the social tissue is through language, and our common understanding of it. Thus, to ease “the hardest parts”, or the most irreversible things, of our system, we ought to think outside the bounding rules of language. This may be not an issue of implementation, but of tools and ways of thinking.

Kudos to Martin Fowler.

Fowler, M. (July, 2003) Who Needs an Architect? IEEE Software. Retrieved from: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf