How: Some Comments on Creating and Evolving the Conceptual Architecture
During early system conceptualization, we start to envision the form or shape of the system, its boundaries and interactions, its primary elements and their interactions. The sketchy shapes of these elements, expressed mainly in terms of their responsibilities, analogies, and drawing on patterns and experience, take a rough form, allowing us to investigate the system concept. Then, as the system concept (identity, value propositions and capabilities) takes shape, so too does the Conceptual Architecture.
In designing complex systems, separation of concerns is a key strategy for gaining intellectual traction and enabling ourselves to reason about important design decisions while considering cross-cutting concerns that are part and parcel of the decomposition-composition dual of systems design and development. The concerns focused on at this point are related to giving shape to the system paying attention to user-facing capabilities and developer-facing properties of the system. We seek to bring intentionality and experience to design to achieve more the system properties we want, recognizing that ultimately system properties are emergent and we will need to sense and respond and adapt as we learn more from the system in context.
The architectural elements of software systems (that is, elements significant enough to the system to draw out and deal with in architectural design) are constructs of inventive human thought. We mold and shape them to accomplish a purpose, subject to constraints and forces. We leverage analogies to draw experience and knowledge from other domains, including mechanisms of nature (e.g., swarms), man-made (e.g., mechanical mechanisms like hubs), and social constructs (e.g., social and economic mechanisms like brokers).
The Conceptual Architecture Diagram is a lightweight and yet powerful tool for sketch-prototyping the system structure, and for rendering the structure of an existing system, to explore adaptations to it. Thus it allows us to explore the system from its earliest conception through evolution. As we experiment on paper, it is cheap to postulate various alternatives and explore their ramifications.
As system capabilities are defined, the associated responsibilities are allocated to “chunks” or components of the system, and these responsibilities are an important thinking tool for architectural designers who need to make software abstractions cognitively malleable and communicable. With something so simple as elements each with their list of responsibilities and relationships, we can experiment with different factorings and hence different abstractions or elements each with a different basis for cohesion of responsibilities. Further, it becomes possible to assess:
- clarity of responsibilities
- whether responsibilities are missing
- components for cohesion of responsibilities
- the system shape for balanced distribution of responsibilities
Architectural components may play different roles in the system, so their responsibilities are related within role-scopes. That is to say, for example, a component may play a minor role in system health monitoring and an active role with respect to some other system capability (e.g., providing shopping cart functionality).
In highly dynamic systems, as software intensive systems are, structure and dynamics are designed together — if we focus on structure we impact dynamics, and vice versa. When we focus on dynamics — on behavior and “how it works” and properties that emerge from the structures as they perform their function and interact — our design decisions have to be expressed in terms of the structure for the structure houses, if you like, the implied responsibilities and interfaces.
The conceptualization of a product isn’t limited to the conceptualization of its use, but the product in use. We’re designing what the product is capable of in conjunction with what the product is and how it is built. A car isn’t a faster carriage, and although early cars had aspects of a carriage, the engine was quite different than a horse, and this translated to mechanisms to make the wheels move (from passive to active). In other words, when we conceptualize a new kind of product we iterate across designing capabilities and the mechanisms and structures that deliver those capabilities, and the product changes the ecosystem (a gasoline powered car raises the need for places to replenish fuel) so to make the product successful we also (impact the) redesign (of) key aspects of the ecosystem or larger system of systems into which our system fits, interacts and in important ways shapes and is shaped by.
“In most people’s vocabularies, design means veneer. It’s interior decorating. It’s the fabric of the curtains and the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product or service. … The essence of the iMac is to be the finest possible consumer computer in which each element plays together” — Steve Jobs
Conceptual Architecture grants us passage between the from-the-outside and the from-the-inside views of the system, allowing us to design interactively across the concept of the system and the internal concepts that allow that conception to take form. And it allows us to think about the elements and how they play together. More specifically, it is the conception and narration of the organization of the parts or elements of the system and its key, or architecturally significant, mechanisms — as the system is conceived, developed and evolved. More pivotally, it is an agent of consilience, helping us to bridge various divides in system design.
Some related resources and ideas: