Technology Radar

NOT ON THE CURRENT EDITION

This blip is not on the current edition of the Radar. If it was on one of the last few editions, it is likely that it is still relevant. If the blip is older, it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don’t have the bandwidth to continuously review blips from previous editions of the Radar.
Understand more

Oct 2021

Adopt

We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects.

We continue to see platform engineering product teams as a sensible default with the key insight being that they’re just another product team, albeit one focused on internal platform customers. Thus it is critical to have clearly defined customers and products while using the same engineering disciplines and ways of working as any other (externally focused) product team; platform teams aren’t special in this regard. We strongly caution against just renaming existing internal teams “platform teams” while leaving ways of working and organizational structures unchanged. We’re still big fans of using concepts from Team Topologies as we think about how best to organize platform teams. We consider platform engineering product teams to be a standard approach and a significant enabler for high-performing IT.

Apr 2021

Adopt

We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects.

As noted in one of the themes for this edition, the industry is increasingly gaining experience with platform engineering product teams that create and support internal platforms. These platforms are used by teams across an organization and accelerate application development, reduce operational complexity and improve time to market. With increasing adoption we’re also clearer on both good and bad patterns for this approach. When creating a platform, it’s critical to have clearly defined customers and products that will benefit from it rather than building in a vacuum. We caution against layered platform teams that simply preserve existing technology silos but apply the “platform team” label as well as against ticket-driven platform operating models. We’re still big fans of using concepts from Team Topologies as we think about how best to organize platform teams. We consider platform engineering product teams to be a standard approach and a significant enabler for high-performing IT.

May 2020

Trial

Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk.

The adoption of cloud and DevOps — while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure — also has constrained teams that lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams maintain an internal platform that enables delivery teams to deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform. If you’re wondering how to best set up platform teams, we’ve been using the concepts from Team Topologies to split platform teams in our projects into Enabling Teams, core “platform within a platform” teams and Stream-aligned Teams.

Nov 2017

Assess

Worth exploring with the goal of understanding how it will affect your enterprise.

The adoption of cloud and DevOps, while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure, also has constrained teams who lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams operate an internal platform which enables delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.

Mar 2017

Assess

Worth exploring with the goal of understanding how it will affect your enterprise.

The adoption of cloud and DevOps, while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure, also has constrained teams who lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams operate an internal platform which enables delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.