Architecture Conceivability

One the most important tasks for software architects in the early stages of any technology delivery program is to reach “architecture conceivability”, or consensus agreement with senior developers that the technical proposition could actually conceivably be workable. Starting from a position of defensive scepticism, it typically entails an outside-in narrative exploration of the potential end-to-end program execution flows at a level of detail between the Component and Code levels in the C4 Architecture Model for key use cases.

The granularity of the discussion will switch depending on the level of technical risk entailed by the component. If it is providing a standard capability that is self-evident to to those present how to code, then there is no point doing the more detailed code discussion. If it is encoding anything with a non-trivial level of technical risk, then dropping down to the next level will be required until everyone is roughly on the same page about how it needs to work. In this way it acts a bit like a code preview (as opposed to a code review), functioning in the same way that a delivery prespective is more efficient than a retrospective in terms of mitigating risk.

Once and only once this has been completed, you will have established baseline viability for the program. The narrative described will be unquestionably wrong, inefficient, full of flaws – that’s not the point. The point is that it will represent a first, stuttering, throwaway sketch out which a simple, resilient system design can eventually be evolved. Gaping holes and pointless layers of cruft will already be visible. Beyond that, most of the selective pressures driving that evolution will be created later by writing tests and the feedback from coding itself.

That’s all fine. However, until you’ve established architecture conceivability, in reality you’ve got nothing. It is hard to over-emphasise the importance of this point. Context and Container-level views are meaningless slideware (or at very best, vague indicators of business process alignment) until they are backed up by Component and Code-level views. That is solely how they gain their value, by proxy as maps to decomposing and navigating the the Code-level views of the platform. Without the code, they are essentially maps to nothing.