How to escape the capacity trap of legacy architecture

When I joined a company a few years ago in a leading position, I first asked all the different tech teams to provide a brief summary of their status: where they were at, their key challenges, expectations, and the like. To my surprise, I found that in several cases that the agile methodology hadn't been adopted. When asked for the reason, the answer I got was "we're too busy firefighting; we couldn't possibly pull off a change to working ways right now".

I was perplexed. Basically, the teams stated that they didn't have enough resources to fix the exact reason why they had insufficient capacity in the first place.

So I asked them. If they thought a new methodology couldn't remedy their situation (with which all were very unhappy), what other options could there be?. And the response was the standard reply: more people, more time. But we all know that in real life, this is not how it works. These two resources are the most precious (and most difficult to come by) of all.

The problem is that this is symptomatic of many challenges we're facing in the technology world. There is a solution that developers and their leaders love—everybody believes it would make a great difference—but making a move is very difficult if there are so many pressing tasks at hand and stakes are high. Customers expect features; management expects results. It seems quicker not to change gears and instead push the pedal down just a little bit further—until the engine blows up.

In other words, throwing a lifeline to a drowning person won't help as long as they are too busy splashing about.

Of course, sooner rather than later, this strategy won't keep teams and companies afloat anymore. At some point, things will just begin to fall apart: the technology will become unstable or unmanageable, and the team will simply give up and move on because it is very frustrating to never get ahead of the curve. Instead of waiting for this inevitable outcome, why not take a look at the options at hand and change something before it's too late?

One of the reasons why humans are not good at changing something that still somewhat functions is because our minds prefer to stick with the familiar (which we think we can control) rather than taking risks (beyond our control). Humans don't like surprises; we are keepers by design.

It takes conscious effort to break this habit and look at one's options: what will happen if we carry on? vs. what could happen if we change it? If we know that we cannot (or it doesn't make sense to) maintain a situation for much longer, the risk attached to change suddenly looks much less intimidating.

Again, this must be a conscious process. Almost all people I spoke to who were stuck in the legacy trap of working themselves to death trying to keep a monolith functioning with modern services needed some professional distance to understand their situation. They became aware that they couldn't sustain this for long, and that it was also a waste of resources.

As a next step, reviewing the options usually makes it easier to accept and execute change. For example, moving from waterfall to agile methodology, or stopping to rebuild critical parts of the system with much better concepts and tooling. If it takes a few weeks to build something that will boost your output tenfold afterwards, it's simple math that management will also understand. Everybody will benefit: developers due to better working conditions, customers due to faster delivery, and management due to increased value creation in shorter periods of time.

Going back to my introduction, what the team later told me was that, thanks to switching to agile mode, "it felt so good to be in the driver's seat again". The team was no longer reduced to reacting and firefighting; they could now choose their battles—and win them, for the benefit of everyone involved.

As much as agile methodology was the catalyst for the team in question, we learned that WunderGraph is the catalyst for teams working on APIs. We saw many teams so locked into their routines of integrating and maintaining an ever-growing number of APIs that they hardly questioned their way of working. As soon as they took the time to try out WunderGraph, especially in connection with WunderGraph Cloud, which removes the need for infrastructure, they told us that it's an incredible boost to capacity without having to add new people to the team.

This is also one of the key use cases that exist for WunderGraph. We understand that the majority of systems still is either monolithic or a wild combination of more modern architecture patterns and a monolith. Time and resource constraints often hamper the efforts of solving this puzzle, so only a few teams are actually able to fix this by overhauling their entire architecture (but I am still yet to see a system that doesn't contain even a tiny bit of legacy code :)).

In my days as a project manager, sketching out projects to fix this would easily end up on a monthly or even yearly scale, which—understandably—was unacceptable in most cases. So all we could do was slip in a smaller project here and there to try to prevent the worst rather than building the best. As the system evolved in parallel, we never got things really fixed—just more complicated.

Being well aware of this problem, WunderGraph is designed to work and integrate with legacy architectures. Our goal is to make it as simple and quick as possible to create visible and feasible results for the teams working with our open-source SDK and WunderGraph Cloud. We follow these steps to help users and companies escape the legacy trap:

• Tame the monster (i.e., use WunderGraph as the API gateway for the monolith)
• Automatically integrate data sources (APIs, databases, etc.) into the Virtual Graph so that all information is readily available wherever you need it and in whichever fashion you need to expose it (automatically and securely, of course)
• If desired, run all integrations through WunderGraph Cloud to make deployments and collaboration extremely rapid
• With this capacity gain, replace the monolith at your own pace and build new services on the basis of the Virtual Graph quicker than ever before

All this doesn't take long, and there is a whole team to support the process. As a start-up, we understand how important it is to show results. And that's why it's our goal for our users, too.

TL;DR: We would rather stick with trying to fix what's there rather than taking a different approach. This is one of the reasons why WunderGraph was built: to make the transition from a legacy architecture to a modern setup, quick and easy. This way, teams can show results quickly and delight customers, developers, and management alike.