Design is a critical part of the process of architecture, and yet in much architecture the design process is not reflected in the final delivered architecture. Many architectures are simply a collection of artefacts (mostly models of some form), which describe the end result of the design process.
So why is this a problem? – While models are useful artefacts they only capture what was designed, and not why a specific design was created. Models do not capture the process of design. The value of design is in the reasoning, the traceability back to the business requirements, and the decisions which led to the creation of a particular architecture.
Good design is justifications, reasons, and trade off considerations – Design is often confused with models or diagrams, in reality the diagrams are the output of the design process. Since a number of solutions could satisfy a business need, the reasoning behind picking one design over another is where the real value of architecture lies.
This highlights a key distinction between the process of architecture and architecture deliverables. Architecture is more than a checklist of deliverables which must be created, it must also include the “design narrative” which captures why decisions were made and how the deliverables relate to and inform each other. Models are critical for simplifying both software and the software process; Simple design focuses on delivering a system that balances delivering on the immediate needs while considering future needs.
Design Methods and Processes also have an impact on the architecture process in terms of the expected deliverables used to seed the detailed design process. Different methods will have different implications for the architecture process. In Agile Development, for example, the architecture may begin at a high level, then allow agile design/development to proceed in order to validate a particular element of the architecture prior to formally documenting the design.
Scale of a project also impacts design. In small-scale projects, there may be very little architecture and mostly design, however as project complexity increases the importance of up-front architecture grows. In large-scale enterprise projects the development of an overall architecture is an essential precursor to the initiation of design since it provides the context into which the design activities will deliver.
Models are not Design – Models without design provide an illusion of understanding – Architects & support organizations need to understand why certain design decisions were made during the architecture process so that future enhancements to the solution can be made with awareness of all the relevant information. Without recording the design decisions future architects and support organization are doomed to infer or make assumptions about why a solution was designed in a particular way. This impacts both the ability to maintain and enhance the solution, and also the ability for others to reuse elements of the architecture. Documenting design rational allows architects to evaluate whether an existing architecture component is suitable for inclusion in a different architecture.
You can reverse engineer an architecture from an existing solution, but not the design intent – Most architecture deliverables can be reverse engineered from a solution, however it is not typically possible to determine the reasons that design decisions were made, or the context in which those decisions were made (alternatives considered, constraints, alignment with principles etc.).