geekyprimitives

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.