Having run my software architecture kata for thousands of people across the globe, I can now pretty much predict what's going to happen. During the initial iteration, groups of people are asked to design a software solution given a set of requirements, with the output of this exercise being one or more diagrams to illustrate their solution. Literally moments before the exercise starts, we talk about "significant decisions" and "architectural drivers". Everybody agrees that technology decisions are important for a number of reasons; including cost, team skillset, organisational standards, etc.
On reviewing the diagrams though, upwards of 90% of them will not have any technology mentioned whatsoever.
Image may be NSFW.
Clik here to view.
When I ask why the diagrams don't include information about technology, the responses are typically along the lines of:
- "the solution is simple and can be built with any technology"
- "we don't want to force a solution on developers"
- "we want the team to decide"
- "it's an implementation detail"
- "we follow the 'last responsible moment' principle"
- "everybody knows that we use Java"
There are a couple of separate discussions to have here about not properly engaging in the problem space, and that technology does actually have an influence upon the resulting design. Fundamentally though, not considering some of the implementation details (even at a high level) leads to a very superficial view of the solution. This is evidenced in iteration 2 of the architecture kata, where I encourage groups to illustrate their solutions using the C4 model. Although one of the goals is to create better diagrams, the groups are "forced" to have much richer design discussions in order to create the detail needed for these diagrams. Many groups will actually modify their designs because they realise they won't work. This feedback is a good thing, because no code has been written at this point.
Back to the point of this post. Imagine that, as a developer, you receive or are presented the type of designs that emerge from iteration 1 of the architecture kata. It's all very high level, very fluffy, very conceptual and very light on technical details. Most of the software developers I work with during my training are understandably wary about "ivory tower" or "solution" architects, who are removed from the day to day job of building software and talk about ideal or conceptual solutions. Yet these same developers are doing exactly the same thing by not considering technology when designing software. Unless we change this situation, today's software developers are going to be the ivory tower architects of tomorrow.
