Today I want to talk about a common digital transformation topic I get asked about, application modernization. More specifically, how everyone is doing it but so few successfully. Typically the conversation starts with one of the following:
“I need to move off my legacy system, how can I use containers to do this?”
“How do we move to a cloud-native microservice architecture?”
“We’ve been told to move everything to the cloud, how do we do that with thousands of applications?”
Often, my initial answer is another question: “Out of curiosity, how did you get to this as your solution?”
Strangely, at that point, it often falls off the rails.
I’ll answer these questions in more specifically at the end, today though I want to talk about complexity and the need to experiment.
One of the biggest problems here is that these are all solutions looking for a problem. While we hope they may be appropriate solutions, hope is not a strategy. On their own, there is not enough information to provide guidance and we need to look deeper.
How did we get here?
Every company becomes more complex as it evolves. To move forward, we have to make decisions, and those drive complexity into the system. If we started by storing money for people then expanded into loaning them money and helping them invest, every new service we add brings more complexity into our environment. Regulation also adds complexity by enforcing the need for decisions we might not otherwise make.
Additionally, we have our stakeholders, the people in the system who make decisions. Whether they are executives setting direction, managers guiding the implementation, team members executing, partners interpreting requests or regulators applying policy, everyone is introducing change and hence, increasing complexity. The amount of this we have in our system is our complexity debt. Acknowledging the problem is half the battle.
A shout out to our friend complexity
Any system involving people could be considered at least complex. For a given input (e.g. we want to add this feature), the output cannot be predicted (e.g. how will the system respond with the new feature in place). To deal with this inability to predict, we experiment. (See Cynefin as a standard model for describing this).
So, if the most appropriate path to change in our complex system is to run a series of experiments, how does a blanket statement like move everything to “the cloud” make sense?
On the one hand, enabling teams to deliver value continuously provides them with the capability to experiment. Without technology platforms such as public cloud and containers that allow for rapid experimentation, gaining an understanding of your particular brand of complexity is challenging.
On the other hand, the system is complex, so whether a particular technology is the right one to solve your problem needs to be an experiment and hence, allowed to fail too.
The trick here is we need to run small, cost-effective experiments, learn from them and use those outcomes to decide our path forward. This, in it’s truest sense, is the essence of agility.
So what is a good strategy?
Understanding your application portfolio and how it interacts is a good start. Not everything will need the same approach to move forward.
As I was discussing last week in my post on Locality, Simplicity and Flow, empowering your delivery teams to make decisions at the rock face is a valuable way in which leaders can help control complexity debt and make the right choices to modernize your applications.
Having capabilities like cloud services (internal, public or hybrid) and containers are table stakes in empowering your delivery teams. However, not every application needs the same solution, and not every area will require the same level of assistance. Beyond providing the enabling capabilities, you need to provide the guidance and support for teams to build there own path with an understanding of what the organization requires of them.
Sometimes the simplest solution to a problem may be the easiest. Refactoring an application may leave you no better off than you were to start with if the underlying business process is flawed. Taking a different perspective to a problem may allow you to eliminate problems and provide value without changing the entire system. The best way to get that perspecitive is to empower your team and your leadership to experiment.
Conclusion
It is not one size fits all when it comes to application modernization. The systems we create and work within are complex in nature and require an open mind and varied perspectives. The solution is not just about putting the right tools and capabilities into place, although these are often good first steps. Building a powerful roadmap that incorporates opportunities for learning also helps greatly. Keeping your roadmap dynamic and adjusting as you go is critical.
So based on the above, here are some answers to the initial questions:
“I need to move off my legacy system, how can I use containers to do this?”
Look at your business drivers for moving. Moving to a new platform, especially one you may not have deep experience in managing, may not be the best solution. If the system is core to your business, not having deep internal expertise may introduce even greater complexity.
Containers require consistent system architecture. If migrating to containers is the right path, emulation is possible, but not every application will respond well to emulation and analysis is required. The cost you are looking to save in the short term by not refactoring the application may cost you more money in the long run.
“How do we move to a cloud-native microservice architecture?”
First of all, determine if that is the right solution and design pattern for you. Done well, this can be a beautiful design model. It can also be complete overkill depending on the business problem you are looking to solve. Perhaps a better goal will be to determine how to enable teams to deliver value independently.
Having the same organization that built your existing (possibly) monolithic, non-cloud native system build your new solution will often result in problems as you will not have fundamentally changed how the organization develops systems. See
.
Take a careful look at how you will measure success. An excellent way to measure progress is to baseline against the cost of change. If you find your cost of change increasing, then take a look at how teams are delivering and what platforms they use. For example, there can be a tendency to spin up workloads on a public cloud for experimentation but not spin them down. Which now continually costs you money.
Make sure you have the right tooling and metrics in place to manage your newly fragmented system effectively. Coach your teams and leadership on how to make decisions within the new application framework.
“We’ve been told to move everything to the cloud, how do we do that with thousands of applications?”
Start by creating a list of applications and categorizing them by how to treat them. For example, rearchitect, replace, retire and reframe.
Once you’ve begun to identify key applications that would benefit from rearchitecting into cloud services, assign teams to work with those applications to guide them through the process.
Look for the small wins, the low-hanging fruit that will enable your engineering teams to learn and still provide value to the business.
Understand that a central organization will not be fast enough to move everything. You could through money at the problem and outsource, but this will bring with it problems in that the outsourcer will not truly understand your business.
Remember, not all parts of your organization are the same. Provide a path to success that doesn’t rely on the central team. Create a set of guidelines of what is required for secure delivery, hold teams individually accountable and support them as needed. A model like can help with creating that common agreement as to what is required.
Of course, if you need help with any of the above, Xodiac and our ecosystem of partners are able to help you.