Introduction
What's a Software Architect?
Okay so we've established what Software Architecture is, sort of... but what about the person behind the blueprints? Well it's simple really, if architecture is about the important stuff, then an architect is the one who identifies, understands, and takes responsibility for that important stuff.
Who is the architect?
The answer to "Who is an architect?" can vary depending on the organization. In some companies, it's an official title held by someone; in others, it's the senior developers who naturally assume the role of architect.
Rather than getting stuck on who holds the title, it's more insightful to consider and understand the relationship and responsibilities between the ones who implement and the ones who architect:
Should architects develop?
Absolutely! If architects aren’t involved in development, how can they ensure their designs are actually followed? How will they know what the real state of the system is? How will they experience the solutions and problems that they themselves are creating? Without these insights, future decisions are only based on guesswork. Architects should be hands-on, at least to some extent. Maybe they’re not cranking out code 24/7, but they should be involved in code reviews or looking over the implementation once in a while. This way, they can keep the architecture grounded in reality, not just in diagrams.
Should developers architect?
Yes, again! Developers should indeed wear the architect hat, at least part-time. This approach isn't just about individual growth; it profoundly benefits the architecture itself.
When developers engage in architectural thinking, they bring invaluable ground-level insights to the table. They are the ones that have the finger on the pulse of the system so they understand the system's functionality, limitations, and potential like no one else. Their input helps shape architectures that are not just theoretically sound, but also practical and efficient. Moreover, when developers have a hand in making architectural decisions, it fosters a sense of shared ownership. They’re more invested in the overall system design, which leads to stronger commitment and better outcomes for the entire project.
The result
When both developers and architects engage in design and coding, you get a smoother, more iterative and more collaborative process. Architects who code can make sure that the software follows the design and developers who architect can provide valuable feedback on the needs of the system as well as the practicality of the architecture itself.
This approach fosters a culture of shared responsibility, leading to a shorter feedback loop between design and implementation, allowing for more rapid iterations and improvements to the overall system design.
An architect's responsibilities
The important stuff
As we've discussed, the core of an architect's responsibilities is identifying and balancing trade-offs for all of the important aspects of a system. What's "important" can change, the key is to keep asking, "What's important for this system, right now?" One day, it might be ensuring scalability for millions of users; the next, it could be optimizing for lightning-fast performance all while balancing constraints like time, budget an resources. A good architect knows how to prioritize these often conflicting needs, ensuring that nothing important is overlooked.
Ensure architectural integrity
It's one thing to make a decision, it’s another to ensure that it's actually being followed. As an architect, you need to keep an eye on how your decisions are being implemented in the codebase. This means taking part in the development process, for example participating in code reviews or maybe even jumping in to fix something yourself. The architecture isn't just a pretty diagram—it's a living part of the system, and you’re responsible for making sure it stays on track.
Constant analysis
An architect's work doesn't end once the initial design is complete, software needs to be able to support constant change. That means constantly analyzing the existing architecture which may involve:
- Identifying areas for improvement and proposing solutions
- Question outdated assumptions and axioms left over from previous eras
- Reviewing system performance metrics
- Analyzing user feedback
- Analyzing stakeholder feedback
- Identifying bottlenecks or pain points in the development process
- Identifying bottlenecks or pain points in the architecture
- Analysis of trade-offs
- Balancing the benefits of changes against the costs and risks involved
The architecture you designed six months ago might need a tweak today to handle new requirements, emerging technologies, or the evolving needs of the business. Keep it fresh, keep it relevant.
Technical breadth
"A jack of all trades is a master of none, but oftentimes better than a master of one"
While technical depth is essential for any software professional, an architect's value lies in their technical breadth. This means understanding a wide array of technologies, frameworks, patterns, and paradigms rather than focusing exclusively on one. Why? Because by maintaining a broad understanding and knowing a little bit about a lot of things, architects can compare trade-offs and make informed decisions to use the right tools for the job, rather than falling into the trap of overusing familiar technologies.
"If all you have is a hammer, everything looks like a nail."
Follow latest trends
In the fast-paced world of technology, an architect can't afford to hit the snooze button. They need to stay awake and alert to the latest trends, tools, and best practices in software engineering. An architect who is informed about the latest trends can bring fresh ideas to the table, allowing their team to benefit from innovations that could improve performance, security, or development efficiency. Whether it’s emerging design patterns, cloud technologies, or advancements in AI, an architect must be vigilant and ready to adapt to a constantly changing environment.
But be careful, it's not about chasing the shiny new thing—it's about knowing when that shiny new thing could become a game-changer for your system and your team.
Know the domain
But an architect can't just work in a technical vacuum, they also need to have an understanding of the business and domain. Without it how are they to make sound architectural decisions that align with the business needs? How will they communicate with stakeholders who only speak in specialized domain jargon?
A simple example of this is the business of a concert ticketing system. An architect needs to understand the business's needs to be able to scale up fast when taylor swift holds concerts while scaling down when only indie bands are playing.