There is an ongoing debate surrounding the role of software architects in agile software development lifecycles (SDLC) in today’s fast-paced business environment. While software holds significant importance for organizations in terms of competitiveness and business operations, the architectural decisions underlying software development have become increasingly crucial. They impact various aspects such as modernization, technical debt, engineering metrics, customer satisfaction, and costs.
However, traditional architectural practices, and with them the role of the architect itself are facing skepticism. Some are questioning the architect’s applicability to modern software development methodologies, particularly in agile environments.
The Agile Manifesto itself emphasizes the emergence of the best architectures, requirements, and designs from self-organizing teams, making it clear that even architects struggle to find their place in this process. With architecture drift and technical debt accumulating with every sprint, architects are seeking ways to actively engage in faster and more organic agile processes.
It has become evident that there is a gap between the architectural team and those who interact with the application on a daily basis. Even in the context of the microservice architecture, failing to adhere to best practices can result in a tangled mess that may force a return to monolithic structures, as we have seen with Amazon Web Services.
I believe that it is necessary to shift architecture left and provide architects with better tools to proactively identify architecture drift and technical debt buildup, injecting architectural considerations into the feature backlog.
With a few tools to understand the architecture or identify the architectural drift, the role of the architect has become a topic of extensive discussion. Should every developer be responsible for architecture? Most companies have an architect who sets standards, goals, and plans. However, this high-level role in a highly complex and very detailed software project will often become detached from the day-to-day reality of the development process. The modern development organization introduces various new roles and tools, leading to confusion about who owns the architecture, who owns technical debt, and what the minimum tooling requirements are to effectively address the problem. Alas, despite its importance, technical debt ownership remains unclaimed, resulting in a stagnant situation where nothing happens. So without ownership and without the right tools and insights into the architecture, architects end up planning for an application that differs significantly from the actual outcome. Developers deviate from the plan, and the technical architectural aspects become less prioritized, making some argue that the software architect’s role is no longer necessary. Let the technical debt accumulation begin.
Consider the metrics employed to assess the quality and performance of the software. Security, code coverage, and cyclomatic complexity are among the factors measured. Testing is obviously an essential practice, while code coverage measurement helps determine the quality of the testing process. But even here architecture is a different ballgame, and determining the appropriate measurement techniques and metrics for a specific software architecture remains a challenge. It is my opinion that the architect role has evolved to a point where it lacks the necessary tools, insights, and metrics to truly make a positive impact in terms of addressing technical debt and that technology leaders fell short in empowering architects to do so.
Technology leaders need to empower the architect with architectural observability. What is architectural observability? It is a software engineering best practice that provides architects with detailed visibility and context into an existing application’s architecture to profile and baseline how an application is architected, collecting observable dynamic operational and static data to proactively detect drift, identify significant architectural events, and fix architectural anomalies.
Architects must use architectural observability to understand how the code operates within the application and to define quality metrics that the software architecture, not only the code, must meet. This approach will equip architects with the appropriate tools, insights, and metrics to effectively carry out their responsibilities and make informed decisions. Perhaps then, the role of the software architect in the modern agile world will cease to be the subject of this ongoing debate.
