As businesses grow, their systems and processes grow with them. Ensuring software is easy to change for this growth is a huge step towards future evolution. Often systems are continuously built upon to factor for this growth but become hard to change and monolithic.

The Demystifying Software Modernisation series highlights the need to implement strategies to make software easy to change. Focusing on upfront design work can help a business understand the best strategy for them, often changing depending on the service or product a business offers. Modernisation is partly about creating a bespoke element that questions the current problem the business is having vs the growth and opportunity of the future.

Often, the process of a software modernisation project isn’t just the matter of modernising the software itself but also modernising the platform engineering behind it. It can often be the case that deployment pipelines have been written internally, and as businesses attempt to grow and scale, they can struggle to maintain the change of pace to cloud.

Below are 3 practical examples of strategies businesses can implement to make their software easier to change.

1. Code Hotspots

Development teams often need to work in parallel with each other, possibly on the same code. In some organisations, this becomes a considerable challenge. If we analyse how they’re operating to understand any dependencies they have on each other, we can begin to understand the dynamics of how they work.  This allows a focus on creating a backlog of tasks that can be performed independently without the dependency on someone else. Any contact point between the teams becomes well-defined, and developers can prioritise their work accordingly.

One way to strategically identify what areas are making the work difficult is by looking at the coupling points. Understanding where the change needs to be made and understanding what’s out of control, and therefore will slow the process. Often the factors out of control can be both at a development or business level. For example, if the process involves coordinating across multiple departments, this needs to be factored into timing across all teams.

2. Understanding Technical Debt

As things change, technical debt is often incurred. But, the term ‘technical debt’ is very generic. Software Modernisation should be completed focusing on business outcome and goals, so the technical debt associated is to increase business value.

A focus on incurring technical debt should be a business decision to prioritise areas for change. If something is being changed in the future, there is no business value to change it in the present. The focus on modernisation should be on the areas causing the business pain that will give the greatest value. A question asked in episode 6 of the Demystifying Software Modernisation series is, “What’s stopping you from making change happen in the quickest and simplest way possible?”

3. Modularization

Modularization can be extremely difficult to achieve. Just one factor of this is understanding at what level it should be focused on. There are currently a lot of monolith (a software application that is deployed as a single artefact where the source code resides in a single repository) applications that are poorly structured.

In a monolith, most of the features already exist. By looking at the current system, you can begin to cluster those features and behaviours, which gives the first indication of what should be together. Once the functionality of what should be together is understood – what do you do physically?

The Demystifying Software Modernisation series suggests keeping the modulation at a low level. If you are unclear of the boundaries, keep the features together physically to make a soft module so they can still access each other. During this process, the interface and value can be validated, and APIs defined, which gives everything time to stabilise until a physical separation can be made.

Watch the full Demystifying Software Modernisation series episodes 5 and 6 below to learn more about how your business software can evolve at the same pace as your business.

Demystifying Software Modernisation Ep.5: Strategies for making your software easy to change

Demystifying Software Modernisation Ep.6: Strategies for making your software easy to change (Part 2)

Learn how Codurance can help with your modernisation strategy with the final episode in the Demystifying software modernisation series.