Architecture and Design
Before I get into this, the“architecture” and “design” I’m talking about is code. With that out of the way…
In software there is the idea of an Architect. This is a person that establishes the architecture of some system. It is not always clear what this means though. Some folks consider the “architect” the person that makes all the technical decisions, but that really isn’t true. A software architect is really responsible for setting the technical direction and guide the design of a complex system.
In practice this means a couple things. First off, an architecture should define how systems interact at a high level. The goal is not to ensure that some REST or gRPC protocol is used, but rather, that the message contains certain properties that reflect the design. A good example would be messages that contain event types vs. messages reflect models within a system. In an event based system, the protocol is often less important, where as a non-event based system might rely on the protocol to help convey what actions need to be taken. These are design decisions that should go into the architecture and set the direction of the system.
Next up, an architect should generally avoid technology decisions. This is critical as an architect is not going to write all the software for a complex system. The architect, by defining the design and guiding the technical direction, should avoid a specific technology decision until the very last moment. The goal should be that in providing a design, the folks working on the system can evaluate the state of the art and provide the necessary insight into the technology options. The architect can then evaluate the options and help make a decision according to the design and architecture.
Avoiding choosing technology is probably one of the most difficult aspects of being an architect. Those looking for guidance often have opinions on what should be used. The lack of a decision often feels like a technology that person feels is a good choice is being actively avoided with no explanation why. The reality is that the architect is simply hedging the bets of a design by trying to avoid being tied to a technology that might not be a good fit. A great example of this tactic is seen when selecting a database. A good architect will likely avoid a database decision for as long as possible. The reason being is that by avoiding that decision, the code written in the meantime will help to clearly define what features the database should provide. When it is time to select a database, you can do so knowing that the models and organization of the data in the code makes sense in the overall architecture and is a good fit for the database.
Finally, the architect needs to provide a direction for the system. Like in an company, the leadership is responsible for the alignment of its employees towards the goals of the business, the architect needs to provide similar alignment in the design. It is critical that an architect formalize how a system design functions such that teams confidently implement elements that can easily interact with the system as a whole. I’m calling this aspect direction as it often relates to the flow of data throughout a system.
In any complex system, there are going to be different requirements from different teams. The teams might have social baggage and internal preferences that stem from that team’s historical perspective. An architect’s role in this scenario is to provide direction such that these biases have a limited impact. The architecture makes this possible by keeping the guiding principles of the design front and center. The architect is not the building every element of the system, so it is critical that the design reflects where teams have clear autonomy to do what they feel is right and supports the system. The design and architecture helps to set this direction for the system and provides teams clear borders of autonomy.
The reason for an architect is to help place the responsibility of technical direction on one person. An architect is there to help make technical decisions when necessary, but more importantly, the architect needs to ensure a design is in place that supports parallel work towards a functioning system. An architect uses the design to make this possible and helps break technical ties when the need arises.
As someone who might be working with an architect, this should hopefully help provide a barometer with how well that person is doing. Understanding the role of an architect also should help to avoid unnecessary conflict around disagreements regarding technology choices. No one enters a role and knows exactly what to do, so my hope is that as a contributor to a system, you can help guide a new architect with good feedback.
