Sequencing Architecture Modernization: Risk Averse vs Risk Tolerant
Modernizing an architecture usually take years. Even a decade or more is nothing out of the ordinary for large organizations who have accumulated legacy and heritage systems over long periods of time.
This presents technology leaders with one of the most difficult modernization challenges: where to start and in which order to modernize?
There are usually a number of factors which greatly complicate the situation. The need to keep delivering product enhancements and new innovations while modernization is in process is one big factor, and dependencies between modernization work items is another.
Often there is a tension. Starting with a simple exemplar to prove the new tech stack and lay the foundations is generally a safe and risk-averse approach. But, simple exemplars usually deliver little direct business value, and business leaders feel like they are being asked to commit to an expensive initiative with little tangible benefit, and other value-adding work has to be put on hold.
As a result, there can be pressure to begin modernizing a part of the system that will have a clear business impact. This increases risk: there is an expectancy to deliver while still discovering and establishing new foundations. This requires an increased tolerance of risk.
Low Hanging Fruit vs Last Toothpaste in the Tube
In the dream scenario, there is an area of the architecture which has a high value to the business when modernized and has little complexity. In the Architecture Modernization Sequencing Grid, this is the bottom right corner. If this option is available, then it’s an obvious win-win sequencing decision.
Starting with a new Product or Feature
An example of low hanging modernization fruit is a brand new feature that needs to be built and can be delivered in isolation with no dependencies on existing systems. There are 2 key things to keep in mind:
- There can still be significant complexity in the infrastructure, especially if there is a mix of cloud and on-prem.
- There is a lot to be discovered by modernizing an existing part of the architecture. Starting with something brand new defers these discoveries.
Avoiding the Last Toothpaste in the Tube
Another obvious sequencing decision is to avoid the last toothpaste in the tube in the top left, where modernization is going to be harder to deliver and there is little business advantage to be gained in doing so.
The key is being able to identify the last toothpaste in the tube. A few of the signs to look for are:
- Does not change often and there is no desire to change it even if possible
- Runs on legacy tech stacks e.g. mainframes and deprecated technologies
- Few people understand how it works and everybody is afraid to touch it
- A high number of dependencies
Risk Averse vs Risk Tolerant
Businesses are complex environments with many competing and interrelated goals, aspirations, and challenges. In my experience, there is rarely a clear standout win-win option for kicking off a modernization.
Instead, the discussion leans more towards starting with something simple and easy with little business value (risk averse), or start with something more complex and higher business value, but also higher pressure to deliver and more likely to incur unexpected delays, costs and challenges (risk tolerant).
Choosing a higher-risk starting point also has the potential to completely derail the initiative if many problems are encountered and the promised value is not timely delivered. People can get burnt very easily, and decide that falling back into old patterns is much safer than being part of the modernization.
Making the decision is not simply choosing to be risk averse or tolerant. There are a lot of factors to consider. The best leaders I’ve worked with took a structured approach, creating a checklist or scorecard to understand the major considerations.
Below is a generic scorecard you can use as an example. You should tailor the questions and the scoring system to the specific constraints of your project rather than using this as-is.
Business Value
Quantifying the value of a piece of work before it is delivered is difficult. If your organization doesn’t have a useful system in place, you could consider:
- Looking to see if the initiative is highly rated in the company’s priorities. If you’re not sure where to start, talk to product leaders directly or review company townhall presentation.
- Having a quantifiable number. If the initiative is tied to improvements or certain business metrics or OKRs, this can help to get a sense of the value. Usual caveats apply regarding the quality of those numbers.
- Sometimes work is valuable because it enables other high priorities to be delivered. Consider if this piece of work delivers functionality which supports other strategic initiatives.
Delivery Risks
As you are delivering modernization, especially at the beginning, unknown surprises which add time, cost, and other unplanned expenses are likely to occur. Consider the impact of such delays and how quickly they will be resolved.
For example, is this modernization work tied to business or product deadlines? And what would be the impact of missing those deadlines? Who will feel the pain and stress if those deadlines are missed?
When technical, organizational, or other kinds of problem do arise, will the company divert financial resources and people away from other projects to rapidly remove blockers? If blockers take a while to get resolved, and there could be many of them, potential deadlines could easily be missed by many months.
Discovery Value vs Complexity
While complexity leads to uncertainty and increases risk, complexity shouldn’t be avoided at all costs. Addressing complexity surfaces and removes unknowns and risk.
For each aspect of your architecture, it’s good to think about the level of complexity but also what can be learned. Not all questions will be equally important so be careful with your scoring system.
Obvious aspects to think about are frontend, API, and data with caveats: delivering a modernized data storage solution is more valuable but it’s also riskier than simply building an API which connects to an existing data store.
In my experience, infrastructure is always a top consideration, both in terms of delivering modernized infrastructure which makes future work easier, and dealing with the challenges of trying to develop new technologies on legacy infrastructure which can slow everything right down.
Modernization initiatives usually involve a new approach to authentication and authorization with a consolidated and modern identity solution. Establishing new patterns is highly valuable, but defining them and integrating with existing solutions can take a while.
Local development is also worth considering, too. How much will modernizing this area of the architecture allow you to improve developer productivity?
Thanks for reading my article.
Feel free to leave a comment if you’d like to add to the discussion or challenge any of the points raised.
I appreciate all good-natured feedback and interactions.
