#19: The Software Architect Role | Systems and Architectural Thinking - 1

In this episode of The Software World, I tried something new and spoke without a guest.

I mentioned The Role of a Software Architect in the previous issue of my newsletter. The podcast idea came out from that issue to have a couple of sessions about what I learned about systems and architectural thinking over the last months.

Here are the links I mention in the episode:

• On Thinking Architecturally by Peter Cripps

• The Evolutionary Architect from Building Microservices book by Sam Newman

• Fundamentals of Software Architecture by Mark Richards and Neal Ford

• Rumsfeld Matrix

I also started using mind maps to organize my thoughts, and here is the one for the role of a software architect.

SHOW NOTES

Being a great software engineer doesn't make you a good architect. Although you might be good at designing architecture in your software projects, the software architect is a different role with various responsibilities and expectations. If you are thinking of becoming an architect, you should know what you are getting at.

As a software engineer, the projects you focus on are only part of the business domain. You focus on developing and architecting a specific project or a couple of services. As a result, you gain new knowledge around a limited area. As a software architect, your role and expectations are broader.

I will borrow the analogy from Erik Doenenburg to better explain the difference. Software architects are more like city planners than architects. City planners design cities by looking at the available information, citizens' needs for today, and expectations from tomorrow. If you've played Cities: Skylines or SimCity before, you will understand immediately. In these games, the goal is to plan the best cities. You create zones and define them as industrial, commercial, and housing areas while building infrastructure and services around them. But you never specify a building. A city planner only establishes the limitations and doesn't define the inner details of facilities. A software architect does the same for services and apps; defines boundaries for individual services, plans how different services will sit, and work together in the big picture.

Mark Richards and Neil Ford use the knowledge pyramid to explain the difference between an architect's knowledge and a software engineer's.

The Knowledge Pyramid

On the top layer, we have the stuff we know: our knowledge and expertise. In the mid-layer, we have the things we know that we don't know: the things we know exist, we've heard them or used them, but we don't have any expertise. The last but the most significant portion of our knowledge is the stuff we even don't know exists; we simply are not aware of them.

Developers spend their life whetting their expert skills by growing their knowledge on the subject, a.k.a. the top layer in the pyramid--technical depth. The bigger the top layer, the more expert the developer is. For architects, the second layer is more important than the top. Here the technical breadth comes in; how much the middle layer expands into the bottom layer defines the breadth. Both top and mid-layers are essential for an architect, but they sacrifice some parts of their expertise to expand their portfolio. They learn new things but don't get any deep knowledge of them. Because in the architect role, it's more beneficial to have a broader understanding of various technologies than to have expertise in one or two.

The transition in knowledge acquirement is where most developers struggle while becoming architects because they don't want to leave their expertise behind. The case is that the stuff you know is also the stuff you maintain, and architects have no time to broaden their knowledge and keep their expertise. They can still have expertise in one or two languages or frameworks, but these technologies mostly stay at the hobby level. Architects need to acquire knowledge about system design, architectural characteristics, and architectural styles, but not how to implement user authentication in NodeJS. They might still learn it; it's okay to have deep knowledge of one or two topics. But it's not required.

The technical breadth vs. technical depth is only one small part of the architectural thinking and software architect's job. Sam Newman frames an architect's job in three categories:

1. Strategic goals

2. Principles

3. Practices

The company defines the strategic goal, and the architect focuses on designing systems aligned with it. Strategy drives the architect's work. Principles are the rules that the architect prescribes to align with what everyone will be doing. Practices are detailed and practical guides to ensure everyone is following the principles. As you see, an architect's job is not only technical but also includes leading and guiding. Designing systems architecture requires both technical capabilities and interpersonal skills. Defining principles and guiding software engineers with practices involve navigating politics and communication.

If you want to become a software architect:

• Grow your technical knowledge and develop your interpersonal skills together.

• Learn how to convince people.

• Learn how to mentor and coach people.

• Discover how to give and receive effective feedback.

• Explore different strategies to communicate with a diverse group of people.

• Master writing to create better documentation to reflect your ideas and plans better.

• When you focus on the technical side, move your target from gaining technical depth in one or two specific areas to progressing through having technical breadth. You won't need in-depth knowledge about one language or framework; instead, learn concepts, programmatic approaches, and different architectural styles.