Over the last several years, I’ve used Architecture Kata regularly as the basis for both a group workshop exercise and a recruitment tool. I’ve completed lots of these exercises as both participant and facilitator and have developed a good sense of how to use these kata and where the dragons lie.
This is the first of a series of articles about how I use kata to build and/or identify solution design skills with colleagues and candidates at ThoughtWorks.
These articles are written for experienced software engineers who are required to create solution designs as part of their role.
I believe Architecture to be a capability rather than a role or title, so you do not need to be officially called an “Architect” to benefit from this material.
These articles don’t assume any specific domain or technical knowledge, although the later episodes do present a solution design for a distributed web application to be hosted on Amazon Web Services. Having conceptual knowledge of this type of solution and AWS would be beneficial, but not mandatory.
Ted Neward – the creator of Architecture Katas – sums up the problem they address perfectly with this quote:
So how are we supposed to get great architects, if
they only get the chance to architect fewer than
a half-dozen times in their career?
In less succinct words, the opportunity to architect a “live” software system is too infrequent and too risky a process to be the sole mechanism by which architects hone this skill. Architecture Kata were created to provide samples of realistic high level problems to solve, much like other uses of the term “kata” in the software industry.
All forms of kata endeavour to provide a safe way to focus on particular aspects of your craft. For example, with a code kata you might repeatedly solve the same list processing problem via:
- a variety of looping forms (e.g., for, while, until, etc)
- a higher order list comprehension (e.g., map).
There is no commercial or schedule risk to any of these solutions. Kata is used purely as a learning task – a set of rehearsals away from the spotlight and heightened expectations of real life software development.
Similarly, you can use architectural kata with a deliberate focus on specific architectural forms:
- start with a monolithic implementation
- iterate towards a finer grained microservices solution
- switch your integration approach from synchronous and RESTful to asynchronous and event-based.
- change focus to specific non-functional requirements (e.g., security, availability, scale etc)
Each of these decision points will have a material impact on your architecture.
If you’ve got this far reading and haven’t had a look at any of the kata, I’d advise you to go ahead and do so now for context. I’ll wait…
There are many ways to skin an architecture kat-a :-), but I follow the following process when introducing people to them:
|Roles||what are the the primary roles interacting with the solution?|
|Responsibilities||what are the key responsibilities for each of these roles?|
|Capabilities||what are the core business capabilities required of the solution?|
|Business Process||what business processes does the system need to support?|
|Logical Architecture||what are the high level components of the technical solution?|
|Physical/Deployment Architecture||how are those high level components implemented?|
The following articles in this series will decompose each of these steps via a worked example of the I’ll Have The BLT kata.
Did you find this article useful/interesting?