Technology Radar | An opinionated guide to technology frontiers

Download the Technology Radar Volume 24

Themes for this edition

Increasingly, organizations are adopting a “platform team” concept: set up a dedicated group that creates and supports internal platform capabilities, then use those capabilities to accelerate application development, reduce operational complexity, and improve time to market.

Consolidated Convenience over Best in Class

We’ve seen a rise — particularly in the cloud space — of developer-facing tool integration, with the aggregation of tools for artifact repositories, source control, CI/CD pipelines, wikis, and others. These consolidated tool stacks promise greater convenience for developers as well as less churn. But the set of tools rarely represent the best possible choice.

Perennially “Too Complex to Blip”

Many of the complex topics we discuss for the Radar end up being classified “TCTB — too complex to blip”. And often, the topics recur perennially; these include monorepos, orchestration guidelines for distributed architectures and branching models. Like many topics in software development, too many trade-offs exist to allow clear, unambiguous advice.

Discerning the Context for Architectural Coupling

One topic we discuss at nearly every meeting is the appropriate level of coupling in software architecture, between microservices, components, API gateways, integration hubs, frontends, and so on...pretty much everywhere two pieces of software might connect. But there is no single right answer: these decisions must be made on a case-by-case basis rather than seeking a generic but inadequate solution.

Platform Teams Drive Speed to Market

Increasingly, organizations are adopting a platform team concept: set up a dedicated group that creates and supports internal platform capabilities — cloud native, continuous delivery, modern observability, AuthZ/N patterns, service mesh, and so on — then use those capabilities to accelerate application development, reduce operational complexity and improve time to market. This growing maturity is welcome and we first featured this technique in the Radar in 2017. But with increasing maturity, we're also discovering antipatterns that organizations should avoid. For example, “one platform to rule them all” may not be optimal, “big platform up front” may take years to deliver value and “build it and they will come” might end up as a wasted effort. Instead, using a product-thinking approach can help you clarify what each of your internal platforms should provide, depending on its customers. Companies that put their platform teams behind a ticketing system like an old-school operations silo find the same disadvantages of misaligned prioritization: slow feedback and response, resource allocation contention and other well-known problems caused by the silo. We've also seen several new tools and integration patterns for teams and technologies emerge, allowing more effective partitioning of both.

Consolidated Convenience over Best in Class

As engineering practices that feature automation, scale and other modern goals become more commonplace with development teams, we see corresponding developer-facing tool integration on many platforms, particularly in the cloud space. For example, artifact repositories, source control, CI/CD pipelines, wikis, and similar tools were usually hand-picked by development teams and stitched together à la carte. Now, delivery platforms such as Azure DevOps and ecosystems such as GitHub have subsumed many of these tool categories. While the level of maturity varies across platform offerings, the appeal of a “one-stop shop” for delivery tooling is undeniable. Overall, it seems that the trade-off lies with having consolidated tool stacks offer greater developer convenience and less churn, but the set of tools rarely represents the best possible.

Perennially “Too Complex to Blip”

In Radar nomenclature, the final status after discussion for many complex topics is “TCTB — too complex to blip”: items that defy classification because they offer a number of pros and cons, a high amount of nuance as to the applicability of the advice or tool or other reasons that prevent us from summarizing our opinions in a few sentences. Frequently, these topics go on to articles, podcasts, and other non-Radar destinations. Some of our richest conversations center on these topics: they're important but complex, preventing a single succinct point of view. Numerous topics recur meeting after meeting — and, critically, with several of our client engagements — that eventually fall to TCTB, including monorepos, orchestration guidelines for distributed architectures and branching models, among others. For those who wonder why these important topics don’t make it into the Radar, it’s not for lack of awareness or desire on our part. Like many topics in software development, too many trade-offs exist to allow clear, unambiguous advice. We sometimes do find smaller pieces of the larger topics that we can offer advice on that do make it in the Radar, but the larger topics remain perpetually too nuanced and unsettled for the Radar.

Discerning the Context for Architectural Coupling

A topic that recurs virtually every meeting (see “Perennially 'Too Complex to Blip'”) is the appropriate level of coupling in software architecture between microservices, components, API gateways, integration hubs, frontends, and so on . . . pretty much everywhere two pieces of software might connect, architects and developers struggle finding the correct level of coupling — much common advice encourages extreme decoupling, but that makes building workflows difficult. Coupling in architecture touches on many important considerations: how things are wired, understanding the inherent semantic coupling within each problem domain, how things call one another, or how transactionality works (sometimes in combination with other tricky features like scalability). Software can’t exist without some level of coupling outside of singular monolithic systems; arriving at the right set of trade-offs to determine the types and levels of coupling becomes a critical skill with modern architectures. We do see specific bad practices such as generating code for client libraries and good practices such as the judicious use of the BFF patterns. However, general advice in this realm is useless and silver bullets don’t exist. Invest time and effort in understanding the factors at play when making these decisions on a case-by-case basis rather than seeking a generic but inadequate solution.