Master

TechnologyRadar

An opinionated guide to technology frontiers
Volume 24

Themes for this edition

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.

Visit our archive to read previous editions

Subscribe. Stay informed.

We publish articles related to Technology Radar throughout the year

Thank you!

You have been subscribed to our Technology Radar content. Keep an eye on your inbox, we will be in touch soon.