Software Architecture KATA

29 May

Software architecture KATA

JArchitects’s held another awesome Tech Day on June, this edition focusing on Software System Architecture. Our guest speaker this time was Bart Blommaerts from BB Consulting.

The workshop started with a theoretical description of the theme followed by a few hands-on sessions (Architecture Kata).

After the theoretical introduction the attendees were challenged to put theory into practice. We were divided in small groups to discuss the design a solution for a given problem. Between every Kata session the teams had to explain the rationale behind their solution, so we could learn from each other’s ideas. In the spirit of JArchitects’ Tech days, another great knowledge sharing encounter.

What is a Kata?

The short answer is “practice opportunity”.

Kata is a Japanese word most commonly known on martial arts realm. The term translates to the English word ‘form’ and refers to choreographed patterns of movements practiced either solo or in pairs.

According to Bart Blommaerts “You might know the saying practice makes perfect, and Architectural Katas are exactly that: practicing. These Katas were born out of a simple desire — Software architects need a chance to practice being software architects.”

Ted Neward also made quite important observation: “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 summary, this workshop was in fact a 6 hours practice where the JArchitects’ team had the opportunity share experiences and learn from each other while creating the software architecture of a given problem in a very positive atmosphere with a super dynamic approach.

Why System Architecture?

For every computational system, there are various stakeholder, customers, users, developers, to mention just a few. These stakeholders need to have a clear view on what needs to be built.

Reminder: every system has an architecture, even those where the architecture was not formalized. It could be good or bad architecture, but the fact is that the architecture exists anyway.

Therefore, we need a way to document decisions, models, designs and at the same time use some kind of notation/language to represent these elements in a way that all stakeholders can easily understand.

Thus, isn’t it better to ‘formally define’ the system architecture? How about an Architectural Description using views and perspectives?

If you are interested in going deeper, I strongly suggest to dive into the book “Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives”, by Nick Rozanski and Eóin Woods. And maybe even have it always close to, just in case.

Grady Booch once said “one cannot see the ocean’s currents by studying drops of water”. We can apply this quote into our context by saying you should always make some kind of architecture visualization. It’s a fine line between over and under documenting your software solution, however. Therefore, be aware of the fact and don’t over-document your system. Also remember the change is the only constant in software industry. Got the irony?

Goals of visualizing your architecture:

Consistency — Every stakeholder should have a clear understanding of all elements involved
Reporting — Architecture needs to be in the heads of the stakeholders
Checking and validating — Share the architecture with your different stakeholders
Share information — Other people might have experience with certain challenges

When creating visualization models, for any problem you have at hand, it is paramount you define properly the notation for the components you intend to include in the diagrams. This notation could be UML, some variation of UML, or even simple boxes, circles, lines and arrows, as long as they are consistent and clear in every diagram you create. You can start with more pragmatic approach with boxes and lines, and in case of necessity for your project, you can then change to a more formal notation.

“Don’t make things more complex than they need to be, boxes and lines are fine. Just make sure to be consistent and always provide a legend” Bart Blommaerts

One other detail to keep in mind: only document what’s useful.

The JArchitects’ Kata

The goal of this Kata workshop was to guide attendees in creating software architectures that meet the challenges of today’s complex and ever-evolving systems.

In this Kata we had a change to define/discuss the Architecture of ‘AM.I.SCK ‘, a medical assistant application which should support chat nurses answering questions from customers about potential health problems.

Some AM.I.SCK context:

Nurses that answer questions from patients via a chat platform
250+ nurses worldwide, hundreds to thousands of customers
Access to medical histories
Assist nurses in providing medical diagnosis
Reach local medical staff, even ahead of time
Enable parts of the system for direct patient usage
Conversations are not considered medical records

Requirements

Access patient medical histories
Provide an service-level agreement on turnaround time for interaction
Assist nurses in providing medical diagnosis
Support nurses geographically divergent from clients
Enable client customers to reach local medical staff (if necessary), contacting the local medical staff directly ahead of time (if necessary)
Eventually enable parts of the system for direct client customer use

During the hands-on moments the attendees had to define the 7 viewpoints (diagrams) that represent the System Architecture for “AM.I.SCK”. The viewpoints were:

Context view
Functional view
Information view
Concurrency view
Development view
Deployment view
Operational view

It was indeed a quite interesting workshop. Hands-on approach is always engaging!

Key takeaways

Every system has an architecture, even those where the architecture was not formalized.
Only document what’s useful
Be explicit with definitions, notation, specifications and steps
Respect your definitions
Do not reinvent the wheel. There are companies out there that live only to solve some cross-cutting concern problems. If you have the opportunity, use their solution (service) and avoid at all costs to build your own.