“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”
Will Durant
Firstly, let’s define what we consider as software architecture, to better comprehend the ideas presented here. At its most basic, software architecture can be viewed as a set of interacting software components designed to solve a specific problem. It proposes various pathways for a solution to meet both explicit and implicit business requirements. In essence, software architecture devises an IT solution to a business problem.
Next, let’s delve into the role of a Software Architect in an Agile context. It’s important to clarify that a Software Architect is not a super senior software developer. I believe an architect operates at a different level of abstraction than a software developer, even though they should be proficient in development and uphold best practices in software design and development.
In a company, it’s not uncommon to find architects operating at different levels of abstraction. I had the opportunity to work in a company that offered a suite of solutions. My role there involved considering all these solutions as an integrated whole. In such a setting, we may find software architects dedicated to each individual solution, alongside a software architect for the entire suite of solutions. The key distinction between these architects could lie in the level of abstraction they operate at. Some may focus on the scope of individual solutions, while the suite software architect needs to view each solution as a part of a greater whole (the Suite).
As software architects, we must manage trade-offs to identify various paths that best meet business requirements. I agree with Robert Martin’s view that the objective of our decisions should be to optimize operational and maintenance costs. We need to look beyond product or business requirements, considering those unstated elements that could negatively impact us over time. This, in my humble opinion, is the greatest challenge we have to manage. An Agile context simplifies our tasks since it requires us to manage changes, receive feedback, and adjust our solutions based on data-driven decisions.
In conclusion, software architects must remain open to receiving and managing changes, as well as feedback from each iteration and product release. It’s essential to analyze and thoroughly understand the problem, making informed decisions based on data to incrementally improve the solution with each iteration.
In upcoming posts, I will continue to explore the role of the Agile Software Architect. In the meantime, I would love to hear your thoughts on this topic.
–Carlos G.