Link: http://traceinthesand.com/blog/2012/05/22/conceptual-architecture-why/
Why: Motivation for the Conceptual Architecture View
Conceptual Architecture is a key medium for describing the “big picture” and essential design ideas of our system, helping others to more rapidly comprehend a complex system, how it is composed and its critical mechanisms or interworking to achieve some key internal system capability essential to sustaining itself. The Conceptual Architecture Diagram serves as a high level map of our system, providing for navigation around complex systems, location of responsibilities, and identification of dependencies.
But Conceptual Architecture is also a focus of essential design work! As we conceive of the system structure, we’re tackling questions of decomposition and modularity, with the dual of composition and emergent properties. We do so to make the system organizationally and cognitively tractable, bringing order to the system. We might think of this as a kind of “social order” if we see its elements as agents of system responsibilities, working with cohorts to deliver system capabilities and in this interaction effecting emergent properties. But even if we don’t go that far, we are at least bringing a kind of mechanical order, complete with hierarchically composed sub-orders, to the system.
Modular systems enable us to:
Early on, we’re dealing with our conceits of formative system elements — on paper. We’re crafting lo-fidelity sketch-prototypes of the system structure, and iterating across the conception of the system and our discovery and exploration of how we might conceive of, arrange and build the system. Because it is cheap to do, relying more on how generative our imagination is leveraging the grist of experience, patterns, capabilities in other systems and frameworks, and so forth, we can explore various alternatives, discovering elements and relationships, illuminating the system conception or possibilities we might offer in terms of system capabilities. We can play with different factorings of responsibilities into capabilities and onto elements. And we can evaluate our postulated alternatives with respect to coverage or completeness as well as balance, harmony, conceptual integrity and consistency, in addition to the achievement of desired system outcomes. All of which allows for a much more active, adaptive, creative exploration of the system concept and structural organization before the direction is channeled and cast in shaping, anchoring expectations and code.
We don’t claim to be able to so well conceive of the system in its ultimate form that we go into system development with a perfect and complete design. We do claim that we can begin the evolutionary adaptation process with a more plastic and malleable medium than a growing mass of code. And then we can support code evolution with, again, a more malleable medium for exploring architectural-level refactoring and adaptations — changing sketches and more formal models to explore the impact of ideas before we incur the cost of making the changes in the code base. All the while maintaining greater intellectual traction over a complex system, because we have cognitive aids to system understanding and work with system constructs in their own terms, rather than always and only in terms of code which contains details that obfuscate.
Some related reading:
