Extracting Characteristics from Requirements and Context using Architecture Katas

Key Insight

Architectural characteristics are derived from both explicit statements within requirements documents and the architect's inherent domain knowledge. While requirements might specify explicit user numbers or scale, architects leverage implicit domain knowledge to anticipate behaviors that influence design. For example, when designing a university class registration system for 1000 students over 10 hours, an architect with knowledge of student procrastination would design for all 1000 students attempting to register in the last 10 minutes, rather than assuming an even distribution. To hone this skill, 'architecture katas' were devised, serving as individual training exercises (akin to martial arts katas) that provide aspiring architects with a domain-targeted problem and additional context. This method allows architects to practice deriving characteristics and trade-offs within a 45-minute timebox, receiving feedback on their designs.

Each architecture kata follows a predefined structure, including a 'Description' of the overall domain problem, 'Users' outlining expected numbers and types, 'Requirements' detailing domain-level needs, and an 'Additional context' section for implicit knowledge impacting design. The 'Silicon Sandwiches' kata serves as an illustrative example: a national sandwich shop aiming for online ordering, expecting thousands, potentially millions, of users. Key requirements include order placement with pickup times, external mapping integration, delivery services, mobile accessibility, national and local daily promotions, and various payment options. The additional context reveals franchised shops, future overseas expansion plans, and a corporate goal of hiring inexpensive labor to maximize profit. Architects systematically analyze each element of this scenario to identify its influence on the system's structural design.

From the Silicon Sandwiches kata, both explicit and implicit architectural characteristics can be derived. The 'millions' of potential users explicitly demand scalability (handling many concurrent users) and elasticity (withstanding bursts of traffic, particularly around mealtimes, even if not explicitly stated). Requirements like external mapping services imply integration and reliability considerations. Mobile accessibility drives performance characteristics for page load times. The need for national and local promotions, alongside customized directions, points to customizability as a key characteristic, potentially suggesting an architecture style like microkernel for plug-in behavior. Implicit characteristics, vital for any system, include availability, reliability, and security. Architects must also engage in continuous trade-off analysis, collaborating with developers and stakeholders, understanding that 'there are no wrong answers in architecture, only expensive ones,' and ultimately striving for the 'least worst collection of trade-offs' rather than a single 'best' design.