# Implementing Federated Governance in Data Mesh Architecture +
## 1 Introduction  
The majority of modern organizations that deal with data processing are constantly facing the challenges of big data to some extent. These challenges include: volume, velocity, veracity, variety, and value of the processed data [1]. To cope with these, we distinguish two important aspects used by organizations, namely _data platforms_ and _organizational structure_. The platform serves the utility purpose, which is facilitating operations over data assets. Meanwhile, the org structure defines the user's responsibilities, roles, and rights needed to perform the necessary operations. In this article, we focus specifically on the data platform aspect that is required for implementing the decentralized platform architecture. _Data warehouses_[2] are considered to be the first type of platform to deal with big data. Being oriented to managing the structured data, they provide tools for business schema enforcement on the collected data, user query processing engines, and analytical online data processing (OLAP). This kind of solution is widely applied today, but it may struggle with such big data requirements as velocity and variety of data. To overcome this, _data lakes_ were proposed as a second type of platform [3]. They implement a _schema-on-read_ functionality, which is opposite to schema-on-write seen in the data warehouses. In the data warehouse architecture, incoming data (application telemetry, operational database changes, etc.) are transformed during the ingestion phase. In the data lake architecture, we keep the ingested data in their raw format, usually by using large object storage. The data processing is postponed until the querying phase, when the value extraction is performed by respective professionals, like data scientists. This facilitates thespeed (velocity) of batch and real-time acquisition directly from the data sources to the support of a variety of data types, including structured and unstructured information. The synergy of these two platforms was introduced in [4]. _Data lakehouses_ preserve the benefits of both solutions. On one side, analytical data pre-computation enables fast business queries (e.g., business intelligence cubes); on the other side, raw data storage enables the discovery of valuable data insights in the future. Even with the strong support of distributed technologies, all these three kinds of platforms are designed and developed as centralized solutions from a logical point of view. The centralization comes from the fact that usually, data value extraction is performed by analytical teams that are detached from the operational activities of the company. Data scientists and engineers are gathered under a single data division, tasked with performance evaluation, and serve as a mediator between the business people and developers. Nonetheless, with the growing popularity of decentralized systems in recent years, a new data platform architecture called Data Mesh [5] has emerged. Building on the lasting works around the domain-driven design [6] and data markets [7], it manifests four core principles:  
* Distributed data domains;
* Data-as-a-product;
* Self-serve data infrastructure;
* Federated computational governance. In contrast to the previous platform types that envision the centralization of the data ownership and value extractions under the command of a dedicated team, the mesh architecture aims to remove the segmentation of the holistic business domains across the operational and analytical teams. The core component of any big data platform is a metadata management (MDM) system. This makes it possible to account for, link, comprehend, integrate, and control the existing data assets. MDM can be seen as an essential part of the federated governance [8]. From a high-level perspective, we can split the last data mesh principle into two modules:  
1. Definition, access, and collaboration on schemes, semantic knowledge, lineage, etc. ;
2. Tools to automatically enforce security, transparency, legal policies, etc.