Is there compatibility between software architecture and agile methodologies?

Software architecture describes the organization of a system or its structure and explains how it behaves. A system represents the assembly of components that perform a specific function or set of functions. In other words, software architecture provides a solid foundation for building a system.

As the number of software solutions grows, a degree of homogenization between these solutions becomes increasingly necessary. In most cases, this process has economic implications, reducing costs directly or indirectly, which is one reason that makes software architecture valuable. However, this will only be worthwhile if it meets the architectural drivers (of principles and constraints), providing the necessary foundation for the rest of the code.

With these technological solutions, the implementation of agile methodologies grows. If we understand Agile as adapting quickly and embracing change, we are talking about a process of continuous improvement, which provides a high-quality solution in a short time. It is also about removing waste, that is, everything that is not worthwhile within a process.

There is an exciting concept within some Frameworks that tries to take advantage of both approaches, called Agile Architecture. The idea of ​​this combination is to have a reference architecture that builds solutions, with a degree of innovation that will feed the architecture at the same time that other teams can take advantage of it. However, these two universes may sound contradictory or incompatible to some professionals.

The issues that generate conflicts between software architecture and agile methodologies are:

1. Architecture is quality, so is there agility without architecture?
2. Isn’t an area of ​​architecture antagonistic to squad models?
3. Does the emerging architecture work?

There are several questions, and the answers are complex, so let’s go by parts.

The conflict between software architecture and Agile

From my own experience, at a software architecture event in 2018, in San Diego, we can say that our speakers received suspicious looks from the audience when speaking about agile methodologies. Fortunately, we were able to clarify Agile as an ally for all processes, dissolving the antagonism that professionals in the field tend to interpret the two subjects.

When looking at the characteristics of software architecture and comparing them with agile methodologies, both can seem a bit disjointed:

However, conflicts are not limited to theoretical differences. At the XPConf 2019 event in Montreal, a group of computer scientists prepared a survey bringing together several companies that use agile methodologies. One of the questions was about the disadvantages of agility, and the answers were as follows:

• 58% of respondents reported that commitment has dropped;
• 49% reported technical debts;
• 42% low documentation;
• 40% refactoring or restructuring;
• 26% poorly structured architecture;
• 16% high development cost.

The last five items on this list are related to quality, that is, to architecture activities. But what are the causes of these negative experiences?

The big mud ball

One of the biggest problems affecting software architecture is the term coined by Joseph Yoder, Computer Scientist and Agile Consultant from the USA, as “a big ball of mud”. A pattern where all software lacks a noticeable architecture. While undesirable from a software engineering perspective, such systems are usual in real life because of business pressures, developer turnover, and code entropy.

According to Yoder, many of our software systems are architecturally little more than slums. Investment in tools and infrastructure is inadequate in the vast majority of cases. Tools are often primitive, and infrastructure such as libraries and frameworks receive little investment. Individual parts of the system grow out of control. The lack of infrastructure and architecture sets precedents for problems in one part of the system, causing erosion and pollution of adjacent components. Deadlines approach like storms, and architectural elegance becomes increasingly unattainable.

So the first prediction we have here is:

Incremental architecture

The second reason is that agility preaches incremental architecture, improving the architecture as the system develops. To developers, this concept sounds like Nike’s policy: Just Do it, a method also known as Extreme Go Horse (questionable programming practices). It links incremental architecture with a lack of planning and reactive decision-making or even weak workarounds, which is a big mistake.

Incremental architecture focuses on the way developers and operations interact with the project, so it’s about finding the agile practices best suited to the software architecture. In this scenario, we have put together methods and techniques that help to avoid communication and process failures.

How to match software architecture with agility?

There is a solution to unite agile methodologies with software architecture constructively. We developed this solution through practice with our customers, and to achieve this goal, we use a tactic we call the Evolutionary Approach. In this process, we identify the needs that arise in the project, assess the capacity (time to change) to implement improvements, and look for a low-risk solution.

1. Finding needs – Visibility

This first step of the evolutionary approach is also called pain perception. In software architecture, pains arise anytime, so we need to develop an accurate perception of these pains. It is essential to anticipate the impacts of possible problems that may happen. 

We use some applications that indicate the system modules’ dependencies. In many cases, we find several connections that demonstrate a high probability of failure, such as a “tangle of wires”. As is a risk in a power pole, for example, it is a software risk.

2. Time for the changes to happen

If it takes time to change, does that mean the project needs detailed planning? No! Even because the idea is to add agility to the architecture by constantly improving the project. The most appropriate way we find to do this is through PDCA:

• Plan: Plan improvements:
• Do: Run tests;
• Check: Check results;
• Act: Act/Implement.

For some managers, this strategy can move towards the Go Horse model, with total development stops to resolve critical points, but the PDCA does not go that way. The tactic to avoid these downtimes is to have constant time for improvement. Before the project, an amount of time (weekly or daily) is defined to improve the system.

Therefore, we do not wait for problems to arise; we already know that they will appear at some point, and the way out is to allocate time. Our recommendation is to set aside around 20% of the weekly hours for all team members to focus only on quality. We call this behavior “qualitivity”, a word that does not exist in the Brazilian dictionary but expresses the time invested in quality to improve productivity. 

3. Security for change – Continuous testing

When we talk about security to change, we talk about low risk. To guarantee this, we usually work with safes whose access is exclusive to the specialists responsible for the architecture, but this is not the only method nor the most indicated. It goes back to the without agility, that is, without multidisciplinarity.

The agile way out is to seek reliability for the entire system; in this way, it is possible to achieve collaborative creation, promoting autonomy.

An automated testing approach is the most appropriate way to achieve system security, enabling risk-free changes. At all stages, from code planning and development to operation and release, we apply continuous testing, eliminating the risks of the changes we want to implement.

Yes! There is compatibility between software architecture and agile methodologies!

As we can understand so far, the idea of ​​incompatibility between software architecture and Agile is based on little-depth principles about what agile optimizations are.

It’s important to talk to an expert who understands both areas, and we can help you with that.

Here at Objective, we have some successful cases of implementing Agile in systems that used a Go Horse approach. Instead of technical debts and poorly structured architecture, as reported in the 2019 XPconf, our customers were faced with a well-organized system structure, with a more fluid and assertive process.