In a recent article, my colleague Kelsey Beyer pointed out that transforming your operating model is just as important as the technology when introducing data mesh in an organization. Although, as Kelsey notes, organizations often sideline making the necessary changes to their operating model because of a perception that doing so is too complex, such changes are, in fact, critical to the success of data mesh. If done correctly, changing the operating model in parallel to the technology can even make it easier to move to the decentralized way of working data mesh requires.
That said, while the aim of data mesh is decentralization, some degree of centralization is still necessary if data mesh is to deliver for an organization. While the delivery of data and data products will sit within the respective domains closest to the source of data, the platform delivery remains centralized — this means the organization can leverage economies of scale through the centralized platform, while also making it easier to create value by decentralizing the delivery of specific use cases.
Striking a balance between decentralization and centralization inevitably comes with a number of challenges. Some of the most typical include changes in ownership and end-to-end responsibilities of data product teams, setting priorities to limit the amount of work-in-progress, and the new client-like relationship data product teams begin to have with internal consumers.
One of the mechanisms that can really help overcome these challenges is a transformation office. A transformation office can help to manage the change program and plays a crucial role in guiding the organization in tackling the challenges mentioned above. It’s a centralized body, set up to coordinate relevant stakeholders. In this blog post I’ll explain some of the things it does and how it helps tackle some of the most common issues that come from a data mesh implementation.