Architectural decisions are the decisions that are hard to change later on (contrary to design decisions). One goal of an architect is to minimize them, i.e. design the system so that they are not so important after all. We also try to make it possible to postpone making them as long as reasonable so that we have more knowledge when we eventually make them.
It’s crucial to understand the needs of the domain - f.ex. the complex, often changing rules of a pension system x transactional processing with focus on security and batch processing in a bank x high volume and importance of speed at a stock exchange.
The goal of architecture is to satisfy requirements (enable delivering desired qualities, respect constraints, costs) -
Architecture that never refers to necessary qualities, performance characteristics, costs, and constraints is not really architecture of any kind.
- Has multidimensional clear design performance objectives [performance = all regarding how it functions, not just speed etc.]
- Has clear multiple constraints
- Produces architecture ideas which enable and permit objectives to be met reasonably within constraints [and we can try which works best or combine multiple]
- Estimates expected effects
- The Architecture of Open Source Applications and The Architecture of Open Source Applications, Volume II: Structure, Scale, and a Few More Fearless Hacks - ” the authors of twenty-five open source applications explain how their software is structured, and why”
- Architecture War Stories by Stefan Tilkov on Oct 04, 2014 (talk, 45 min)