About The Playbook
Korio is a group of professionals who came together to help companies re-platform and become agile and fast. We prefer to work with established companies in the mid-market who might be struggling with the transformation to digital. Collectively, we have gone through dozens of transformations. We have witnessed successes and failures.
Based on what we have learned, we have become quite opinionated on what works and what doesn't. This short post is part of a larger Playbook that we have assembled based on what we have learned.
For tactics that should guide how you think about your digital platform, explore the links below.
As we learn more from our clients and if we think that the learning is: A) actionable, B) validated and C) doesn't state the obvious, then we will add it to our Playbook.
Remember, everything we propose can be done incrementally and with very little lead-time. If you want to adopt the plays in a more gradual manner, go ahead but consider setting each up as an experiment: have a hypothesis, measure the impact and act on what you learn.
The Play: Replacing Legacy Systems Is Hard - Do It Incrementally
Consider leveraging a modular architecture, a Data Pipeline, Robotic Process Automation and Change Data Capture technology to slowly migrate from the burden that is your current platform. This is a practice commonly known as "Legacy Strangulation". As the name implies, the process can happen in stages but, ultimately, it ends in the decommissioning of the nast bits of your current platform.
While most companies will completely remove their old platform, it isn't always necessary. If your current platform has elements that are well architected (i.e. modular) and can be "plugged into" the new, emerging platform, there may be no need to turn them off. Not all software built a decade ago is bad. Often the opposite is true as it has really only been in the last ten years - in the rush to the web - that things got messy.
How
- Complete your Value Mapping and Business Architecture work to confirm issues and gaps in the current platform
- Identify architecturally clean elements of the current platform that can be retained
- Establish a Data Pipeline at the core of your new technology stack that can eventually scale to capture ALL business "events"
- Introduce Change Data Capture (CDC) technology into your new technology stack that can "listen to" and record data change events according to an API or "data contract"
- Build new services that are small and modular to fill the gaps and replace the messy parts of your legacy system
- Feed the new services with CDC data, in the short term and according to the API, to keep the old platform and the new services synchronized
- Slowly turn-off the legacy system by incrementally swapping in new services that use the established API/contract
- In cases where the new platform and the old platform have user interfaces that can't be made to work together, use Robotic Process Automation (RPA) to bridge the gap
Think carefully about this Play before proceeding. While it solves the problem of Big Bang Replacements, it comes with its own complexities and pitfalls.
Why Bother
- Big Bang Replacement projects are hard to get right. In the ideal situation, you would release new services in small increments so you could test them with users and start the learning cycle. Legacy Strangulation is an approach that finds a good middle ground because it allows you to be incremental.
- (Re)building your approach to digital by adopting a modular architecture and incremental developement is a massive win. The sooner you start, the better off you will be. Alternatively, working for 2 or 3 years before your team releases new modules to Production (i.e. into the market) is a significant missed opportunity.
What To Avoid
- Don't adopt this tactic blindly. Legacy Strangulation demands the acknowledgement of very specific decision rules and data contracts. If your legacy system's architecture can't be easily overlayed on these rules and contracts, it might be better to avoid this Play. What you want to avoid is a situation where your developer teams must write significant amounts of "glue" code to patch the new platform and the legacy system together. If clean CDC and RPA code won't do it, consider an alternative approach.
The Fallback
Ultimately, you may need to decommission your current platform and turn on a new "core" in one big step. If this is the case, we still strongly encourage clients to find small modules that can be released early. These might be features that don't need to be integrated with core systems. Work on these modules early in your transformation to give the teams exposure to the new architecture and new ways of working.