If there is one thing to make new app development look like child’s play, it’s modernising old ones while still serving customers.
What were you doing in 2013?
Many of us were helping build applications now vital to their organisations and customers. These systems are everywhere. We tag and meme them as classic or legacy and often suck our teeth at talk of changing them. Unfortunately, app years are short; something built 15 years ago will today looks like an urban development from the 70s. Most don’t age well and need a serious renovation to bring them up to standard or support new business value.
🥛Glass half-full; As an industry, we have a lot of patterns and anti-patterns for making existing systems faster and safer to work on. App Modernisations generally fall into three categories, and the bigger the system, the more likely it is to require a combination of all three.
1️⃣ Replatforming. It’s about risk and operational efficiency. E.g. migration to the cloud, containerisation, hiding the old behind a modern behaving gateway.
2️⃣ Decomposition. A need to make new changes faster and safer. Large-scale refactoring of domains into new discrete data stores, services and UIs.
3️⃣ Rebuild. Some parts are a write-off. Building new and migrating users across is just as expensive and risky, but looks faster ⚠️Compared to decomposing, migration and demolition of the old one is the hard part.
Regardless of the approach, after multiple varied modernisations, my top three learnings are:
🚧Don’t skimp on the groundwork. Kent Beck puts this best as “for each desired change, make the change easy (warning: this may be hard), then make the easy change”. Think test automation, scientist patterns, observability and release controls. Teams also need space for engineering archaeology - investigating what a system does and how.
💡 Outsiders help, but no shortcut for (re)learning. The knowledge and constraints that guided the original implementation are gone or forgotten. Getting help from partners experienced in transition patterns and cloud-native is a no-brainer, but the team must relearn what’s essential and feasible today.
🚨 Something will go wrong - prepare your team and customers. Modernisations, at best, raise change friction with customers and go over budget. At worst, they create reputation damage, churn and team burnout. Start the conversations early with support and marketing. Broadcast the reasons for change and gameplay worst-case scenarios before significant releases. Practice your incident management in calm periods.
As perverse as it may sound, I’ve grown to enjoy the challenge of App Modernisation. The system has proved itself valuable compared to a green field that may be abandoned within a year.
Originally published on LinkedIn.
Comments