Architectus Oryzus

Martin Fowler wrote an article on software architecture almost 15 years ago. I just discovered it now while in the midst of changing jobs, and I found this part where he contrasts architect styles to be very relevant for me in this moment:

Architectus Reloadus is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity,  and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow.

Architectus Oryzus is a different kind of animal. This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in non-technical terms — such as development costs.

In many ways, the most important activity of Architectus Oryzus is to mentor the development team, to raise their level so that they can take on more complex issues. Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck. This leads to the satisfying rule of thumb that an architect’s value is inversely proportional to the number of decisions he or she makes.

-Martin Fowler in Who Needs An Architect?

I think that summarizes very well the role I played for my previous company. Without the benefit of the article’s description, I intuitively approached architecture in this way. It’s always been clear to me that collaboration is the key to a better product. That means always looking for feedback on designs (earlier the better), and being open to better ideas (often bubbling from the bottom up, sometimes from unexpected places). Raising the level of the development team is crucial, to both increase the pool of critical thinkers available for each problem (huge win), while also reducing the incidence of “misguided” code submissions (which can become dangerous precedents for future development if left unchecked). There is so much opportunity to learn in both directions.

Ultimately, looking back on my experience now, if I can be critical in one area, it’s that I probably got a bit too involved with the teams at times, leading to over-reliance. I’m thinking in particular of the moments when I was overseeing three scrum teams. Teams came to rely on me to do reviews, especially code reviews. Even after raising their level and mentoring them to the point that they were capable of self-organizing and taking on that role themselves, I did not notice anyone rise up to truly champion the cause*. Partly I think, that’s because I was performing that role so consistently. Too consistently perhaps. Hence there may be a lesson here about stepping back when the time is right.

*(At least, the team structures never lasted long enough to see if any champions would finally emerge. I do hope they have gone on to be leaders on their future teams).

In the end, it was a very rewarding experience with my previous company, and I’m looking forward to the new challenges ahead.