Techniques Thoughtworks Technology Radar face high cost of integration. Moreover, its adoption remains limited to sections of larger organizations and technology vendors are distracting the organizations from the hard socio aspects of data mesh — decentralized data ownership and a federated governance operating model. These ideas are explored in Data Mesh, Delivering Data-Driven Value at Scale, which guides practitioners, architects, technical leaders and decision makers on their journeys from traditional big data architecture to data mesh. It provides a complete introduction to data mesh principles and its constituents; it covers how to design a data mesh architecture, guide and execute a data mesh strategy and navigate organizational design to a decentralized data ownership model. The goal of the book is to create a new framework for deeper conversations and lead to the next phase in maturity of data mesh. 4. Definition of production readiness Trial In an organization that practices the “you build it, you run it” principle, a definition of production readiness (DPR) is a useful technique to support teams in assessing and preparing the operational readiness of new services. Implemented as a checklist or a template, a DPR gives teams guidance on what to think about and consider before they bring a new service into production. While DPRs do not define specific service-level objectives (SLOs) to fulfill (those would be hard to define one-size- fits-all), they remind teams what categories of SLOs to think of, what organizational standards to comply with and what documentation is required. DPRs provide a source of input that teams turn into respective product-specific requirements around, for example, observability and reliability, to feed into their product backlogs. DPRs are closely related to Google’s concept of a production readiness review (PRR). In organizations that are too small to have a dedicated site reliability engineering team, or who are concerned that a review board process could negatively impact a team’s flow to go live, having a DPR can at least provide some guidance and document the agreed-upon criteria for the organization. For highly critical new services, extra scrutiny on fulfilling the DPR can be added via a PRR when needed. 5. Documentation quadrants Trial Writing good documentation is an overlooked aspect of software development that is often left to the last minute and done in a haphazard way. Some of our teams have found documentation quadrants a handy way to ensure the right artifacts are being produced. This technique classifies artifacts along two axes: The first axis relates to the nature of the information, practical or theoretical; the second axis describes the context in which the artifact is used, studying or working. This defines four quadrants in which artifacts such as tutorials, how-to guides or reference pages can be placed and understood. This classification system not only ensures that critical artifacts aren’t overlooked but also guides the presentation of the content. We’ve found this particularly useful for creating onboarding documentation that brings developers up to speed quickly when they join a new team. © Thoughtworks, Inc. All Rights Reserved. 13