Egoless architecture
What is architecture? Which could be the shared properties among diverse schools of thought and practice of architecture? Complexity management is possibly a common property among these kinds of design disciplines. Such complexity is present in many respects; some are of essential complexity, some of accidental complexity; some are about people interaction, some others about process, and others about technology —to mention just a few. Yet another respect, which is all-encompassing, is the usage of the thing being architected.
My main point in this brief comment is that complexity management is pervasive and architecture needs to be practiced by all participants in a project for building any non-trivial system, not just by those with the word ‘architect’ in their job title. Mainly because, in software, the role of the bricklayer is perfectly fulfilled by the compiler and the computer itself —as these core technologies are very good at repetitive and non-creative tasks.
The same key observations and good practices proposed by Gerald M. Weinberg can be applied here: egoless architecting. For an evidence of why this is relevant, reflect on possible responses from a so-called architect when his work is challenged or its defects are pointed out.
Composing software is a recent activity, perhaps just 60 years old. It is like an infant among other adult professions, like architecture —the well-established one. The tendency of a child to mimic the adults around him is a completely normal human attitude, just as normal as the overcoming, later in life, of such attitude. The same child, and if he grows up, starts to be aware of his own identity and the quest for independence continues.
The software industry has tried to mimic old and outdated perspectives from manufacturing; for instance, the notion of division of labor. This notion has been, in part, behind the idea of roles like ‘analyst’, ‘designer’, ‘programmer’, ‘tester’. These roles can be mapped exactly with related stages of the waterfall lifecycle model: analysis, design, programming, testing. Hence, ‘architect’ and ‘architecture’, as an independent role and as a discrete stage in the lifecycle, respectively, is another evidence of the imitation many people in this industry continue doing; also, it is an evidence of the childish age of this industry. If we think in a linear sequence and pick one of those activities as the first stage, followed by another as a second stage, and so on, then accidental complexity is added unnecessarily.
On the other hand, in more mature sectors of this industry, composing software that works robustly and flexibly across many successive releases requires all capacities at once. In this way, specification, testing, architecting, deploying, analyzing, etc., are not stages in the software lifecycle but concurrent activities. As we grow up as more complete and more mature software professionals and software consumers, we can focus more in the usage of the software, and less in our egos, and we can also realize that it is about architecting, not about “architecture” or about “architect”.