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 pages after pages; 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
💡 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 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, 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 progress 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.
In the upcoming Mektups, I will focus on the difference between technical breadth and depth and how you can boost your architectural thinking.
Complement this text with The Software Architect's Role in Software World Podcast.
Until then check out what I've published over last two weeks:
What I published over two weeks
On the latest episode of the Software World, I welcomed Denise Jacobs, speaker, author, and creativity evangelist. We talked about the inner critic that we all have and how it impacts our creativity. Search "Software World with Candost" in your favorite podcast app to listen to the episode. Don't forget to follow the show.
I have faced this question recently, and I went silent. I knew that laying off people or firing someone specific are unpleasant moments of management. I thought about it if I can do it or not.
Slowly but steadily, I'm publishing my notes from the book Building Microservices by Sam Newman. I posted my notes for the fifth chapter.
In the previous Mektup, I talked about this topic. However, since I stopped publishing previous versions of Mektup on my blog, I still found this topic important and decided to edit & publish it as a blog post.
As always, if you are enjoying Mektup, I would love it if you shared it with one or two of your friends. You can send them directly here to sign up. They will get this issue as a gift when they sign up. I try to make Mektup one of the best and actionable emails that you get to grow your software engineering and leadership career.