Software Engineering

Communicating the evolution of your technology stack – and keeping it in check!

Any organisation more than a few years old typically ends up with a pretty diverse set of technology in use, changing over many years. Team members come and go with different skills, motivations and interests. Technologies shift in popularity, industry trends, and therefore in availability of skills, and ongoing support.

Keeping this in check requires active effort across engineering teams – both in the choice of adopting new technologies, and deprecating and ultimately removing old ones.

When reflecting on how to communicate this aspect of our technology strategy, I ended up applying some labels vaguely similar to ThoughtWorks technology radar, albeit one with a broader lifecycle mapped out.

  • Remove – we are actively working to remove this technology from our stack. There should be a clear replacement or alternative strategy.
  • Hold – avoid increasing dependency on this technology. It might be deprecated or we are no longer sure it fits with our strategy.
  • Continue – continue to use this technology as you see fit
  • Adopt – we are actively increasing usage or adopting this technology (often there is a corresponding technology being replaced with a Hold/Remove status)
  • Evaluate – actively evaluating a specific technology, maybe spiking some code to solve a specific challenge, or during an internal hackathon, without yet committing ourselves to it’s ongoing use.
  • Future – something we’ve heard about, and think might be relevant, but don’t plan to evaluate yet.

These could apply to programming languages, frameworks & libraries, SaaS tools or even architectural approaches – and could be split across different segments (Office IT, DevOps, Platform, and sometimes technology specific verticals too eg Java or Python)

The aim here primarily is to build awareness and trigger active conversations – to avoid adopting a new technology into the stack without considering the wider context, or continuing to establish deeper dependencies on a technology that is on the way out.

If you’ve found other approaches that have worked well for you, I’d love to hear them.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.