Why Agile and DevOps Cannot Fix a Software Architecture That Is Hard to Change

Key takeaways

• Agile and DevOps improve the process of delivering software. They do not repair a system whose architecture makes changes hard to understand, test, and release.
• A modular architecture gives teams enough separation to change one part of a system without pulling several other teams and systems into the work.
• When architectural boundaries break down, delivery becomes slower and less predictable even if the organization has good people, strong processes, and modern tooling.
• The answer is not necessarily a rewrite. First, understand where the architecture is creating the most drag, then focus modernization work there.

Most organizations have already tried to improve how software gets delivered. They have adopted agile practices, invested in DevOps, automated pieces of testing and deployment, and worked to get product, engineering, and operations moving in the same direction. Many are now adding AI tools to help developers produce code faster. None of that is wrong. Much of it is useful. But there is a point where a better process stops producing the improvement everyone expected.

You see it when a request that sounded straightforward turns into months of work. A team may be asked to add a feature, change a pricing rule, update an integration, or address a security issue. Then engineering starts looking at the work and discovers that the change touches a shared data model, an old service, two downstream applications, and a workaround somebody built years ago because the intended interface did not do what they needed at the time.

Now the work needs several teams. It needs a much larger test cycle. Nobody is comfortable making a firm commitment because nobody is entirely sure what will happen when the change goes live. At that point, the problem is not that the team needs better sprint planning. The problem is that the system has become hard to change.

Agile can improve delivery. It cannot fix the thing being delivered.

This sounds obvious when you say it plainly, but organizations often treat every delivery problem as a delivery-process problem. If development is slow, add people. If releases are unreliable, add controls. If too much work gets caught in QA, automate more testing. If customers are waiting, put more pressure on the roadmap.

Sometimes those actions help. But they do not answer the more important question: what is making the work take so long in the first place?

Agile and DevOps are ways of organizing work. They can reduce handoffs, shorten feedback loops, and make it easier to release changes more often. They are especially effective when teams can make changes within a reasonably defined part of a system. If a team understands what it owns, knows how its component interacts with the rest of the application, and can test the likely impact of a change, good delivery practices make that work faster and more reliable.

However, if changing one component requires developers to understand several others, work around undocumented dependencies, and pull people into meetings because no one knows what might break, the architecture is already consuming the capacity the organization thinks it has available for new work. Better ceremonies do not fix that. More developers do not automatically fix it. AI-generated code does not fix it either.

In fact, all three can make the issue more visible. They increase the amount of change moving through a system that may not be able to absorb change cleanly.

The real issue is whether teams can make a change without pulling on every thread

A modular architecture is simply an architecture that gives teams room to work. That does not mean a system has no shared services, integrations, data, or dependencies. Of course it does. A complex business system is supposed to be connected. The question is whether those connections are clear and controlled or whether they have grown into a tangle nobody can confidently explain.

In a healthy architecture, components have defined responsibilities and interact through interfaces that teams can understand and rely on. A developer working on one area of the system does not need to know every detail of how another area is built. The software may be complex, but the complexity is contained well enough that people can work on it.

In an unhealthy architecture, that containment starts to disappear. A team bypasses an interface because it is quicker than waiting for another change. A component takes on responsibility for something that probably belongs elsewhere. A short-term fix becomes permanent. Over time, different parts of the system begin reaching into one another, and dependencies build in both directions. That is how a system becomes difficult to reason about. It is also how a seemingly small change becomes a much larger one.

Dan Sturtevant described the practical consequence well in his original article: when architecture degrades, the system becomes less understandable. Teams cannot reliably anticipate the side effects of a change, learning curves get longer, and the work of maintaining the system starts to crowd out the work of improving it.

The business may not call that an architecture issue. It sees missed release dates, higher maintenance cost, more defects, delayed modernization, and engineers saying, “We really do not want to touch that.”

But that is what it is.

This is why more people often do not create more capacity

There is a natural assumption that a software organization can move faster by adding developers. That is true when the work can be divided. It is not true in the same way when every important change requires the same people, the same context, and the same highly connected part of the system.

If ten developers need to coordinate constantly because they are all working around the same architectural core, adding another ten developers does not double output. It may just increase the amount of communication, integration work, and testing required to get a change out the door.

The same issue affects modernization. A company may decide to migrate to the cloud, replace a platform, integrate an acquired product, or introduce a new AI capability. On paper, each project can look manageable. Then the project starts and reveals that the application everyone thought they were changing is tied to systems, services, and data flows outside the original scope.

This is where organizations lose time and budget. They are not necessarily doing the wrong project. They are making decisions without a clear view of the structural condition of the software they depend on.

The job is to make the next change easier than the last one

This does not mean every old or complicated system needs to be rewritten. That is usually not realistic, and it is often not necessary. Mature software supports real customers, products, operations, and revenue. A wholesale rewrite can consume years of effort while introducing a completely new set of risks. The better question is: where is the architecture creating the most drag, and what would make that area easier to change?

Sometimes the answer is to restore a boundary that has been eroded over time. Sometimes it is to reduce a cycle of dependencies that has grown too large. Sometimes it is to separate a responsibility from an overloaded component, or to create a stable interface so that teams no longer have to reach into each other’s systems to get work done.

The right answer depends on the system. That is why leaders need evidence before deciding whether to modernize, replace, retire, or leave something alone. In the research behind Silverthread’s approach, architecture is analyzed as a network of actual dependencies rather than a set of boxes on a diagram. That makes it possible to see where components are tightly interconnected, where changes are likely to propagate, and where a targeted refactoring effort can reduce future cost and risk. In one example in Sturtevant’s article, a successful refactoring effort broke a large architectural core of more than 800 files into two smaller cores. The value was not that the diagram looked cleaner. The system became more understandable and less likely to create wide-ranging side effects when teams made changes.

That is the outcome that matters. The organization should not be spending less time on architecture because architecture is an abstract technical concern. It should be spending less time fighting the same architectural problems over and over again.

Architecture is part of the business’s ability to respond

A system can be stable and still be a problem. It can continue to do its job while quietly limiting what the business can ask of it next.

That is the tension technology leaders need to see clearly. The question is not whether the software works today. The question is whether the organization can change it when a customer, competitor, market shift, security requirement, acquisition, or modernization decision demands it.

Agile, DevOps, better tools, and AI all have a role in helping organizations respond. But they work best when the architecture gives teams a workable foundation. If the system has become a tangle of hidden dependencies, the organization needs to understand that before it assumes the answer is more process, more people, or more code.

Silverthread helps organizations make software architecture visible, measurable, and actionable so technology leaders can see what is slowing change, make better modernization decisions, and focus investment where it will have the greatest effect. To learn how Silverthread can help your organization contact us at silverthread.com.

Frequently asked questions

Can agile practices help a tightly coupled software system?

They can improve the way teams plan, collaborate, and move changes through delivery. But they cannot remove the dependencies that make those changes difficult to understand and test. If the architecture is the constraint, process improvements will eventually reach a limit.

What is modular architecture?

A modular architecture organizes software so that components have clear responsibilities and manageable dependencies. Teams can change one area of the system without creating broad and unpredictable consequences in others.

Do microservices automatically make a system modular?

No. A microservices environment can still be tightly coupled if services share databases, rely on undocumented behavior, or must be changed and released together. Modularity comes from the quality of the boundaries between components, not from the number of services.

Does a hard-to-change system need to be rewritten?

Usually, no. The first step is to understand where the architecture is creating the biggest delivery, maintenance, or modernization problem. Organizations can often create meaningful improvement through targeted refactoring rather than a full rewrite.

How can a technology leader tell whether architecture is affecting delivery?

Look for repeated patterns: small changes expanding in scope, extensive regression testing, delays caused by cross-team coordination, recurring defects, modernization projects uncovering unexpected work, and a small number of engineers carrying disproportionate knowledge of critical areas.

Foundational research

Sturtevant, Daniel J. “Modular Architectures Make You Agile in the Long Run.” IEEE Software, January/February 2018.

‍