Dojo, kata and software architecture

I am back home after architectural kata, where I played role of a “customer”, for the first time.I am tired, but smiling. Team was unbelievable, problem we were trying to solve quirky enough, discussions during presentations of architectures were great, tons of good “critical thinking”. Everyone was treated equally and had to survive under constant fire of questions from the audience.

On my way home I realized that I have learned something really important, even more important then discussed designs and technology stacks.

These things are so important that I have to share it with you, my dear reader. It is nothing that would change your life, rather things we tend to forget about.

Architecture is a collaborative effort.

We had three teams, 3 to 4 members in each. Every member of the team had its own view on what “customer” said, even when I thought there was no place for misunderstanding. This collaborative view on problem ended up with more open, flexible design. When team members were not able to agree on what was expected from the system they were creating subsystems and boundaries, to postpone final decision until “customer” provided more details.I have also found that if you create your architecture in a collaborative way, seniority of people involved matters less. Why? We had really unbalanced teams, with different experience and seniority levels, and at the end of the day they created pretty similar designs, they cut the problem domain in same places.I think it is because common sense and “gut feeling” is a thing that matters more in software architecture then we want to admit. So, if seniority and experience doesn’t matter so much, why all architects are people with long gray hair and beards? Why does it take so much time to become one of them, Gandalfs or Sarumans of software development lands? Thanks to architectural kata I think I know the answer.

Architecture needs to be validated (through constant communication).

If designs were pretty similar, at least at the components and collaborations level, does it really matter who creates architecture in your project?
Yes, it does matter. I was amazed how different our communication styles are, and when it came to share with others effort of 45 minutes design session in my personal opinion there was only one team during kata which outperformed. Shined like a crazy diamond (if you know what I mean).
I was just standing with my eyes wide opened, staring at the whiteboard, and I was hearing voice in my head “you dumpass, you too often forget how important is to communicate architecture”. This is what makes software developers great architects.
Ability to communicate architecture.
Second thing that is connected with that, a need for more communication, is something that eats my CPU cycles for years. There are hundreds of ways to validate software, some are good, other are even better and even more expensive :), some work, some doesn’t. But how to validate architecture? Find design flaws, possible bottlenecks and “hidden traps” in technology stacks? Again, through communication, but make sure that your audience was not involved in a design process, because they will protect their “kid”, new shiny beautiful design.
Once we started to share results of our work during kata, I suddenly started to hear many “oops we didn’t think about it, oops does it really work this way?, oops we made wrong assumptions about technology”. Count every “ooops” as a failing test, failing unit test 🙂 and you got ODA, Oooops Driven Architecture 🙂

So next thing to remember, if you have an architect who doesn’t collaborate and communicate his work, find him another place, it will just simply not work, period.
And make sure your architect doesn’t fall too often in love in particular technology, he should not be constrained by technology,and when you are in love you are biased. On the other side, he just needs to know this stuff, that’s it, there is no place for feelings 🙂

And don’t worry, we are all in love, everyone has their technology stack of choice, but you need to be critical about it, honest to yourself.

Problem domain can and will impact architecture, the trick is that you never know when and how.

Yeah, this one is a nasty thing. It looks to me that some designs where immune to particular changes of requirements,
while other simply just exploded. As a “customer”, I have hidden few domain details, simply skipped it :). During presentations,I got my memory back, and communicated that I forgot about few details, here and there. Some teams reacted to the change saying,
“yeah, we have plugins so what you said can be implemented as a one more plugin”, others just had to rethink big chunks of the system.
What can we do about it? Nothing? Communicate with customer? I was available all the time, something that doesn’t happen in a real world, and still I was able to surprise teams.
These things just happen, my only advice is simple. When change comes, throw what you have and start from scratch. It is cheap as long it is still a design phase. You just simply don’t know how many places in the system this change will affect, don’t take this risk. I recommend you to build new design and validate it once again. In an ideal world….

You can also build open, flexible architecture from the beginning, of course when you can afford it. During kata I have also learned that there are few things you need to do to open yourself for endless possibilities of design space in front of your eyes. ( whooohoo I used “design space” for the first time in my post, and it looks so cool 🙂 )

Do you want to know what you need to do?

  • remove technology from the discussion in early stages of shaping the architecture, stay away from it as long as you can
  • understand constraints in the existing system (you don’t create beautiful architectures in the middle of the desert, you will have to fit, become part of another existing system), understand constraints which are out of your control and make them vital part of your design and communication
  • What is important for me, doesn’t matter for you, as long as we don’t share same context, context is definitely the king

That’s all folks. My personal take away from this architectural kata. Believe me, once you try it you will want more and more, it so rewarding.
If anyone is interested to try it at one of upcoming conferences in Poland, let me know, I will be more than happy to help.

Tagged , , ,

8 thoughts on “Dojo, kata and software architecture

  1. Great you’ve decribed that experience!
    I must admit that I’m very curious what architectures were most resilent to new requirements?
    In particular – how much in common did they have with Ports&Adapters/Hexagonal architecture?

    • jpalka says:

      I didn’t find any signs of ports&adapters and hexagonal architectures 🙂 in 45 minutes you are not able to get so far, it was rather split between core and supportive domain of the application, putting boundaries between core and rest of the system in a right place. Good old CRC, mapping the right way components, responsibilities and collaborations.

      • przemekpokrywka says:

        I don’t get it: not able to go that far? You’ve used CRC, you’ve talked about plugins – it must have been already clear whether the architecture was Hexagonal-ish or not. Surely we don’t talk about the same thing. I meant *the* Hexagonal Architecture as described by A. Cockburn. Sorry, assumed that you know it – Sawek Sobtka has a stunning presentation about it. On the other hand nice to know you also value CRC.

      • jpalka says:

        That’s the beauty of the language and not sharing the same context 🙂
        When I was saying about “plugins” I was referring to problem domain which was subject of the kata. It was part of problem domain. Teams were designing online implementation of popular board game, which has lots of “expansion packs”, which change rules of the game, add tiles to “base set”. Teams which decided to implement part of the system using “plugins” where more immune to changes.
        I am aware of Hexagonal-ish architecture 🙂 but teams didn’t even get to this discussion. 45 minutes, you don’t have time too look for analogies, you follow your gut feelings 🙂

      • przemekpokrywka says:

        Now I got it… Indeed, language without a common context has played tricks 🙂 A very interesting kata. Again, thanks for sharing!

  2. Pawel says:

    Interesting observation about the role of experience in making decisions about the architecture – I’m not quite sure I would agree though… I’m not sure whether your conclusions about the insignificance of the seniority are a little premature. I would be very much interested in looking at it in a wider context, eg. What about the differences between people with 1 year and 20 years of experience? What about the slight differences in their decisions, maybe the little difference is what matters? Up until it’s researched in a wider context it’s going to remain just the anecdotal evidence to me 😉

    • jpalka says:

      Pawel, there was no any scientific method applied 🙂 and I know I should :). This is just single observation from this particular kata. People who joined this kata were just too smart, we were all from one company, from the same cultural context, working together in the same technology stack, which also is something which probably impacted designs created by teams. I will try to broaden my research. I hope you will join me at upcoming conferences so we can run this experiment once again… looks like a interesting topic to explore in 2013 🙂

      • Pawel says:

        Great idea, I’m absolutely up for participating in the architecture kata if there’s a chance 🙂 Thanks for the clarification on the context – “context is definitely the King” 😀

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: