Read the full article here.

When the Agile Manifesto came out in 2001, it stated that one of the 12 principles of agile software is that “the best architectures, requirements and designs emerge from self-organizing teams.” At that point, many architects began to see the writing on the wall. Two decades later, that principle has proven quite prophetic, as the role of software architects and software architecture has dramatically evolved. In a traditional waterfall model, the architect played a critical early role in specifying the architectural blueprint that generally stuck throughout the life of the application. In particular, with monolithic applications, the die was cast that this was going to be the forever architecture, proven out by the inherent difficulties to re-architect and refactor monoliths that teams face today. Based on the conventions, best practices and technology stack of the era, this was a practical and rational decision that most organizations followed.

Fast forward to 2023 and these architectural decisions have become inconsistent—in most cases—with cloud-native patterns, processes and infrastructures. Even more so, the role of the software architect has needed to evolve with the advent of iterative, faster cycle, Agile methodologies delivered in a DevOps-driven culture. And yes, often by self-organizing teams. In the earlier waterfall model, software architects were heavily involved upfront and their participation and hence authority decreased once the original application was delivered. Now, with rapid development loops, high-frequency releases, updates and quick-turn MVPs, software architects need to proactively and continuously insert themselves in the development process throughout the lifecycle of their apps. Culturally, they must also adjust from an authoritarian role that dictates architecture to a more consultative and engaged approach that focuses more on influence than authority.

Exploring The Necessity Of Software Architecture

Some organizations have questioned whether they need the software architect role at all. High-velocity, self-organizing teams often democratize and share the architect role when they start off, but evidence suggests that eventually, problems emerge as every application faces its share of shortcuts, mistakes and short-sightedness. We need to look no further for such evidence than Exhibit A: the snowballing architectural technical debt that has been cropping out across a wide variety of applications over the last few years. Monolithic applications and their accumulation of technical debt should be a bellwether for any application team. These monoliths started out with a significant architectural technical debt handicap but have since ballooned into even bigger balls of mud. Architectural technical debt, as detailed in my previous Forbes article, is the accumulation of architectural decisions and implementations that lead to the high complexity of software, and includes deep shared dependencies, long dependency chains, duplicated code and dead code.

If mushrooming levels of technical debt don’t convince teams of the importance and value of software architects and architecture, architectural drift is submitted as Exhibit B. Like rust or rot that accumulates over time, architecture drift deteriorates the original composition and structure of an application and has a direct technical, business and cost impact. Ignoring architectural drift while building more and more features on top of an application is like adding more and more stories or rooms to your home while the infrastructure and foundation crumble. Eventually, the whole thing falls apart or collapses. Architectural drift happens to all applications, not just monoliths, so even applications that were originally well-architected can fall victim to neglect, shifting priorities, developer turnover, release pressures and a lack of visibility that any of this is happening. Clearly, someone needs to take responsibility for architectural drift and debt. The answer must be the architect.

While the evolved software architect role is needed more than ever, how an architect attacks this debt and drift problem is unclear. Observability solutions seem like an answer as they are already in use across a wide range of monitoring, logging and tracing use cases, but they focus solely on cloud infrastructure and application performance. To track architectural drift, architects need a continuous architectural observability approach. Just as infrastructure and application performance tools dynamically monitor behaviors, build baselines, set thresholds and detect anomalies, architectural observability best practices apply the same disciplines to software architecture and drift. Unlike static code analysis approaches, architectural observability needs to observe and analyze software architecture behavior (not code smells) in dynamic, production environments.

Architectural observability focuses on the problem of architectural technical debt. For example, within an application architecture, how can you help an architect identify the domains that are hidden deep inside a complex architecture so they can create efficient service boundaries that lead to cleaner separation, better modularity and effective cloud-native microservice architectures? This requires an understanding of resource dependencies and cross-domain pollution and entanglements while improving modularity by adding common libraries. By observing and analyzing the architecture, software architects can pinpoint and prioritize what needs to be fixed, building a modernization backlog for developers to address sprint to sprint. In addition, by creating an architectural baseline, the architect can detect drift as new domains are added or dependencies are introduced.

Final Thoughts

The question of whether software architecture still matters is unequivocal: it matters more than ever. However, its role and significance have fundamentally evolved in the age of Agile and DevOps. The software architect's job is no longer just about setting a blueprint in stone; it's a fluid, ongoing effort to keep the architectural debt and drift in check. High-velocity, self-organizing teams may be the standard today, but the complexities they introduce call for specialized vigilance. The emergence of architectural observability as a discipline represents an innovative leap forward, equipping architects with the tools they need to monitor, analyze and adapt architecture in real time. This ensures not just the functional efficiency of applications, but also their longevity, scalability and the ultimate success of the businesses they serve. Far from being obsolete, the software architect’s role has become multidimensional, providing the navigational expertise needed in a sea of rapid development and technological change. So, does software architecture still matter? The complexities and challenges facing today's software ecosystems answer that question with a resounding yes.

If you like this article consider subscribing to our bi-monthly newsletter to get information about our portfolio, solutions, and insights delivered to your inbox.