Technology Radar

Feb 10, 2019 · 7 min read
#techniques #tools #process

It’s all of a buzz at my current job at the moment. Change is in the air.

There is a lot to take in, and a lot to learn. Recently, I was one of two people who presented to our Project Management Office (PMO) on what was happening in our department. The main aspect of this presentation, and my life at work at the moment, was the Technology Radar.

What is the Technology Radar?

The Technology Radar was something borne out of ThoughtWorks which helps visualise the technologies being used, and their maturity within the business. The Technology Radar is an evolving, living “thing”, as technologies ebb and flow.

Our Technology Radar

Why is it important?

My current employer has always been a Microsoft shop. They have historically built native Windows applications, and everything from languages, tooling, frameworks etc has been Microsoft through and through.

We are now starting to move into web applications, and everything is up for discussion.

But, how do we manage this transition? How do you imbibe such a vast amount of information in areas you are not familiar with? How do you hold people to account for the choices they are making? As humans we naturally gravitate to what we already know.

Well, one of the tools helping us achieve that is the Technology Radar. Our Technology Radar is a GitHub repo full of markdown files. We have defined a branch protection policy to make sure folks are accountable for the choices being made, and that there is a thin layer of oversight. The mindset of the review team is to always try and say “yes”, as long as there is enough rationale and reasoning behind the technologies being put forward. We are not there as a hurdle to get over, but to facilitate the thinking and documentation.

How it works

Each quadrant on the Radar, has it’s own folder, and each ring in a quadrant is another folder.

tech-radar
  languages
    adopt
      tech-one.md
      tech-two.md
    trial
      ...
    assess
      ...
    hold
      ...
    README.md
  tools
    ...
  platforms
    ...
  techniques
    ...

Within the quadrant folder, we have a README.md that explains what we want the engineers to document in order to propose a new technology. This is not a tick box exercise. We are actively wanting this Technology Radar to be the one stop shop for engineers. To see what is being used, how it is being used, how teams picked it up, the good, the bad, the workarounds etc. Within the next few months, we are wanting teams to document their usage as case studies, for others to understand and learn from. We are very aware that a tool/language/technique etc may fail for one team, but may be perfectly fine for another, so this needs to be taken into account.

We make sure we cover off licensing, costs, management of the technology, community involvement, maturity etc. We have specifics for certain quadrants too, like “unit testing tools” and “static analysis” for the languages quadrant for example. This guidance will also change over time, once we are more mature at using this technique.

Submarines

What have submarines got to do with a Technology Radar? Well, a lot actually.

In this analogy, the submarine is your technology stack, platform, department (however you want to look at it). You have all your engineers on your submarine, but you need supplies. The supplies is your technology stack. Where you need to be careful, is taking that technology and going to the bottom of the ocean for years at a time. It’s not healthy. You have to come up for air (and to keep sane, I would imagine).

The longer you stay at the bottom of the ocean, and not at periscope level, your technology is decaying and going stale. You must come up for air, and to look around and see what technology is now available.

This is why the Technology Radar is an evolving thing for us. It’s not a one time exercise to define and publish. You need to nurture this living thing.

Define, Use, Evolve, Repeat

So, how do you stay at periscope level? We are still in the early stages of this, but at the moment we anticipate the way we are going to stay relevant is:

Review dates

Just because a piece of technology has been through the process, and made it to adopt, does not mean it will stay there. What is good for 2019, may not be good for 2020, or 2021.

The review dates are twofold:

Constant proposals

Every day, there seems to be a new technology, be it a tool or framework (looking at you JavaScript), we are constantly getting new proposals to review. Being on the review team is quite a privilege, as you get to have a good overview of what the engineering teams are thinking.

Deploy to production

Without true data, you cannot gauge how useful a technology is. Therefore we mandate that a tool/language/platform needs to go into production (in some fashion) in order for a technology to transition to the adopt phase. Only when you put something through its paces, do you know how it handles.

Small features

With the above in mind, you need to start small. As with most things in software engineering, break it down, use, and then evolve.

Fail fast and fail small

Fail fast is interesting thought process. It’s not a free pass. You are still accountable. You still have to learn. It doesn’t mean you can do as you please, and then say “we failed fast”. You still need a rationale. So, for me, you need to add the “fail small” comment afterwards. Fail in ways that are not meaningful, and limit the impact.

Iterate

This is a given in our world.

Learn to throw away

Learn to throw code away. Architect your solutions whereby throwing “stuff” away is not a problem. Services, apps, should be small enough to be able to be re-written (if required).

Hold people to account

The phrase de jour is “Is it on the Tech Radar” - No. “Should it be on the Tech Radar” - Yes. I’ve even fell foul of this, and I’m pushing the Technology Radar a lot in our department. It’s important we hold each other to account, and re-affirm our culture.

See also

Content

Social

Recent