Who should be responsible for software architecture 🧢
Engineering teams in small to mid-sized companies often start designing their software with one clear goal: functionality. Their goal is not to design a mature or stable architecture (yet), but rather to develop a concrete solution that delivers value to their customers. However, in larger companies, stability is a key priority when designing new software architectures. Their engineering teams operate on existing, mostly complex architectures with a track record of providing value to their customers. They are responsible for architecting solutions that are both functional and sustainable. This is where the role of software architects comes in. In this post, we’ll expand on software architecture and how engineers can think more like an architect.
What is Software Architecture?
There are many definitions on the internet, but a simple way to think about it is that it’s a high-level view of components that are wired together to form a larger system. Or as Ralph Johnson described it in his email exchange with Martin Fowler:
“Architecture is about the important stuff. Whatever that is”.
Software architecture is a collection of important components that work together to deliver value to the user. Here’s an example below of a three-tiered architecture.
Software architecture overview
Software architecture by itself is not an important subject for users; however, poor architecture decisions can impact overall user happiness and increase customer churn. The architectural decisions are often made by engineers and/or architects, and these decisions have to be well-studied before building on top of the software architecture. Think of it as the blueprint of a new apartment. The architect has to produce a well-designed blueprint before handing it over to engineers to build the apartment. Whoever owns software architecture shouldn’t think of creating a “complete” design; rather, they should focus on creating a “good enough” design that naturally evolves based on the information they have at the time. This pragmatic approach helps you, the software architect, design, test, and iterate.
Who should own Software Architecture? 🧢
In start-ups and scale-ups, almost every engineer is responsible for the software architecture. Any changes made by an engineer should be considered within the context of the interfaces and abstractions in their current architecture and how to maintain stability after making their changes. Any proposed architectural changes require buy-in from the engineering team before implementation because the entire team ultimately owns and maintains the software’s architecture. The Architect role should be perceived as a collaborative responsibility of tech leads and senior engineers. They are the technical decision makers, and that includes architecture. Martin and Ralph also shared a similar view on why software architecture is important, for basically everyone: “One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change. It is hard to go back and change your basement, though it is possible.” For small-mid sized companies, it is often a better idea to allow engineering teams to own their software architecture. This gives them an opportunity to have more impact and scope for their personal development,
How to think like an Architect đź’
If engineers want to collectively own their software architecture, how should they think like an architect? Here are five things:
How to think like an Architect
1. Think deeply about the tradeoffs 🤔
Engineers know that to design a piece of software, they need to gather both functional and non-functional requirements. It’s the latter they need to focus on more closely. Non-functional requirements, also known as software qualities or attributes, are the “-ilities” that define how well a software system performs. Examples are reliability, availability, security, and testability. Engineers who think more like architects are able to discuss quality trade-offs when designing software architecture. They can also provide technical insights into which trade-offs are sufficient for the business. This ability comes from years of experience working on production systems and developing a strong understanding of the business they’re in.
2. Learn to zoom in and out 🔍
A strong sign of architectural thinking is when an engineer is able to design a component for a team (zoom-in) while being able to think about the boundaries of the component and how it connects with other components (zoom-out). An engineer who can zoom in and out of other components of a bigger system has the opportunity to collaborate with cross-functional teams! This also builds trust with non-technical stakeholders, where engineers can share different lenses on the architecture for planning.
3. Keep up-to-date with latest tech 🌟
Architects keep up with technology trends to understand which ones are applicable to their business. They follow the latest open-source projects (e.g., CNCF), subscribe to newsletters for tech updates like TL;DR or Last Week in AWS, and attend meetups to discuss or present new tools they’ve been experimenting with. For engineers to act like architects, they need to consistently think about their company’s tech stack: what’s working well, what isn’t, and what new tools they could introduce to their team. Regularly reviewing the tech stack helps maintain a strong security posture, keep up with modern solutions that improve developer workflows, and attract new talent to their teams!
4. Design to avoid human errors 🤦‍♂️
The main role of a software architect is to help the business succeed, and a key part of that is designing systems and automating workflows to reduce possible human errors. Human errors can happen when developers accidentally push bad code to production, an engineer manually configures something in the AWS console, a support engineer has over-privileged database access, or a junior developer is given access to the production database. Software architects establish good practices for accessing and deploying changes, and enforce Zero Trust policies to ensure that developers and support engineers only have the level of access they need to do their jobs. A great software architect makes it nearly impossible for human errors to happen. 🛡️
5. Build good business intuition 🤌
Architects can provide technical insights in leadership meetings and should have strong intuition about the how behind customer requests. Engineers who design software architectures need to understand what needs to be delivered to customers and should be able to look ahead to plan for scale or different customer requirements. A good business intuition is when an engineer can anticipate what will or won’t work for the business from a technical view. Building this kind of intuition means designing an architecture that solves today’s problems while also anticipating how it will need to evolve in the future. This often manifests in architectural patterns or abstractions that make it easier to expand for future business needs.
Conclusion
Software architecture is a critical piece of software development. Engineering teams address it differently based on their company size. Larger companies hire dedicated architects, while smaller companies like startups and scale-ups approach it as a collaborative responsibility of engineers. There is no universal solution for it; however, owning what you build is generally a good software engineering practice, especially since most engineering teams find it easier to own their architecture collectively and engage in engineering discussions that allow them to have more scope and impact than a dedicated software architect.