Enable javascript in your browser for better experience. Need to know to enable it? Go here.


Adopt ?

  • To measure software delivery performance, more and more organizations are turning to the four key metrics as defined by the DORA research program: change lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. This research and its statistical analysis have shown a clear link between high delivery performance and these metrics; they provide a great leading indicator for how a team, or even a whole delivery organization, is doing.

    We're still big proponents of these metrics, but we've also learned some lessons since we first started monitoring them. And we're increasingly seeing misguided measurement approaches with tools that help teams measure these metrics based purely on their continuous delivery (CD) pipelines. In particular when it comes to the stability metrics (MTTR and change fail percentage), CD pipeline data alone doesn't provide enough information to determine what a deployment failure with real user impact is. Stability metrics only make sense if they include data about real incidents that degrade service for the users.

    And as with all metrics, we recommend to always keep in mind the ultimate intention behind a measurement and use them to reflect and learn. For example, before spending weeks to build up sophisticated dashboard tooling, consider just regularly taking the DORA quick check in team retrospectives. This gives the team the opportunity to reflect on which capabilities they could work on to improve their metrics, which can be much more effective than overdetailed out-of-the-box tooling.

  • 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.

  • We keep hearing about enterprises finding their security badly compromised due to an overreliance on the "secure" network perimeter. Once this external perimeter is breached, internal systems prove to be poorly protected with attackers quickly and easily able to deploy automated data extraction tools and ransomware attacks that all too often remain undetected for long periods. This leads us to recommend zero trust architecture (ZTA) as a now sensible default.

    ZTA is a paradigm shift in security architecture and strategy. It’s based on the assumption that a network perimeter is no longer representative of a secure boundary and no implicit trust should be granted to users or services based solely on their physical or network location. The number of resources, tools and platforms available to implement aspects of ZTA keeps growing and includes enforcing policies as code based on the least privilege and as-granular-as-possible principles and continuous monitoring and automated mitigation of threats; using service mesh to enforce security control application-to-service and service-to-service; implementing binary attestation to verify the origin of the binaries; and including secure enclaves in addition to traditional encryption to enforce the three pillars of data security: in transit, at rest and in memory. For introductions to the topic, consult the NIST ZTA publication and Google's white paper on BeyondProd.

Trial ?

  • Although it’s been around for a while, we're seeing more and more use cases where using the CBOR specification for data interchange makes sense — especially in environments containing multiple types of applications communicating with one another: service to service, browser to service, and so on. One thing we've found useful with Borer, a Scala implementation of a CBOR encoder/decoder, is the ability for clients to negotiate content between the binary representation and plain old JSON format. It's quite useful to have a text version viewable in a browser as well as the concise binary format. We foresee CBOR/JSON bilingual protocols picking up in popularity with the continuing rise of IoT and edge computing and other situations where the environment is tightly constrained.

  • Increasingly, we see a mismatch between what data-driven organizations want to achieve and what the current data architectures and organizational structures allow. Organizations want to embed data-driven decision-making, machine learning and analytics into many aspects of their products and services and how they operate internally; essentially they want to augment every aspect of their operational landscape with data-driven intelligence. Yet, we still have a ways to go before we can embed analytical data, access to it and how it is managed into the business domains and operations. Today, every aspect of managing analytical data is externalized outside of the operational business domains to the data team and to the data management monoliths: data lakes and data warehouses. Data mesh is a decentralized sociotechnical approach to remove the dichotomy of analytical data and business operation. Its objective is to embed sharing and using analytical data into each operational business domain and close the gap between the operational and analytical planes. It's founded on four principles: domain data ownership, data as a product, self-serve data platform and computational federated governance.

    Our teams have been implementing the data mesh architecture; they've created new architectural abstractions such as the data product quantum to encapsulate the code, data and policy as an autonomous unit of analytical data sharing embedded into operational domains; and they've built self-serve data platform capabilities to manage the lifecycle of data product quanta in a declarative manner as described in Data Mesh. Despite our technical advances, we're still experiencing friction using the existing technologies in a data mesh topology, not to mention the resistance of business domains to embrace sharing and using data as a first-class responsibility in some organizations.

  • Living documentation, which comes from the behavior-driven development (BDD) community, is often considered a privilege for those well-maintained codebases with executable specifications. We found that this technique can also be applied to legacy systems. Lack of business knowledge is a common obstacle encountered by teams when doing system modernization. Code is usually the only trustworthy source of truth because staff turnover and existing documentation are outdated. Therefore it's very important to reestablish the association between the documentation and the code and spread the business knowledge among the team when we take over a legacy system. In practice, we would first try to go to the codebase and deepen our understanding of the business through simple cleanup and safe refactoring. During the process, we'll need to add annotations to the code so that we're able to automatically generate living documentation later. This is very different from doing BDD in green-field projects, but it's a good start in legacy systems. Based on the generated documentation, we would try to convert some of the specs into executable high-level automation tests. Do this iteratively, and eventually you could get living documentation in legacy systems that is closely associated with the code and partially executable.

  • Since introducing them in the Radar in 2016, we've seen widespread adoption of micro frontends for web UIs. Recently, however, we've seen projects extend this architectural style to include micro frontends for mobile applications as well. When the application becomes sufficiently large and complex, it becomes necessary to distribute the development over multiple teams. This presents the challenge of maintaining team autonomy while integrating their work into a single app. Some teams write their own frameworks to enable this development style, and in the past we've mentioned Atlas and Beehive as possible ways to simplify the problem of integrating multiteam app development. More recently, we've seen teams using React Native to accomplish the same thing. Each React Native micro frontend is kept in its own repository where it can be built, tested and deployed separately. The team responsible for the overall application can then aggregate those micro frontends built by different teams into a single released app.

  • We continue to see many teams working and collaborating remotely; for these teams remote mob programming is a technique that is well worth trying. Remote mob programming allows teams to quickly "mob" around an issue or piece of code without the physical constraints of only being able to fit so many people around a pairing station. Teams can quickly collaborate on an issue or piece of code using their video conferencing tool of choice without having to connect to a big display, book a physical meeting room or find a whiteboard.

  • With the increased use of remote distributed teams, one of the things we hear people have missed having is the physical team wall. This is a single place where all the various story cards, tasks, status and progress can be displayed, acting as an information radiator and hub for the team. Often the wall was an integration point with the actual data being stored in different systems. As teams have become remote, they've had to revert to looking into the individual source systems and getting an "at a glance" view of a project has become very difficult. A single team remote wall is a simple technique to reintroduce the team wall virtually. While there might be some overhead in keeping this up-to-date, we feel the benefits to the team are worth it. For some teams, updating the physical wall formed part of the daily "ceremonies" the team did together, and the same can be done with a remote wall.

  • A system's architecture mimics organizational structure and its communication. It's not big news that we should be intentional about how teams interact — see, for instance, the Inverse Conway Maneuver. Team interaction is one of the variables for how fast and how easily teams can deliver value to their customers. We were happy to find a way to measure these interactions; we used the Team Topologies author's assessment which gives you an understanding of how easy or difficult the teams find it to build, test and maintain their services. By measuring team cognitive load, we could better advise our clients on how to change their teams' structure and evolve their interactions.

Assess ?

  • Many augmented reality (AR) applications depend on knowing the location and orientation of the user's device. The default is to use GPS-based solutions, but spatial anchors, a newer technique to address this requirement, are also worth considering. Spatial anchors work with the image recorded by the device's camera, using image features and their relative position in 3D space to recognize a real-world location. For this location a corresponding anchor is created in the AR space. Although spatial anchors can't replace all GPS and marker-based anchors, they do provide more accuracy than most GPS-based solutions and are more resilient to different viewing angles than marker-based anchors. Our experience is currently limited to Google's Cloud Anchors for Android, which worked well for us. Somewhat uncharacteristically Google also offers Cloud Anchors for iOS and with Azure Spatial Anchors Microsoft supports even more platforms.

  • After successfully launching their email application HEY as a server-side application, Basecamp reported migrating its flagship product, Basecamp 3, to Hotwire this summer. As organizations increasingly default to single-page applications (SPAs) for new web development, we continue to be excited by Hotwire swimming against the stream. Unlike SPAs, Hotwire applications keep most of the logic and navigation on the server, relying on a minimal amount of browser JavaScript. Hotwire modularizes HTML pages into a set of components (called Turbo Frames) that can be lazy loaded, provide independent contexts and send HTML updates to those contexts based on user actions. SPAs offer undeniable user responsiveness, but the simplicity of traditional server-side web programming combined with modern browser tooling provides a refreshing take on balancing developer effectiveness and user responsiveness.

  • We're seeing increasing use of the Kubernetes Operator pattern for purposes other than managing applications deployed on the cluster. Using the operator pattern for nonclustered resources takes advantage of custom resource definitions and the event-driven scheduling mechanism implemented in the Kubernetes control plane to manage activities that are related to yet outside of the cluster. This technique builds on the idea of Kube-managed cloud services and extends it to other activities, such as continuous deployment or reacting to changes in external repositories. One advantage of this technique over a purpose-built tool is that it opens up a wide range of tools that either come with Kubernetes or are part of the wider ecosystem. You can use commands such as diff, dry-run or apply to interact with the operator's custom resources. Kube's scheduling mechanism makes development easier by eliminating the need to orchestrate activities in the proper order. Open-source tools such as Crossplane, Flux and ArgoCD take advantage of this technique and we expect to see more of these emerge over time.

  • We're seeing continued innovation in remote collaboration tools. The new Huddles feature in Slack provides a Discord-like experience of persistent audio calls that users can jump in and out of at any time. Gather provides a creative way to emulate a virtual office with avatars and video. IDEs provide direct collaboration features for pairing and debugging: we've previously blipped Visual Studio Live Share and included JetBrains Code With Me to the list in this edition. As tools continue to evolve modalities for collaboration in addition to video conferencing, we're increasingly seeing teams participating in remote spontaneous huddling, recreating the spontaneity of informal conversations over the intentionality of scheduling a Zoom or Microsoft Teams meeting. We don't expect to ever fully recreate the richness of face-to-face communication through digital tools, but we do see improved remote team effectiveness by giving teams multiple channels of collaboration rather than relying on one toolchain for everything.

  • In May 2021, the U.S. White House published its Executive Order on Improving the Nation's Cybersecurity. The document puts forward several technical mandates that relate to items we've featured in past Radars, such as zero trust architecture and automated compliance scanning using security policy as code. Much of the document is devoted to improving the security of the software supply chain. One item in particular that caught our attention was the requirement that government software should contain a machine-readable Software Bill of Materials (SBOM), defined as "a formal record containing the details and supply chain relationships of various components used in building software." In other words, it should detail not just the components shipped but also the tools and frameworks used to deliver the software. This order has the potential to usher in a new era of transparency and openness in software development. This will undoubtedly have an impact on those of us who produce software for a living. Many, if not all software products produced today contain open-source components or employ them in the build process. Often, the consumer has no way of knowing which version of which package might have an impact on the security of their product. Instead they must rely on the security alerts and patches provided by the retail vendor. This executive order will ensure that an explicit description of all components is made available to consumers, empowering them to implement their own security controls. And since the SBOM is machine-readable, those controls can be automated. We sense that this move also represents a shift toward embracing open-source software and practically addressing both the security risks and benefits that it provides.

Hold ?

  • Some organizations seem to think peer review equals pull request; they've taken the view that the only way to achieve a peer review of code is via a pull request. We've seen this approach create significant team bottlenecks as well as significantly degrade the quality of feedback as overloaded reviewers begin to simply reject requests. Although the argument could be made that this is one way to demonstrate code review "regulatory compliance," one of our clients was told this was invalid since there was no evidence the code was actually read by anyone prior to acceptance. Pull requests are only one way to manage the code review workflow; we urge people to consider other approaches, especially where there is a need to coach and pass on feedback carefully.

  • We continue to perceive production data in test environments as an area for concern. Firstly, many examples of this have resulted in reputational damage, for example, where an incorrect alert has been sent from a test system to an entire client population. Secondly, the level of security, specifically around protection of private data, tends to be less for test systems. There is little point in having elaborate controls around access to production data if that data is copied to a test database that can be accessed by every developer and QA. Although you can obfuscate the data, this tends to be applied only to specific fields, for example, credit card numbers. Finally, copying production data to test systems can break privacy laws, for example, where test systems are hosted or accessed from a different country or region. This last scenario is especially problematic with complex cloud deployments. Fake data is a safer approach, and tools exist to help in its creation. We do recognize there are reasons for specific elements of production data to be copied, for example, in the reproduction of bugs or for training of specific ML models. Here our advice is to proceed with caution.

techniques quadrant with radar rings Adopt Trial Assess Hold Adopt Trial Assess Hold
Moved in/out
No change

Unable to find something you expected to see?


Each edition of the Radar features blips reflecting what we came across during the previous six months. We might have covered what you are looking for on a previous Radar already. We sometimes cull things just because there are too many to talk about. A blip might also be missing because the Radar reflects our experience, it is not based on a comprehensive market analysis.

Unable to find something you expected to see?


Each edition of the Radar features blips reflecting what we came across during the previous six months. We might have covered what you are looking for on a previous Radar already. We sometimes cull things just because there are too many to talk about. A blip might also be missing because the Radar reflects our experience, it is not based on a comprehensive market analysis.


Download Technology Radar Volume 25

English | Español | Português | 中文


Stay informed about technology


Subscribe now

Visit our archive to read previous volumes