Techniques Thoughtworks Technology Radar 20. Miscellaneous platform teams Hold We previously featured platform engineering product teams in Adopt as a good way for internal platform teams to operate, thus enabling delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. Unfortunately we’re seeing the “platform team” label applied to teams dedicated to projects that don’t have clear outcomes or a well-defined set of customers. As a result, these miscellaneous platform teams, as we call them, struggle to deliver due to high cognitive loads and a lack of clearly aligned priorities as they’re dealing with a miscellaneous collection of unrelated systems. They effectively become just another general support team for things that don’t fit or that are unwanted elsewhere. We continue to believe platform engineering product teams focused around a clear and well-defined (internal) product offer a better set of outcomes. 21. Production data in test environments Hold 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. 22. SPA by default Hold We generally avoid putting blips in Hold when we consider that advice too obvious, including blindly following an architectural style without paying attention to trade-offs. However, the sheer prevalence of teams choosing a single-page application (SPA) by default when they need a website has us concerned that people aren’t even recognizing SPAs as an architectural style to begin with, instead immediately jumping into framework selection. SPAs incur complexity that simply doesn’t exist with traditional server-based websites: search engine optimization, browser history management, web analytics, first page load time, etc. That complexity is often warranted for user experience reasons, and tooling continues to evolve to make those concerns easier to address (although the churn in the React community around state management hints at how hard it can be to get a generally applicable solution). Too often, though, we don’t see teams making that trade- off analysis, blindly accepting the complexity of SPAs by default even when the business needs don’t justify it. Indeed, we’ve started to notice that many newer developers aren’t even aware of an alternative approach, as they’ve spent their entire career in a framework like React. We believe that many websites will benefit from the simplicity of server-side logic, and we’re encouraged by techniques like Hotwire that help close the gap on user experience. © Thoughtworks, Inc. All Rights Reserved. 18