Category Archives: Technical

Cut from my writing up of AirFrance-KLM’s modernization strategy for it’s 2,000+ apps.

For each major decision (like modernizing an application, moving an application team to a new toolchain, putting a new platform in place, and other major changes to do how you do software), always have a business case. You have to avoid local optimization too: make sure you focus on the big picture, looking at dev, ops, and the overall business outcome. What does it mean to speed up the release cycle? Does introducing new services and capabilities make your daily business run more efficiently, or attract new customers? Does it help prevent security problems or add in more reliability? As they say “what is this in service of?”

This is especially important for avoiding gratuitous transformation, gold-plating, and other fixing it if it ain’t broke anti-patterns. Also, it will help you show people why it’s worth changing if everything seems to be going well. “[T]eams have applications who are working and sometimes are working quite, quite well,” Jean-Pierre Brajal says, “So people come to us and say, “well, why do I have to cancel my application? It’s already running.” You can use a business case to show the benefits.

Also, he notes, it’s important to make sure you’re improving the process end-to-end, not just one component. Let’s say you make automating testing the software better, but don’t address deploying the software. Now, when you’ve moved the team off their old system – that was working – you’ve introduced a new problem, a new bottleneck that they didn’t used to have to deal with.

There’s a lot more in the talk.