Essential Activities of Software Architecture

This article is the fourth one in a series that provides practical advice and guidance on how to leverage the Continuous Architecture approach. Today, we’ll discuss the essential activities of architecture, which together with the principles and tools, are a key component of the Continuous Architecture approach (see our “Revisiting Continuous Architecture” article).

In the industry and within each company there is a perennial debate about the importance of software architecture and architectural practices. We introduced Continuous Architecture five years ago to contribute to this debate with an objective of aligning architectural practices with agile and continuous delivery practices.

Continuous Architecture is based on six core principles, which outline how we can approach architecture in today’s world of agile, DevOps and cloud. Though the principles are a valuable guide for us, they are, by design, not a prescriptive guide to which activities to perform. We address this topic in our second book:  “Continuous Architecture in Practice” by introducing the essential activities of architecture as well as architectural tactics. We have found the essential activities to be the minimal set required to achieve a sustainable and successful software system. We believe that no matter what methodology or toolsets you are using, the essential activities for maintaining a sustainable architecture of a software system are the same.

We define the essential activities as follows:

• Focus on quality attributes, which represent the key cross-cutting requirements that a good architecture should address. Quality attributes—performance, scalability, and security, among others—are important because they drive most of the significant architectural decisions that can make or break a software system.
• Drive architectural decisions, which are the primary unit of work of architectural activities. Continuous Architecture recommends to explicitly focus on architectural decisions because if we do not understand and capture architectural decisions, we lose the knowledge of tradeoffs made in a particular context. Without this knowledge, the team can’t support the long-term evolution of a software system.
• Know your technical debt, the understanding and management of which is key for a sustainable architecture. Lack of awareness of technical debt will eventually result in a software system that cannot respond to new feature requests in a cost-effective manner. Instead, most of the team’s effort will be spent on working around the technical debt challenges—that is, paying back the debt.
• Implement feedback loops, which enable us to iterate through the software development life cycle and understand the impact of architectural decisions. Feedback loops are required so that the team can react quickly to developments in requirements and any unforeseen impact of architectural decisions. In today’s rapid development cycles, we need to be able to course-correct as quickly as possible. Automation is a key aspect of effective feedback loops.

 As depicted in the above diagram, the main objective of the essential activities of architecture is to influence the code running in the production environment. The main relationships among the activities are summarized as follows:

• Architectural decisions directly impact the production environment.
• Feedback loops provide visibility of the system’s behavior in production and so measure the impact of architectural decisions and how the software system is fulfilling quality attribute requirements.
• Quality attribute requirements and technical debt help us prioritize architectural decisions.
• Architectural decisions can add or remove technical debt. 

It might come as a surprise that we do not talk about models, perspectives, views, and other architecture artifacts. These are incredibly valuable tools that can be leveraged to describe and communicate the architecture. However, if you do not undertake the essential activities, we briefly described in this article, architecture artifacts on their own will be insufficient. In other words, models, perspectives, views, and other architecture artifacts should be considered as a means to an end—which is to create a sustainable software system.  

For more information on our book “Continuous Architecture in Practice”, please visit our website at continuousarchitecture.com or continuous-architecture.info