Are you Ready to Become a Software Architect?

For a long time, I would watch software architects and weigh the possibility of becoming one. However, every time I imagined myself in that position I could not help but wonder what my daily routine would be like. I used to think that role would change my responsibilities and cause greater exposure, both internally and externally.

Pondering about these matters, I would feel an adrenaline rush through my body. So, I started to consider which were the skills I had to improve or acquire in order to become the person who would determine the project development.

This happened several times and I even wondered if I were scared. I did not know that yet, but I did know I had to live that experience.

I had to change the way I thought about systems. I learnt that there is an integral approach to thinking systems: everything has to coexist and interconnect.

Being a Good Architect

There are no magic words to turn you into a good architect when the moment comes and the challenge arises.

It takes experience. It takes having seen and analyzed different systems, faced several problems, designed solutions to those problems and witnessed the outcome of those scenarios in order to learn from that experience. That is how you know what could have been done differently, what worked and what did not.

Here is where the dilemma appears (and this happens in most professions): how can I get experience when I cannot perform the role?

Sometimes we feel trapped in a hamster wheel. You need a job to get experience but companies won’t hire you because you don’t have enough experience.

Alternatively, architecting is not only about designing a solution but also knowing (and practicing) how to communicate our solution for any audience (whether technical or not) to be able to understand and feel comfortable with it.

Building Confidence

In order to build confidence in others (even with no experience as an architect) we need practice. Confidence comes with practice. We need to practice in a safe environment where we can learn from our experience and the experience of others.

For example, at Spark Digital we have a space known as “Architectural Katas” where we offer a space for people to practice.

“Kata” is a Japanese term associated with martial arts. It refers to very specific patterns that are practiced and repeated until a certain technique is mastered.

In software development, during a Kata, a hypothetical issue is presented and teams are gathered to design and communicate their solutions to that particular issue.

Conducting an Architectural Kata

An Architectural Kata may be organized in many different ways. You can allocate more or less time to the building and presentation of the solution, but the final goal in all cases should be the same: gaining experience by working on the solution of hypothetical problems.

Given a certain problem, the team establishes both functional and non-functional requirements (the latter being very important since they will determine the architecture and since here, the team makes all the assumptions). After that, each team works on the solution to the problem using each and every tool they consider necessary.

The final step is the most important one: communicating the solution. Once the time is up (the time given may vary between 30 minutes and 2 weeks), each team has to explain their solution to the other teams.

Ignacio is a member of Spark who participated in these Katas.

During my first Kata I felt the need to ‘play’. I had to break the Kata and assemble it back, over and over again, much like a kid with a toy.

Here is what I learnt from that experience:

1. Be clear about what you want to communicate and do it as directly as possible. I used ordinary language to keep the audience engaged and to make my ideas fully clear.
2. Identify which skills are valuable in order to become a technical leader. Finding out the skills I needed made them simpler to acquire and made me confident to present my solutions. For instance, I discovered that having a global vision of the problem helps visualizing improvements and risks.
3. Embrace mentoring. I learnt the most during mentoring. I got all my knowledge and experience from it. I was encouraged to develop without fear of making mistakes. It was part of the process of learning how to think like an architect.
4. Know and assess yourself. I used the Kata to size myself, to think about when I would see myself as an architect, to acknowledge I had developed skills and built enough confidence to deal with problems. I felt it was a good decision to give myself some time for these skills to appear naturally.

To sum up

Getting ready to become an Architect is a process that should not be forced; it should come with meditation and self-knowledge. Practice is the way to build confidence, and there is no better place to practice than architectural Katas. These Katas should be framed within a structure, should be supplemented by mentoring and should offer space to err, try again, and reach an outcome; they should enable the easy and clear presentation and communication of the architectural solution.

Leonardo Alifraco & Ignacio Magenta — Software Architect & Prospective Software Architect @ Spark Digital