App Modernisation — Just Do It
As a consultant at Pivotal and then Tanzu Labs, I worked on many modernisation projects with different clients, and saw many more in their nascent stages during the pre-sales process with potential customers. I was often brought into pre-sales meetings at the point where a potential customer wanted to better understand what we could offer, and we at Labs needed to better understand their particular problem.
Often clients had already been planning modernisation of a business-critical legacy application for months, but had not yet written a single line of code. I could elicit guilty looks of complicity from a client team by saying: “I bet you have a lot of documents and PowerPoints by now”.
The problem with any major rewrite or modernisation of a large application is knowing where to start. And a purely technical analysis of your legacy estate won’t help you with that; it always leads to analysis paralysis. Six months of creating proposal documents, architecture maps, and presentations generates no value for your business. So, what’s the alternative?
At Labs we developed a collaborative approach to application modernisation with a relatively short discovery and analysis phase before we started to write code.
Step 1 — define goals for the project. What benefits did the business expect from the investment in modernisation? Often the first answer was “We don’t want another expensive round of app server license renewals in the next fiscal year”. That’s a fiscal goal, but leads straight back to a technical analysis of “how to do it” and doesn’t help find a starting point.
Step 2 — Dig deeper to find other business goals. What are the problems with this application? How long does it take you to go from an idea to having a new piece of functionality in production? What are the things you wish the application did better? Are there new features or functions that would help you grow or protect your revenue but that are currently too hard to implement?
Step 3 — Run collaborative workshops involving a mix of people: product owners, business stakeholders, technical teams, and users to understand the business process and how the current application landscape supported or hindered it. Event Storming was very effective as a way of building a shared understanding between the different groups of stakeholders. Event Storming also helped build a narrative, find the pain points, and we would use the information gathered there to select an initial slice for modernisation.
Rather than creating a detailed plan for modernising the entire application, we would find one thing we could implement using the new technology stack that would bring immediate value to the business. This new functionality slice would co-exist with the existing application, so an important part of the design process was working out the points where we could integrate the new and the old.
Step 4 — Start writing user stories and building the new functionality. Rather than spending six months on analysis, we had spent at most two or three weeks. And by writing code and getting it to production or at a staging environment, we could validate the strategy in the real world.
Step 5 — Repeat steps 1 to 4. The more often you did it, the faster the process went, and each time you go around the loop, you have modernised more of your application, and your legacy version has got a bit smaller.
The advantages of this incremental approach to modernisation are:
- You get started quickly and can validate your assumptions in the real world. The old military adage that “no plan survives contact with the enemy” applies to software modernisation initiatives too. The sooner you start doing the real work the sooner you uncover the problems your detailed planning didn’t reveal.
- You start to create value for the business faster by starting with something everyone wants improved. Too many modernisation strategies involve many man years of effort to create something that at best is no worse than the thing you are replacing — just on a newer technology stack.
- You and your team are intimately involved in building the new application. The expertise on both the new application and the process stays within the enterprise rather than walking out the door when the consultancy contract ends.
If you are currently struggling with a modernisation initiative and would like to explore some low-risk alternatives, message me on my Linked In profile at https://www.linkedin.com/in/paulthekelly/.
