The topic of software architecture is very controversial in the agile community. Opinions vary from “architecture emerges by itself” to “spend Sprint-Zero on architecture and required infrastructure”. Both these extremes are far from being lean, because lean in essence is about reducing waste and maximizing long-term value. Sprint-Zero architecture is BDUF – big design upfront – and is wasteful because its value won’t get fully realized until the very last part of implementation is done. Emergent architecture (being dictated by the underlying implementation) is wasteful because it constantly causes rework and refactoring at the architectural level is never easy. It also wastes informational context: strategic macro-level decisions (and thus their justifications) are buried in the implementation details where they are indistinguishable from tactical micro-level decisions.

But what is in between those extremes? Can architecture help prevent waste without being wasteful itself? What is lean architecture? I tried to find it out experimentally.

Architectural Kata

First time I’ve learnt about Ted Neward’s architectural katas from Benjamin Reitzammer at SoCraTes Conference. Since then I’ve facilitated several architectural katas myself at different community events. My style of facilitating can be described as exploratory: I neither prescribe any particular method to solve the kata nor do I require any particular presentation format – words or pictures or a mixture. The only constraints are:

• 30 minutes for preparation, 5 minutes for presentation;
• work in a group of people you don’t know well (otherwise I’d give 20 minutes for preparation);
• communicate and justify macro-level decisions (does it count for the definition of the architecture in lean context?);
• state assumptions explicitly.

I also give some hints:

• to focus on getting quick feedback on technical feasibility and costs;
• don’t spend too much time on modeling the problem domain as it can be done later on the micro-level;
• I also say something like “I want to see data flowing” (more on that later).

Lessons Learned

Most participants get frustrated after their first kata because of how little they’ve actually scratched on the solution domain surface. Many of them complained about the time box being too short. I always replied that if you have no plan, then the quicker you realize it the better, but if you have one and it requires more time, try to make it leaner next time. I used frustration on purpose as motivating factor and to raise the awareness that architecture requires deliberate practice too.

After each kata I also saw good patterns in solutions people propose:

• split the system based on domain functionality;
• identify data flows between sub-systems;
• identify different actors and sub-systems they communicate with.

Many participants demanded to see my solution, which I shamelessly stitched together from the patterns mentioned above. That approach was every time well received. I was hesitant though because it was just one way and I was more interested in letting people explore new ideas.

Each time a long and very constructive discussion about architecture in general and architecture in agile followed the kata. And I always notices that participants learned about architecture a lot and so did I. Common feedback was also to have a chance to immediately apply acquired knowledge to a new kata.

Rinse and Repeat – Architecture Retreat

Since the time frame of a conference session or an evening meet-up couldn’t squeeze several katas I decided to try out a new format – Architecture Retreat (inspired by the Code Retreat). And just yesterday at Spartakiade 2013 in Berlin I’ve got a chance to facilitate the first mini Architecture Retreat. Due to time limitations (again) it consisted of just two katas. We had 3 groups and shuffled them between the katas. There were two different katas: the first one was a simplification of Where’s Fluffy (without rewards) and the second one was a custom kata – a community platform with local sub-groups, mailing lists and events (German software craftsmanship community is building one now).

Surprisingly enough the first kata went better: groups identified actors, sub-systems and interactions. The second one didn’t go beyond requirements engineering and problem domain modeling. The feedback was that the second problem was broader and less known (too few Spartakiade participants were members of the German software craftsmanship community unfortunately). It was also proposed to try the same kata over and over again (although with additional requirements each time) to avoid the initial problem domain learning curve. I’m still convinced that soliciting requirements from the customer on-site is essential part of an architectural kata though. Anyway it might be a Legacy Architecture Retreat (why not?): in a short time-box describe and refactor an existing architecture in order to embrace a new requirement. Sounds good to me.

What’s Next?

How to learn just enough problem domain and incorporate requirements into the architecture one by one in a lean way will be the topic of my next blog post. Yesterday I tried one approach to the second kata myself which went quite well, though I need some more time to generalize and document the method. In a nutshell I’ve applied TDD on the architectural macro-level using use-cases as tests.

The next Architecture Retreat will be held at the Düsseldorf software craftsmanship community on 11th May. Stay tuned.