Two weeks ago, I wrote an article to you (a non-developer) who is responsible for a core system running in a US cloud. It provided some guidance on how to proceed. Today, I will continue my attempt to share helpful tips for the same audience. This time I will focus on common pitfalls to avoid when you investigate how to execute the transfer to a new runtime environment.

The tips are generic for different types of architecture modernisations, not just for moving between different runtime environments, but they should be useful in that specific situation. Of course, context is king as always, so keep that in mind as you read on.

@Community, please help out with solid advice on how to move from US clouds to a new runtime environment. The target audience is non-developers.

Pitfall 1: Blame

It’s common to become surprised when reviewing decisions that were made, perhaps ten years ago. When stress levels are high, it’s easy for blame to arise. However, if blame starts being thrown around, the environment can turn toxic very quickly. Trust goes out the window and psychological safety is low. This is for sure a significant pitfall and a common one.

It’s unproductive to dwell on why what now seems as strange decisions were made and whose “fault” it was. A more constructive approach is to recognise that these decisions were made with different information than we have today, and very likely deemed sensible at the time. And even if they weren’t effective in hindsight, it ultimately doesn’t matter (except for possible learning of course). You can’t change history. You need to look forward and solve your current challenges.

Pitfall 2: Analysis paralysis

Another common pitfall during the analysis phase is the endless amount of information and things to check out, you just never run out of it. Many people also feel uncomfortable moving forward without perfect understanding and a flawless plan. There are many problems with this. One is that time is running and running without any real progress being made. We need to get into action. Another is that the value of each additional day spent analysing is quickly decreasing (diminishing return). It can also result in uncertainty spreading in the organisation as people wait for the analysis to be presented and decisions taken.

A simple and powerful solution to this problem is to dedicate a certain amount of time to the analysis, like a timebox. And favor keeping it too short, rather than too long. That way it’s super clear when the analysis is “done” and ready to share. In the worst-case scenario that there is no valuable information to share, that’s actually an important insight on its own. But more often than not the timebox will result in a lot of insights so that a decision can be made whether further analysis is needed or if it’s time to take action. (Or quite often both, but for different areas.) After all, it’s super important to start doing things. Executing the first steps of what might be a very rudimentary plan will typically provide extremely valuable new information.

Pitfall 3: ONLY tech reasons

Finally, the most critical—and the most common—pitfall when it comes to architecture modernisations, is to allow the initiative to be driven only by technical motivations. While getting rid of technical debt for example might make a lot of sense, if the business value isn’t clear and substantial, there’s a significant risk that the modernisation project will end long before it’s “done”. This can lead to an increase in the technical debt because of a new “generation” in the codebase, while the old is still there. (If the modernisation for getting rid of technical debt is successfully done in baby steps that continuously are deployed to production, this is not a pitfall.)

Driving the modernisation from a business perspective such as increasing revenue or decreasing business risk—increases the chances of successfully finishing the initiative. Running it like that is actually much easier for the techies too, since a clear understanding of the ”why” helps guide a thousand micro-decisions that arise every day. This is also a reason why the concept of Domain-Driven Design (DDD) is so important and popular.

@Community, any more common pitfalls and solutions to share?

Hope is getting stronger, right?

As you might have noticed, none of these pitfalls are really centered around tech, but more around human mindsets and behaviours. That’s no coincidence. As strange as it might sound, tech is rarely the problem. Compared to human dynamics, tech is actually quite easy and manageable.

I hope that knowing that will bring hope to people outside of software development! And don’t forget, taking action is also a real hope creator!

This article was originally published on LinkedIn. Join the discussion and read more here.