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:

  • simplify the design with cohesive units of responsibility
  • partition realms of uncertainty and experiment, separating them from more stable and understood areas of the system;
  • separate areas of the system that change for the same reason (for example, dependencies on underlying technology), from other areas of the system that have different change impulses;
  • create areas of focus for investments in highly tuned performance or extreme robustness and resilience;
  • separate elements for reuse or leverage; and
  • create units of accountability. (Whether we organize development primarily by features or by components, it is helpful to have clear component ownership so that the structural health of the component is an explicit charter.)
  • 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:

  • Decisions, Concerns …(re-)Defining Software Architecture
  • Why Do We Need Software Architecture?
  • What architecture is about
  • Leave a Comment

    You must be logged in to post a comment.