Why Enterprise Apps are So Hard to Replace Strategically
It’s finally time to get rid of one of your key enterprise applications. When you (or your vendor) launched it, it revolutionized the way you, your team, and maybe even your company functioned. But now it’s been 8+ years, and the application is getting in the way of your growth.
Maybe the system is slow and there are security concerns. Maybe as your business has evolved, its workflows are no longer relevant, and you need 2-3 other completely independent systems to actually do your job. Maybe there’s only one person in the business who knows how to use the app at this point (Valerie), and if she ever wasn’t around, no one would know how to use it (Valerie should really stop base jumping).
Regardless of the reason, it’s time to bite the bullet and replace this application with a new one. But outside of the normal obstacles to replacing a key piece of your business workflow (budget, training, shifting around key staff, etc.), there are often additional obstacles companies don’t plan for: the lasting legacy of the original project process, especially when that process was the Waterfall methodology.
This isn’t a post about why you should use Agile concepts when building your new software. There’s lots of literature out there breaking down why you should use Agile ideas rather than traditional Waterfall ones. This is a post outlining why replacing enterprise software in an Agile way is particularly tricky when the original system was built via Waterfall.
Waterfall & Agile from a Business Perspective
Before we get into why replacing a Waterfall-built app is challenging, I want to define a few terms.
If you want to learn more (or just need a refresher) on Waterfall vs. Agile methodologies, this is a great primer. But for the purposes of this post, I’ll define Waterfall and Agile from a business perspective, rather than from a practitioner’s perspective:
When I talk about Waterfall products or projects, I’m talking about products that were built in a fixed-price, fixed-scope way; someone wrote down detailed requirements for an entire system and then someone else built that system in its entirety.
When I talk about Agile products or projects, I’m referring to products that were built in a modular, iterative way, where features are prioritized based on importance and then shipped as independent pieces of the whole application when ready. These projects are often billed as time and materials.
The Lasting Realities of Waterfall
The step companies don’t plan for when replacing enterprise Waterfall apps strategically in an Agile way is the critical upfront work needed to dismantle the Waterfall paradigm, both technically and philosophically.
Every Waterfall project of a sizable scale creates realities that must be accepted before the application can be replaced:
Reality #1: Everything is Connected
First and foremost, Waterfall-built applications are often so interconnected that it’s hard to break out pieces to replace without having to then replace everything else. This can rear its ugly head in many different forms:
The UI/UX of a key workflow can’t be replaced without completely recreating other connected flows
To integrate with a new third-party application, an API needs to be rewritten, which then breaks all existing APIs
Clearing technical debt on a key part of the application’s database would break several different key functions, meaning those would have to be rewritten in full
The list goes on. This issue is the direct result of Waterfall’s fixed-scope approach. The all-in-one nature of a Waterfall application is elegant in a vacuum, but when any change order is needed, it leaves companies with the unenviable choice of either replacing the whole platform in its entirety or foregoing otherwise beneficial improvements.
Reality #2: Disparate Workarounds Abound
As a result, most companies end up relying on other independent systems and workarounds to get their work done.
By running these systems, it allows them to extend out the application without actually touching the underlying code, but this also has unintended side effects:
Knowledge about how all the workarounds work together resting in the hands of only select employees (Valerie, I’m begging you to stop solo rock climbing)
Reliance on third-party tools that introduce bloat to the system
Constant maintenance needs for the workarounds and connections to those external tools
Even when companies use workflow tools like Zapier and Elastic to alleviate the issues above, the core issues still remain. Just because Zapier knows how to pull in data doesn’t mean the overall user experience is any more optimal or cohesive. And on top of that, it can get expensive if you need lots of intricate integration triggers.
In essence, more work is done around the system than in or on the system.
Reality #3: “Done” Is Deceiving
More philosophically, the other complexity is that Waterfall espouses a concept of an application being “done” upon delivery.
Because the original price and scope were fixed, it subconsciously signals to stakeholders that there is no more work to do. That may work if you’re building a radar unit, but that’s not the case for custom software. Even if the application is perfectly tailored to the users who need it and there is nothing more to optimize, security updates and changing UI and UX trends necessitate unexpected changes. When an application is, on a philosophical level, seen as “done” upon launch, these sorts of things tend to be ignored until it’s too late.
All of these realities can make it feel like it’s impossible to replace the aging enterprise app in an Agile way. That often leads to another Waterfall project with the same underlying issues, or worse, to not replacing the application at all. But by accepting these realities as a byproduct of the original project process, it gives you back the power and perspective to build an application with the right features for your team.
So, What Next?
Accepting that there are going to be complexities replacing a Waterfall legacy application is the first step, but it doesn’t solve the daunting obstacle of how to solve those complexities.
Before diving into creating solutions, it’s critical that you do an analysis of why all parts of the legacy Waterfall system exists in the first place.
A Visual Analysis
Here’s just one way to get at the “why” and prepare for a strategic Agile transition to a new application:
Do an inventory of all the capabilities of the system
What are all the main capabilities users need to be able to do in the system?
Which external systems and workarounds are valid processes and which aren’t? Which can be simplified and/or added into the core workflows of the new application?
What do you wish the system could do that it currently cannot?
What changes in your workflows and processes do you see potentially changing in the next 5 years and where does the system need flexibility?
Write these capabilities out on sticky notes and put them all up on a whiteboard.
Arrange the sticky notes so that similar capabilities are clustered closer together to form modules.
For example, “Able to login” would be near “Able to register a new account.”
On a basic level, this will allow you to visualize what the system does and what parts are interconnected. But it should also make it clear both what groups of capabilities can be broken out and modularized.
From there, you can then prioritize those modules and…voila! The first steps towards an Agile roadmap!
By taking this first step to categorize and interrogate all the capabilities within your legacy system (including workarounds), it allows you to understand why the Waterfall project was structured as it was and what is needed in the new Agile project. That process isn’t always easy to do, though, so if you need help replacing an enterprise system in a strategic way (or implementing Agile concepts in general), let’s talk.
—
Originally written for Made In Tandem.