This part of the book is about the overall process of designing software, specifically looking at the things that you should really think about before coding.
Architectural drivers Regardless of the process that you follow (traditional and plan-driven vs lightweight and adaptive), there’s a set of common things that really drive, influence and shape the resulting software architecture.
- Functional requirements In order to design software, you need to know something about the goals that it needs to satisfy. If this sounds obvious, it’s because it is. Having said that, I have seen teams designing software (and even building it) without a high-level understanding of the features that the software should provide to the end-users. Some might call this being agile, but I call it foolish. Even a rough, short list of features or user stories (e.g. a Scrum product backlog¹) is essential. Requirements drive architecture.
- Quality Attributes Quality attributes are represented by the non-functional requirements and reflect levels of service such as performance, scalability, availability, security, etc. These are mostly technical in nature and can have a huge influence over the resulting architecture, particularly if you’re building “high performance” systems or you have desires to operate at “Google scale”. The technical solutions to implementing non-functional requirements are usually cross-cutting and therefore need to be baked into the foundations of the system you’re building. Retrofitting high performance, scalability, security, availability, etc into an existing codebase is usually incredibly difficult and time-consuming.
Software architecture is about the significant design decisions, where significance is measured by cost of change. A high-level understanding of the requirements, constraints and principles is a starting point for those significant decisions that will ultimately shape the resulting software architecture. Understanding them early will help to avoid costly rework in the future.