My random thoughts on two things to keep in mind before you get into a legacy modernization effort. One is to “know what you are getting into” and the other is “have patience”.

You hear about public cloud, cloud native, microservices, streaming, devops, observability, agile, kubernetes, etc. The list goes on and on. Then comes the heavy noise around digital transformation. You review your application portfolio and identify a few products that are candidates for modernization. You call in a few consultants (maybe) to help and/or you decide to initiate your own modernization efforts. Fast forward a few months (or years – hope not) and you have nothing to show except lost time and money. You are then forced to call in more reinforcements or worse kill the effort — and probably restart.

This experience is shared by others too, maybe with varying degrees of success (or failure). No one has a magic prescription to guarantee success, but keeping a couple of things in mind will definitely improve your chances.

1. Know What You Are Getting Into

For all but the simplest systems, your journey is guaranteed to be fraught with pain. Before you sign-off on a modernization effort, spend some quality time to understand your space better and validate the modernization drivers. Once you have the concrete reasoning — make sure to steadfastly support your team during this journey. Build a moat around them to protect them through this journey, so that they can focus.

Software Delivery Performance

There are four key metrics described in the book “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” by Nicole Forsgren, Jez Humble, Gene Kim. Rate the delivery health of your products against these four key metrics (below are excerpts from the book).

1. Delivery lead time – the time it takes to go from code committed to code successfully running in production
2. Deployment frequency –  how often do you deploy code to production
3. Time to restore service – how long it generally takes to restore service for the primary application or service they work on when a service incident
4. Change fail rate – what percentage of changes for the primary application or service they work on either result in degraded service or subsequently require remediation

Tech Health

1. Is the tech you are using past end of life (or getting there)?
2. Does the tech have a community around it?
3. How does your infrastructure look like? Is it a bunch of physical machines and/or some VMs running older Linux/Unix/Windows versions? Is the product running on Mainframes?
4. Is there a healthy market to find talent for the tech you are using?
5. Are you heavily dependent on expensive proprietary tech?
6. Is this a monolith? Answering yes here does not automatically mean you should transform. In some situations a monolith may just be fine.
7. How tightly coupled are other systems to yours? Are dependencies reading from your database directly (yikes)? Do you even know which external systems are using your system?
8. Are you having constant performance issues?
9. How hard is it to debug a production issue?
10. Do you have the right telemetry?

Talent

1. Are engineers excited to join your team to work on these products?
2. Do they feel they are learning and advancing their skills?
3. How difficult is it to onboard a new engineer, such that he/she can start writing code and deploy to production in a matter of days or couple of weeks?
4. Are you heavily dependent on a few SME’s?

Business

1. Has the business process itself changed drastically since the system was originally built?
2. Are there business requests that you are unable to deliver due to the current architecture?
3. Does the business have metrics in terms of product use from a customer perspective?
4. Do you find that your business is driving feature requests and they tell you how to design the system? This is a not necessarily a reason to modernize, but at times could be a strong indicator of an aging system with tribal knowledge spread around.

For each of these areas give your product an honest assessment. Get someone who has no connection to the product, team or org do this exercise. If you are doing bad on a whole lot of them  then you might need to consider a modernization effort. If you instead have a good grade then go give kudos to that product team and move on.

2. Have Patience

Yes have patience. The road ahead is going to be tough. Keep a close eye on the effort so you can adjust the direction based on ground data, light up dark areas by providing the right type of support and pro-actively fix potholes.

I make an assumption here that management is fully committed to building and sustaining a strong team. Building the right team is critical and a topic by itself, so I will not go into that in this blog. 

If you are expecting quick results you will be disappointed. Unraveling years of legacy features and understanding what was done is extremely painful. Chances of having reliable documentation is low to none. The truth often lies in the code. You have to scrape knowledge from your product experts (from business and tech) and also your customers. You will have to role play as customers and understand the app behavior first-hand. A lot of time will need to be spent analyzing existing code for business rules that folks may not be aware of. Understanding external dependencies are critical since you need to work with them to adopt changes.

The newly hired engineers have zero knowledge of your system internals, so expecting quick results is simply not going to happen.

Be ready to build features in small experiments and commit to dark launches to try out the newly built feature in production (using traffic mirrored from the legacy). These features on their own may not be able to replace the legacy system (yet), but can provide valuable insights when compared to legacy.

To summarize, you need to commit to and have patience with these efforts.

1. Be ready to review existing code to dig out business rules (and then validate if still needed).
2. Identify SMEs and other dev resources to perform code analysis, document key requirements (in confluence or wherever effort is minimal). This in most cases has to align with what pieces of the system you are tackling first. Would not recommend a 6+ month waterfall analysis effort, but some pre-work has to be done.
3. Commit to deploying small increments in dark launch mode to create a feedback loop without impacting current system. It may be a few iterations before a working service is built, such that it can replace existing functions.
4. Decide on greenfield vs brownfield. For the most simplest systems you can go with greenfield, others need a brownfield strategy since you are modernizing while the old train is still running.
5. Create a path forward for SME’s. Meaning – don’t leave them behind. Set expectations for them to leverage their subject matter expertise and the need for them to learn nextgen tech stack. Be ready to commit significant time/money to helping them through the journey.
6. Ensure business confirms/owns the requirements for nextgen vs. saying “hey just build it like it is in production today”. While it is a collective effort to figure out the requirements, someone must take ownership.

 

end