How a tech radar assists the conscious development of corporate IT ecosystems

Why should one create their own tech radar:

1. To keep one's competencies in check. Preparing a radar is an analysis of the environment and situation, a way to see where the market is moving and how general trends relate to our projects' technologies. It becomes clear right away in what aspects the company's development is headed vigorously, and which segments need a boost. 
2. To make correct architectural decisions. Teams get a source of information on which solutions are to be used for various purposes. 
3. The radar helps HR staff to look for people with the desired competencies, and to show the candidates which stack they're about to work with. 

Basically, it's now easier for the company to develop its technologies consciously: to concentrate efforts on proven solutions; to understand clearly why its staff need to know how to work with a specific service; and what developer skills will be the most valuable in the short run.

Tech radar structure

The tool combines four categories: (1) techniques and languages, (2) platforms and infrastructure, (3) frameworks and instruments, (4) data management.

Each of these spheres can be split into 4 rings:

• Adopt — technologies actively engaged in the projects.
• Trial — field tested technologies that are about to become the company’s asset.
• Assess — technologies the company is still considering.
• Hold — outdated technologies that haven’t met the expectations.

Image

Our radar contains over 160 technologies. This list draws a picture of which technological trends are the most prominent in our IT landscape.

Three big enterprise IT radar trends 

Having studied our partners' and other large companies' tech radars we have singled out general trends. Further we'll say more about them and provide examples of technologies relevant to each of our radar's topics.

1. Distributed cloud environments. This is definitely the main trend of the recent few years. Monolithic products are history. Now companies use microservice apps and cloud platforms to ensure higher performance per unit of cost.

We’ve got the following solutions in this tech pool:

• Kubernetes and Openshift, the basis for private clouds
• Docker and Docker Compose — globally known app deployment means for containerization supporting environments
• Harbor — we use it as the Docker Registry and to check container vulnerabilities
• ELK product stack for distributed system logging and monitoring.
• Jaeger — platform for monitoring, tracing and transaction management in distributed architectures.
• Istio — traffic and load balancing management, user authentication and authorization.
• KNative — platform for composing Serverless products which enables optimizing resources and simplifies maintenance operation costs (logs, monitoring, metrics).
• Microsoft Azure and Google Cloud public clouds — we use them for the cases when data may be submitted to external infrastructure, such as dev environments.

2. Simplifying product development. This category includes technologies that help speed up the development pipeline so the company can deliver releases faster, get user feedback, and advance its products without any drops in quality. The second crucial task is to make life easier for developers, i.e. by automating repetitive operations to the full extent, and getting rid of manual code checks.

What we use to address these tasks:

• Azure DevOps — DevOps pipeline creation and replication, implementation and distribution of the best development practices.
• SonarQube — static code analysis, test coverage checks, general readability, etc.
• Google Analytics, Google BigQuery, Grafana — analytics and data visualization means used to monitor user behavior and test working hypotheses
• Kotlin for the backend — a more concise and safer language than Java
• Development approaches:
  • Continuous Delivery
  • Trunk Based Development
  • Feature Flags
  • A/B testing techniques

3. Product safety. The transition to distributed cloud architecture changes security requirements. Now one cannot build a secure loop around a product; each app within the system is a potential threat. Safety requirements for a specific microservice rise significantly, and the approach to vulnerability search changes and shifts to the early product development stages.

For instance, Docker images and third-party libraries used and reused in products must be checked for vulnerabilities; such checks are to be integrated into the pipeline so that unsafe code can't reach the production environment.

Cloud platforms and the need for remote maintenance and remote workplace access, and development of the Internet of Things are changing how ecosystem security is handled. As the number of potential attack points has grown and will keep growing exponentially, companies need a distributed modular approach to safety. One may argue that the security perimeter is also undergoing a transition from a monolithic to a microservice architecture.

Since the company isn't in a position to use unsecured technologies, the safety topic gets spread across the radar. For instance, SonarQube helps us check code for basic vulnerabilities, while using Kotlin for the backend reduces the risk of dangerous bugs in the product. The aforementioned Harbor enables scanning containers in use for security, and replaces a similar tool, Nexus (release storage and distribution code repository manager) — for the very reason that the latter provides a lower level of security.

Conclusion

To get the most out of such a tool, the technology stack is to be checked regularly, at least via annual snapshots. This way all teams will be on the same wavelength, and the company will develop more consciously without spending resources on technologies that don't provide maximum efficiency.

If you want to create your own radar, here’s the action plan:

1. Collect opinions from the company's technology experts on which trends are currently essential in their area.
2. Inspect solutions for each of these areas. Checking the existing radars of large companies may be of use as many of them publish their know-hows as we're doing now.
3. Build a structure in a convenient format such as a table, a knowledge base, or a visualization like the one we used.
4. Agree with those in charge of the technologies to check and update the product set in their respective areas regularly.