No doubt, there is much content available for active management and design of architecture. In deed there is so much, that one can wonder, why there are so many systems out having a bad architecture. I am sure, that is true for non-software related systems as well – at least partially. Howvever as I am definitely not an expert in other businesses I stay focused on architecture of software systems.
I would like to refer to IEEE 1471 definition of Architecture: “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
This definition seems to be wisely written – it contains the structured approach byusing words like “organization” and “design” as well as the emergent character by “embody” and “evolution”. This emphasizes – my interpretation – that you actively can drive and design an architecture but get “architecture” as a characterisitic under the hood as well.
I think there is not much need to delve into the wellunderstood topics of focused architecture design and management as many books, articles and guidelines are available, which are worth reading. I know that agile architecture management is a bit less discussed but still one gets some hits on an interent search. My starting position is different two both in thinking about architecture not actively addressed at all. There is not much thinking necessary – just by writing software one creates something that has architectural flavour. Even if one just has a very simple program consisting of one class (main) one has embodied design – in this case the fact, that it is monolithic. The second class requires thinking in organization and structure and contains many design decisions on top. The more the decision one takes the more architecture a system has. Probably not an architecture providing desired characteristics like loose coupling or maintainablility but some kind of intrinsic architecture.
Looking for a methapor I stumpled over ants and anthills – while reading in a book about emergent systems. An Anthill has an organization – thus I would say an architecture – that serves the ants quite well (as I assume again). However there is no obvious central builder or architect dictating next moves and building blocks. Any ant working on the ant hill has a build in blue print, structure or even only some basic instructions how to build the ant hill. Every work and contribution is so to say equal to others. Organization emerges via recognizing local needs, structures and the closer environment. If there is e.g. a tunnel in the hill it is likely to persist over some time and the hill is growing because the location where it was build is accepted (even if this is only true in average).
A stupid thought experiment – far from being realizable – how can we encourage ants to build a better hill (if this is possible at all) – e.g. requiring less ground, material and providing more internal space (very human perception). Building a central plan does not work – because there is no real hierarchy in an ant colony. The only chance is to empower each single ant with a “better” blueprint. Each worker has to understand the improved design and act according to it.
Maybe you figured out where I am heading to – how can we transport that inside onto large software development projects? Simply stated – everybody working on the big project has to act according the blue print. Obviously this comparision is poor with respect to many aspects but opend up my mind for one point, that I personally underestimated for quite a while. It is the fact, that one needs to address the insight of software project participants much more. Assuming that over better insight the actions are more according the global plan. The only way I know to address this is communication – if I excludes pychological manipulation and related stuff.
Luckily software projects can have an active and separate design process, which can be managed e.g. via governance of projects and by reviewing designs and the like. And for today my only take away is that we should not forget to address the intrinsic aspect of design and governance is very important but not sufficient.