An Opinionated Guide to Technology Frontiers
Total Page:16
File Type:pdf, Size:1020Kb
TECHNOLOGY RADAR An opinionated guide to technology frontiers Volume 24 #TWTechRadar thoughtworks.com/radar The Technology Advisory Board (TAB) is a group of 20 senior technologists at Thoughtworks. The TAB meets twice a year face-to-face and biweekly by phone. Its primary role is to be an advisory group for Thoughtworks CTO, Contributors Rebecca Parsons. The Technology Radar is prepared by the The TAB acts as a broad body that can look at topics that affect technology and technologists at Thoughtworks. With the ongoing global pandemic, we Thoughtworks Technology Advisory Board once again created this volume of the Technology Radar via a virtual event. Rebecca Martin Fowler Bharani Birgitta Brandon Camilla Cassie Parsons (CTO) (Chief Scientist) Subramaniam Böckeler Byars Crispim Shum Erik Evan Fausto Hao Ian James Lakshminarasimhan Dörnenburg Bottcher de la Torre Xu Cartwright Lewis Sudarshan Mike Neal Perla Rachel Scott Shangqi Zhamak Mason Ford Villarreal Laycock Shaw Liu Dehghani TECHNOLOGY RADAR | 2 © Thoughtworks, Inc. All Rights Reserved. About the Radar Thoughtworkers are passionate about technology. We build it, research it, test it, open source it, write about it and constantly aim to improve it — for everyone. Our mission is to champion software excellence and revolutionize IT. We create and share the Thoughtworks Technology Radar in support of that mission. The Thoughtworks Technology Advisory Board, a group of senior technology leaders at Thoughtworks, creates the Radar. They meet regularly to discuss the global technology strategy for Thoughtworks and the technology trends that significantly impact our industry. The Radar captures the output of the Technology Advisory Board’s discussions in a format that provides value to a wide range of stakeholders, from developers to CTOs. The content is intended as a concise summary. We encourage you to explore these technologies. The Radar is graphical in nature, grouping items into techniques, tools, platforms and languages & frameworks. When Radar items could appear in multiple quadrants, we chose the one that seemed most appropriate. We further group these items in four rings to reflect our current position on them. For more background on the Radar, see thoughtworks.com/radar/faq. TECHNOLOGY RADAR | 3 © Thoughtworks, Inc. All Rights Reserved. New Moved in/out Radar at No change Our Radar is forward looking. To make a glance room for new items, we fade items that haven’t moved recently, which isn’t a reflection on their value but rather on The Radar is all about tracking interesting our limited Radar real estate. things, which we refer to as blips. We organize the blips in the Radar using two categorizing elements: quadrants and rings. The quadrants represent different kinds of blips. The rings indicate what stage in an adoption lifecycle we think they should be in. Hold Assess TrialTAdoptAdopt rial Assess Hold A blip is a technology or technique that plays a role in software development. Blips Adopt are things that are “in motion” — that is we find their position in the Radar is changing We feel strongly that the industry should — usually indicating that we’re finding be adopting these items. We use them increasing confidence in them as they move when appropriate in our projects. through the rings. Trial Worth pursuing. It’s important to understand how to build up this capability. Enterprises can try this technology on a project that can handle the risk. Assess Worth exploring with the goal of understanding how it will affect your enterprise. Hold Proceed with caution. TECHNOLOGY RADAR | 4 © Thoughtworks, Inc. All Rights Reserved. Themes for this edition Platform Teams Drive Consolidated Convenience Perennially “Too Discerning the Context for Speed to Market over Best in Class Complex to Blip” Architectural Coupling Increasingly, organizations are adopting a As engineering practices that feature In Radar nomenclature, the final status A topic that recurs virtually every meeting platform team concept: set up a dedicated automation, scale and other modern after discussion for many complex topics (see “Perennially ‘Too Complex to Blip’”) group that creates and supports internal goals become more commonplace with is “TCTB — too complex to blip”: items is the appropriate level of coupling platform capabilities — cloud native, development teams, we see corresponding that defy classification because they in software architecture between continuous delivery, modern observability, developer-facing tool integration on offer a number of pros and cons, a high microservices, components, API gateways, AuthZ/N patterns, service mesh, and many platforms, particularly in the cloud amount of nuance as to the applicability integration hubs, frontends, and so on... so on — then use those capabilities to space. For example, artifact repositories, of the advice or tool or other reasons pretty much everywhere two pieces of accelerate application development, reduce source control, CI/CD pipelines, wikis, and that prevent us from summarizing our software might connect, architects and operational complexity and improve similar tools were usually hand-picked by opinions in a few sentences. Frequently, developers struggle finding the correct time to market. This growing maturity development teams and stitched together these topics go on to articles, podcasts, level of coupling — much common advice is welcome and we first featured this à la carte. Now, delivery platforms such and other non-Radar destinations. Some encourages extreme decoupling, but technique in the Radar in 2017. But with as Azure DevOps and ecosystems such of our richest conversations center that makes building workflows difficult. increasing maturity, we’re also discovering as GitHub have subsumed many of these on these topics: they’re important but Coupling in architecture touches on many antipatterns that organizations should tool categories. While the level of maturity complex, preventing a single succinct important considerations: how things avoid. For example, “one platform to rule varies across platform offerings, the appeal point of view. Numerous topics recur are wired, understanding the inherent them all” may not be optimal, “big platform of a “one-stop shop” for delivery tooling meeting after meeting — and, critically, semantic coupling within each problem up front” may take years to deliver value is undeniable. Overall, it seems that the with several of our client engagements domain, how things call one another or and “build it and they will come” might trade-off lies with having consolidated tool — that eventually fall to TCTB, including how transactionality works (sometimes end up as a wasted effort. Instead, using stacks offer greater developer convenience monorepos, orchestration guidelines for in combination with other tricky features a product-thinking approach can help and less churn, but the set of tools rarely distributed architectures and branching like scalability). Software can’t exist you clarify what each of your internal represents the best possible. models, among others. For those who without some level of coupling outside of platforms should provide, depending on wonder why these important topics don’t singular monolithic systems; arriving at its customers. Companies that put their make it into the Radar, it’s not for lack the right set of trade-offs to determine platform teams behind a ticketing system of awareness or desire on our part. Like the types and levels of coupling becomes like an old-school operations silo find many topics in software development, a critical skill with modern architectures. the same disadvantages of misaligned too many trade-offs exist to allow clear, We do see specific bad practices such as prioritization: slow feedback and response, unambiguous advice. We sometimes do generating code for client libraries and resource allocation contention and other find smaller pieces of the larger topics that good practices such as the judicious use well-known problems caused by the we can offer advice on that do make it in of the BFF patterns. However, general silo. We’ve also seen several new tools the Radar, but the larger topics remain advice in this realm is useless and silver and integration patterns for teams and perpetually too nuanced and unsettled for bullets don’t exist. Invest time and effort technologies emerge, allowing more the Radar. in understanding the factors at play when effective partitioning of both. making these decisions on a case-by-case basis rather than seeking a generic but inadequate solution. TECHNOLOGY RADAR | 5 © Thoughtworks, Inc. All Rights Reserved. Techniques Tools Adopt Adopt 1. API expand-contract 52. Sentry The Radar 2. Continuous delivery for machine learning (CD4ML) 3. Design systems Trial 4. Platform engineering product teams 53. axe-core 5. Service account rotation approach 54. dbt 55. esbuild Trial 56. Flipper 6. Cloud sandboxes 57. Great Expectations 7. Contextual bandits 58. k6 8. Distroless Docker images 59. MLflow 60. OR-Tools 33 9. Ethical Explorer 10. Hypothesis-driven legacy renovation 61. Playwright 62. Prowler 32 11. Lightweight approach to RFCs 12. Simplest possible ML 63. Pyright 31 13. SPA injection 64. Redash 25 26 68 14. Team cognitive load 65. Terratest 24 69 70 71 66. Tuple 80 15. Tool-managed Xcodeproj 23 67. Why Did You Render 30 16. UI/BFF shared types 72 73 Assess 22 Assess 17. Bounded low-code platforms 68. Buildah and Podman 16 54 74 29 21 15 57 18. Decentralized identity 69. GitHub Actions 58 70. Graal Native Image 12 13 53 56 19. Deployment drift radiator 75 20. Homomorphic encryption 71. HashiCorp Boundary 20 11 55 14 60 21. Hotwire 72. imgcook 28 59 76 73. Longhorn 10 61 22. Import maps for micro frontends 19 77 23. Open Application Model (OAM) 74. Operator Framework 5 63 24. Privacy-focused web analytics 75. Recommender 62 76. Remote - WSL 9 4 25. Remote mob programming 18 78 27 64 26. Secure multiparty computing 77. Spectral 3 78. Yelp detect-secrets 7 8 66 52 65 79 79. Zally 17 6 2 Hold 1 67 27.