tekBlueprint

Some time ago, it seemed that techradar was a fairly common and useful tool in large and small IT companies. But as it turned out, it is far from everywhere and there is no understanding of why it is needed. Of course, information about the tools and technologies used may be present in some chaotic form, but incomplete, unstructured and rarely updated. Therefore, I decided to write a short article with my purely subjective opinion on this topic.

Introduction

Yes, well-known large companies use methods to track trends and technologies within themselves, even open their tech radars to the public. But looking at them, the question arises: does what is published really bring any benefit, and not just an interesting picture with dots on it?

Let me explain, on the vastness of the Internet you can find techradars in the public domain, which by and large look like a list of buzzwords. It is unclear why they use these technologies. It is unclear when they updated them at all, since there are really old things. Sometimes the list itself looks strange. For example, JSON is indicated. This is what JSON means, do you know how to parse it? Unexpectedly, a rare skill. :)

Why and how

As I said above, my opinion is subjective, I consider techradar from the point of view of how it could be useful to me in my work. For me, techradar is a tool that reflects the tools and technologies used now in the company, their * future* direction of development, past mistakes or experience of use. Plus to all this, information about how exactly in this company certain technologies were used, and not just a quote from WIKI.

What I would like to see in techradar and what I tried to adhere to myself:

1. Must contain up-to-date information. If the information is not updated:
   1. Leads to erroneous assumptions about the competencies of teams or projects, a divergence of expectations between internal teams or external customers/contractors/solution vendors.
   2. Cannot be used as a source of information for planning internal employee training.
2. Information on the tech radar should not consist solely of the name. It is important to understand the following:
   1. Why exactly the technology is used in the company now. Why it is important and fundamental to the business. Recommendations for use.
   2. If this is a new technology, then why did you decide to try it, what can be improved in the future. That is, to understand whether this is someone’s whim without reason or still a conscious need that was arrived at through trial and error.
3. If this is an old technology that is being abandoned, then why is it still used (if any) and what will it be replaced with. What problems does further use bring.
4. Supporting the historicity of changes. Here I mean the ability to track changes in a certain technology. For example, in 2000 we started using C++, and in 2008 we abandoned it, transferred it to Hold, and reoriented ourselves to Java. With a comment and the reason for the change.
5. End user radar display tool requirement. The tech radar presentation should be visual and informative. With search, filtering, and the ability to export to various formats.

Usually, the radar is divided into 4 categories:

1. Adopt – technologies that are already in use and are considered key for the company.
2. Trial – technologies that have already been tested and are ready for use.
3. Assess – technologies that are being researched or planned for use in the near future.
4. Hold – technologies that are being abandoned or not used.

Additionally, an indication for transition states can be used:

1. New – technologies that have just been added to the radar.
2. Moved in – technologies that are moving from Hold to Adopt.
3. Moved out – technologies that move from Adopt to Hold

Who and how it can help

The main purpose is to maintain the relevance of technologies and their use within the company. Indirectly, it can help in:

• If the company is engaged in custom development, then in fact this tech radar is part of the company’s portfolio. That is, we clearly say what we can do and how we can do it.
• If the company is a product company or just a business that needs to automate part of the processes. Then this will help when working with vendors so that they can understand the expected requirements from the implemented solution. It is very desirable that it falls into the general tech stack, without breeding an additional zoo of technologies. This is especially important if the company does not have people who have sufficient competencies to work with new implemented solutions.
• It can help employees and teams within the company in choosing a technology for a new project. Often, one team does not know what the neighboring one uses and either does it again or uses analogues, possibly worse.
• Plan the training and development of technical and non-technical skills of employees. If a company has a radar, it is easy to determine what skills are required or will be required in the future for work.

If we consider it from the point of view of obtaining useful information from the radars of external companies, it can help to understand the market and the general direction of development in order to quickly respond to these changes and not remain an outsider. Yes, there are examples of the death of companies or strong stagnation and marginalization with a significant lag from the mainstream.

What I used

There are several ready-made open source solutions of varying quality. To be honest, there were questions about all of them and they were not completely suitable.

The trendsetter here is the radar from Thoughtworks. The source code is open, so many take it as a basis and modify it to suit their needs, which is what I did.

Below is an example of a radar from the Thoughtworks website:

What they liked:

1. The ability to create multiple radars in different areas (architecture department, testing department, project office, analytics department, development department, DevOps department, etc.)
2. Radar elements can contain a detailed description for each technology.
3. There is a historical nature of transitions between stages of technology use.

What was missing:

1. Tech radars are imported from CSV or Google Docs, but we want a normal user interface for adding and editing elements. Which had to be done nearby as a separate web application.

2. There is no ability to comment on technologies and discuss them inside the radar. More like an idea, but it can be useful within the company, not for public use.

3. Optional, but useful integration with LMS or employee competency management systems. So that you can build end-to-end communication. Again, it had to be done nearby as a separate service.

Conclusion

I found techradar to be a pretty useful tool, it closed some of the questions on existing competencies and gave a general clear picture of what was happening. But you need to keep in mind that its initial filling can take quite a long time. Specifically, meaningful and complete filling, and not just a list of names, just so it was there.

Thoughtworks as a ready-made tool is convenient to use, but it is not very convenient to modify it, it seems it is not designed for this. I would still like to make some kind of tekBlueprint.radar in the future with everything that was missing, without crutches in the form of services nearby.