How to use the Technology Radar

Introduction #

This Tech Radar serves as a crucial tool to improve our architecture practices by explicitly defining standard choices. The goals of introducing a Tech Radar include:

  1. Clarity on Standards: Being clear about the standard choices regarding language, framework, infrastructure, and process.
  2. Spreading Awareness: Increasing awareness of what and how development is handled across different parts of the organization.
  3. Reducing Tech Debt: Reducing the technology and architecture debt that can accumulate when teams build things very differently.
  4. Guiding Decisions: Providing guidance so that deviation from the organizational general vision must be properly reasoned.

The Technology Radar is recognized as one of four key supporting elements — alongside Architecture Decision Records (ADRs), the Architecture Advisory Forum (AAF), and Architecture and Engineering Principles — for scaling the practice of architecture conversationally.

Quadrants #

The topics of the quadrants should remain stable for the years to come. We decided to go with these quadrants:

  • Languages & Frameworks: That quadrant includes development languages (such as Kotlin, Swift or Golang), as well as more low-level development frameworks (such as Spring Boot), which are used in our projects.
  • Methods & Patterns: It is probably the most diverse of all quadrants as it contains not only methods and patterns concerning software development, continuous X, testing and software architecutral topics but also topics that define our culture at and organization of Arrive.
  • Platforms: Technologies related to the operation of software, platforms and infrastructure to run software, tools and services are the topics of that quadrant.
  • Tools: That section contains a range of software tools, from small helpers to bigger software projects, that we've come to love.

Rings #

The technology radar is a collection of technologies and cultural topics that are assigned to rings. The rings are indicators of how strong we agree and promote a topic. For familariy reasons to other technology radars we stick with those for rings:

  • ADOPT: Items strongly recommended for adoption and appropriate use in projects. Technology is platform supported, self-service and frictionless usable for product teams.
  • TRIAL: (Experiment/Assess), Items worth pursuing and trying out on projects that can handle the risk. This is often where experiments start.
  • HOLD: Continue using if you're already committed or deeply invested, avoid expanding usage to new projects or teams.
  • RETIRE: Technology or practices that need to be actively retired. A technology migration plan and tracker should be activated.Generally reserved for end of life frameworks and technologies.

FAQ #

1. My technology is on Hold — does that mean I have to stop using it immediately? #

Not at all. Hold means "don't expand usage" — if your team is already running this technology and it's serving you well, you can continue. What we ask is that you avoid adopting it on new projects or spreading it to new teams. Hold is a signal to start thinking about a path forward, not a mandate to rip things out today.

2. A technology my team depends on isn't on the radar at all. Should I be worried? #

Not necessarily — the radar covers the most broadly relevant technologies across the organisation, so the absence of something doesn't imply it's wrong or unsupported. That said, if you'd like visibility and alignment around it, the right move is to propose it through an RFC so the wider community can weigh in.

3. I disagree with where a technology has been placed. How do I raise that? #

We genuinely want that feedback. The radar is a living document and placements are always open to challenge. Write up your reasoning in an RFC, share it in the relevant Guild or at an AAF meeting, and make your case. Decisions are made through conversation, not decree.

4. How do I get a new technology added to the radar? #

Start with an RFC — articulate the problem you're solving, why this technology is the right fit, and what the alternatives are. Depending on the scope and significance, the RFC will be discussed in the appropriate forum: a relevant Guild for team- or domain-scoped decisions, the AAF for broader engineering concerns, or the Architecture Board for organisation-wide standards. The key is making the reasoning visible so others can learn from it and contribute.

5. Who decides what goes on the radar and where? #

No single person owns the radar. Placements reflect decisions that have been discussed and agreed through our architectural governance forums — Guilds, the AAF, and the Architecture Board. If you feel a decision was made without sufficient input from your area, that's a good reason to engage in the RFC process.

6. I want to experiment with something new. Do I need to go through the RFC process first? #

Not necessarily — small-scale, low-risk experiments are encouraged and don't require formal approval. But if the experiment has broader implications, involves shared infrastructure, or you'd like organisational backing, bringing it as an RFC early gets the right people involved before you're too far down the path.

7. Why is a technology we are successfully using placed in the 'Hold' ring? #

Understanding Our "Adopt" Choices: A Focus on Shared Success

We understand that seeing a technology your team currently loves and relies on placed in the "Hold" ring can be unsettling. It is important to clarify that the Tech Radar is a "current climate sensing tool" a snapshot in time representing where we believe our technical strategy should head next, rather than a critique of the hard work and decisions of the past.

Why "Adopt"? When we categorize a technology as "Adopt," we are identifying it as a "sensible default" or an "invested-in strategic default". By narrowing our focus to these specific technologies for new and target-state development, we aim to achieve several key goals that benefit us all:

  • Focus on Business Value: By limiting the paradox of choice, we enable product teams to focus on building unique business value rather than spending cycles integrating and maintaining non-standard technology.
  • Stronger Support: The "Adopt" technologies are those our platform teams are best equipped to support. Using these "invested-in" defaults ensures your team has a solid foundation and isn't left to solve infrastructure problems in isolation.
  • Shared Learning: When we congregate around a smaller selection of technologies, we "eliminate silos" and scale our collective knowledge. Instead of each team finding limited, isolated best practices for niche stacks, we can leverage and share solutions across the entire organization, learning from each other's experiences.
  • Future Flexibility: Organizations change; teams grow, shrink, and shift ownership. Ensuring the majority of us speak the same technical language makes future optimizations—like shifting domain ownership or reshaping teams—seamless. It ensures that moving to a new team doesn't require learning a "foreign" technology stack, allowing us to move together in the same direction.

This is Just the Beginning Please remember, this is just Version 1. A Tech Radar is most effective when it is sourced from the collective intelligence of the organization. We want to work with the collective engineering organization to shape Version 2. If you believe a technology is misplaced or if there is a nuance we missed, we need that feedback. This is a conversation, not a monologue, and your input is vital to getting it right.

8. What is Arrive's target state of technology? #

Our target state is the Global Platform — the converged, organisation-wide technology foundation we are working towards. The radar reflects both where we are today and the direction we are heading, with the Global Platform as the reference point for new and future development.

It is important to recognise that the Global Platform itself is a snapshot in time. Just as the radar evolves, so will the platform and its technology choices. They are not fixed or perfect, and they will change as we learn, grow, and respond to new challenges and opportunities.

Everyone has a role in shaping this evolution. If you see something that should change, improve, or be reconsidered, you can drive that change through our existing channels:

  • RFC — Propose and socialise changes with the wider engineering community
  • ADRs — Document significant decisions and their context
  • AAF (Architecture Advisory Forum) — Bring cross-cutting concerns and proposals for broader discussion
  • Guilds — Engage with domain and practice communities
  • Experience & Product Tech Steering Groups — Align technology direction with product and experience needs
  • Architecture Board — Escalate or resolve organisation-wide architectural decisions

The target state is a shared responsibility. Use these channels to help evolve a technology stack that works best for Arrive as a whole.

Contributing to the Arrive Technology Radar #

Contributions and source code of the Arrive Tech Radar are on GitHub: ArriveTech Radar on GitHub