Techniques Thoughtworks Technology Radar contains sensitive or personally identifiable information; users might be reluctant to share data or local data protection legislation may prevent us from moving data to a central location. Federated ML is a decentralized technique for training on a large and diverse set of data that allows the data to remain remote — for example, on a user’s device. Network bandwidth and the computational limitations of devices still present significant technical challenges, but we like the way federated ML leaves users in control of their own personal information. 9. Incremental developer platform Trial We’ve been writing about developer platforms and how to build them in almost every edition of the Radar since 2017. In the meantime, the Team Topologies book has also done a great job of describing the ideal of a platform that supports developers with “self-service APIs, tools, services and knowledge.” However, we often see teams shooting for too much of that platform vision too fast. Instead, building an incremental developer platform is key. Team Topologies recommends to always strive for what they call the “Thinnest Viable Platform” necessary at any given stage, where the first version could even be just a set of documentation on a wiki. The next increment could increase the service level by providing templates or allowing teams to create pull requests. Further increments could then introduce self-service APIs, but only if valuable. In short, even though we’ve cautioned against fully ticket-driven platform operating models, going from zero to self-service is the other extreme. Pace yourself, treat your platform as a product and build it up incrementally. 10. Micro frontends for mobile Trial 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 apps as well. When an app becomes sufficiently large and complex, it becomes necessary to distribute the development over multiple teams. This presents a number of challenges around team autonomy, repository structures and integration frameworks. In the past we’ve mentioned Atlas and BeeHive, but these frameworks failed to gain traction and are no longer in active development. More recent approaches include Tuist or the Swift Package Manager for integrating the work of multiple teams into a single app. But in our experience, teams often end up implementing their own framework for integration. While we definitely see a need for modularity in scaling up mobile development teams, the case for micro frontends is less certain. This is because while micro frontends imply a direct correspondence between teams and pages or components, this structure could end up blurring responsibilities for business domain contexts, thereby increasing team cognitive load. Our advice is to follow the basics of good, clean application design, embrace modularity when scaling up to multiple teams and adopt a micro frontend architecture only when the modules and the business domain are strongly aligned. 11. Observability for CI/CD pipelines Trial Observability practices have shifted the conversation from monitoring for well-understood problems to helping troubleshoot unknown problems in distributed systems. We’ve seen success taking that perspective outside of the traditional production environment by applying observability for CI/CD © Thoughtworks, Inc. All Rights Reserved. 14