Architecture Katas for dummies
The sad reality
Meet John. John is a good lad, he has spent most of his five-year-long career so far as a good developer and excellent lead developer. A few weeks back, Linda (his boss) offered him an architect position. John saw that as a promotion, and took the opportunity. Fast-forward a few months: A big service has to be built, and it falls upon John to design the whole solution, him being the architect and all…
Question: Will John succeed ?
Answer: Probably not.
Most software architects start alone in their practice. They do have strong suits; those usually warrant their “promotion” into that position. But architecture is a vast land, filled with strange objects, not unlike the subatomic world at times…
In spite of what many vendors might have us believe, there is complexity everywhere: Network is way more complicated than a simple line on a drawing, so is a file system, a database, an OS and the list goes on and on and on (security, DNS, virtualization, containers, etc…).
Like John, architects usually come from a specific background: developers, network engineer, database, or system administrators. As such, they are also biased towards what they know well, and overly demanding about what they do not.
Proof:
- Architect-who-was-a-developer expects full availability from network, and precise and synchronized clocks everywhere, and for instance blindly assumes that a ‘second’ lasts exactly one second (silly him… it does not).
- Architect-who-was-a-sysadmin expects every application to be fully forward/backward compatible, easy to deploy and to launch, well documented and patched for bugs and security, like any good’ol SystemV command (ask your developers for their application’s “installation guide”).
(A/N: this is slightly exaggerated for the sake of my demonstration, don’t take any of this too personally please :) )
Of course, if you are an expert of everything then please do work 6 days, have a nap on the seventh and look at the rest of us struggling with life. If not, then you need architect friends, a community on which to rely to supplement your own skills, to broaden your views and make a better architect out of you. This kind of network is something you build with time and katas, more on that later.
So OK, an architect needs a network of architects to have a complete view of what is expected from him or her. But an architect also needs practice.
Think of it: How many big architectures have you done lately? By that I mean a real, big, buff architecture that takes you more than a few days to design.
The odds are that you have done less than 10 of those, probably less that 5 even. You cannot be like “OK, I failed our 10.000.000€ architecture this time, but I will do better next time”. Or maybe you can do that once but certainly not twice. So when a 10M€ architecture drops in, you pretty darn sure had better be all warmed up and ready for it. Martial artists do exactly that by practicing a series of fixed moves to the point that it becomes a natural reflex. In Japanese martial arts, those are named katas and they are quite effective.
Proof (I dare you):
- Find a seasoned karateka and, without warning, slap him or her in the face. (Free hints: You probably won’t succeed. If you have glasses, take those off before.)
- Find a judoka and try to tip him/her off. Same hints, plus do that over a thick carpet ‘cause you will probably be in for a full swing.
So practicing these fixed moves mechanically and outside of combat helps in acquiring live-saving gestures. The same goes for architects. They too need to practice their “basic moves” and to hone their “architectural common-sense”. They can then focus on what makes the problem at hand hard. Making this in groups is good for collaboration, networking and empathy.
Rules, Principles
The architecture katas process is really easy to understand and implement. It’s a bit like coding dojos.
As explained, the main purpose is to train you and your teammates designing systems that are beyond your everyday matters. Furthermore, these workshops help to train delivering a system’s design which can be understood by other stakeholders as quickly as possible without compromising on quality.
The rules are:
- People are divided into pizza teams (aka no more than 8 persons).
Each team receives a kata. You can give different subjects for each of them. However, it’s better to give the same subject. This way, people could discover other approaches for a same topic.
- During one hour, all the teams work on the kata.
- They could ask for all the information they need. Then, the organizer shares the information after with other teams.
At the end, every team presents their work during five minutes and answers any questions asked by other stakeholders.
Benefits
There are several benefits to this type of exercise. We get to practise our architectural skills on a regular basis. As in martial arts, where you have to train with katas several times before fighting, architecture katas can help designers to gather knowledge and skills before designing a “real world” application. It can help your teammates to work in partnership, to design applications focusing on communication as a team and to be challenged by other people on their ideas and skills!
An example
Identify poor roads
Use connected cars abilities to identify roads which have to be improved
User needs
A local government organization lacks the ability to identify roads which need improvement. They don’t have the time and money to inspect the roads.
To improve their Return on Investment (ROI), they wish to have dynamic reports on their utilization.
- Data will be gathered from car sensors.
- Data processing must be anonymized and GDPR compliant.
Number of call / Data usage
- One transaction per second per car.
Some feedback from our first session
Thierry Beucher:
It is an excellent teamwork practice from which we can gather several takeaways. The one I would like to highlight is the pressing necessity to lay a common formalism for all participants in order to produce a clear architecture, rid of any ambiguity.
Olivier Paoli:
I appreciated in my group the knowledge of Simon Brown’s C4 model, which allowed us to get started quickly with this common approach. It was interesting to see at the end of the sharing how the approaches are impacted by each other’s profiles and backgrounds: more or less detailed models, technical or business, static or dynamic, components or data, and so on… It seems to me profitable to review the models again at the end and to position them, so that little by little a common vocabulary is shared; and so that the interest of each model, and its positioning in a method, is also shared. Thank you very much for this initiative, we are having fun.
Go further
You could check these two websites to gather more information and katas subjects:
