Communication in two pillars. We’ll come to that later.
For a long time, I thought software architects were a thing of the past. There were some good amount, proven-to-be-working architectures. For example, you could pick up any web framework and base your business logic upon the MVC architecture. A model layer for your data structure, a view layer to interact with the end-user, and a controller layer to communicate between those two layers. What more would you need? I was an ignorant fool, of course. When I started working on bigger projects, the need to properly design a system dawned on me. MVC was an architectural pattern that can provide a skeleton for your application. However, the real work that needed to be done within the application was still there. You still had to design how various entities should work with each other.
Today, I work for an enterprise company. The project I’m working on has 3-digit engineers—so you can imagine how complex the codebase would be. However, we apply microservices architecture on a high level. Each subsequent team owns one or two microservices, and the complexity is limited by the work produced by a handful of engineers. Still, the complexity of these microservices can get out of hand. Two different paths could happen:
- You see an increasing amount of accidental complexity in a microservice. This increase indicates that the service has been (continuously) architected poorly.
- The essential complexity starts increasing exponentially, which is an organic symptom of the need to multiply. So you divide the service into two or more subsequent services, which also requires architectural thinking.
I learned to appreciate that thinking about software architecture is critical for creating systems that can change and adapt. It starts at the lowest level, where you decide where to put your code and how two classes relate to each other. Then it goes higher up and shapes the whole structure of the project at the top. With microservices, for example, one thing you do is decide which service communicates with which one to design the system. So that’s the first pillar: A good software architect should understand how various software entities should communicate with each other on each layer in a simplistic way.
The other side of the coin presents a much different ground. I would have thought that software architects are somehow isolated from both software development and product design. They would gather the requirements, shape the project’s skeleton, and then hand it over to the development team. Fortunately, that’s not the case. Not only do the requirements change, no one can come up with the perfect software architecture in the beginning. We, software craftspeople, are lucky because we are not dealing with concrete but abstract. We can transform our products based on the latest needs. To evolve the architecture, the software architect needs to be up-to-date with both parties: Business driving the software and development shaping up the requirements.
To my surprise, a good software architect needs to be a good communicator. I avoided the managerial path because I did not want to deal with “people” problems. Although a software architect can be an individual contributor or a manager, communicating with people is vital. It’s still possible to delegate “people” responsibilities to a people manager, but delegating communication is impossible. Whether you are seeking to make significant contributions to a project or structuring a small part of the codebase, you need to communicate your reasoning with others. I don’t want to express the buzzwords negotiation or selling here, but you’ll need better and better communication skills while you go higher up the ladder.