Happy Thursday!
I wanted to talk about software architecture for a while but never felt ready. This is the fifth version of this email. I wrote it in four pages at first. But over the weeks, I learned that the act of writing is not just writing page after page; it’s rewriting and deleting unnecessary words. Four pages of thoughts and research condensed into less than a page. Okay, let’s dive into the role of a software architect.
💁 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. How an architect does this?
Sam Newman frames an architect’s job in three categories:
- Strategic goals
- Principles
- 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 defailed 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, mentor, and coach people, and discover how to give and receive effective feedback.
- Explore different strategies to communicate with a diverse group of people and 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 breath. You won’t need in-depth knowledge about one language or framework; instead, learn concepts, programmatic approaches, and different architectural styles.
In the upcoming Mektups, I will focus on the difference between technical breadth and depth and how you can boost your architectural thinking.
