Technology Radar

Machine learning (ML) was once a realm reserved for only a lucky few who had the tools and resources to build cool things. Fortunately, we see a gradual mainstreaming of ML as computational power grows on devices of all sizes, open-source tools arrive and more stringent requirements and awareness around privacy and personalized information all converge to create a burgeoning ecosystem. Techniques such as federated machine learning allow for ML models that provide privacy for sensitive information. The field of TinyML allows models to execute on resource-constrained devices, moving inference to the edge, which both frees resources and improves privacy for sensitive data. Feature Stores provide analogous benefits to the Model-View-Controller design pattern for application development, allowing a cleaner separation of concerns between data curation, model training and inference. Publicly available models such as Stable Diffusion highlight both the amazing capabilities of machine learning and the concerns around source data and ethics. ML components are also easier than ever to wire together, making it possible to build ML experiences and solutions with creative composition of custom business models and highly capable generic models. We applaud the new capabilities in this space and eagerly await future advancements.

The word "platform" continues to be one of the most used words during our Radar meetings because the concept is so pervasive in the industry. It pops up in many different manifestations, including business or domain-focused platforms but also infrastructure or developer experience platforms. Fundamentally, the root cause of many of the problems and disappointments that organizations experience with all platforms is the failure to properly treat them as products. For example, many platforms intended to be consumed by developers lack the user research and contextual analysis we expect in other types of products. Platform owners need to validate their assumptions about developers’ needs and respond to actual usage patterns. And like any good product, a platform needs ongoing support. It must evolve and adapt in response to the developer's changing needs. Additionally, roles like project managers and business analysts often have different scopes than in traditional applications. The "platform as a product" metaphor only works when fully embraced as a practice rather than a trendy phrase.

As we all too painfully know, centralization of any kind opens up the possibility of constriction, bottlenecks or unnecessary exposure. Thus, we constantly strive to find novel ways to break centralized coupling points, highlighted by several blips in our Radar. Based on research into conflict-free replicated data types (CRDTs), which enable data-based applications without a centralized database, the technique of local-first software/applications encourages developers to think about building around peer-to-peer data rather than using a centralized database. Moving data ownership to the edges also allows developers to take advantage of increased capabilities on devices, as showcased in the Mainstreaming of ML theme. For example, many capabilities such as facial recognition can occur on the edge, keeping the underlying data on the device forever.

Software engineers have learned the value of structuring the architecture of an application primarily around domain concepts and business functionality. Technical concerns — a separation of UI from domain logic — are still important but play a secondary role. As mobile apps mature they often get larger, sometimes growing into so-called super apps, which comprise many services and can be seen as platforms in their own right. Apps that aren't quite as large but have picked up many capabilities over the years can usually be decomposed into modules, too, and companies find that mobile apps benefit from the same approach to modularity. Modular apps lend themselves to be written by multiple autonomous teams, which brings many well-documented benefits. Adding to the complexity is the requirement to deploy via an app store and the need to support native iOS and Android versions plus a web-based version, with subtle changes to accommodate each. We see better framework support for the unique tensions inherent in mobile development, but on the whole, despite the benefits, many organizations struggle to bring a modular approach to mobile development.