The classic data management architectures make it difficult to discover, understand, and fetch quality analytical data. This is especially acute in the case of data lakes.

The data as a product principle calls for treating the analytical data as a first-class citi‐ zen. Instead of the analytical systems having to get the operational data from dubious sources (internal database, logfiles, etc.), in a data mesh–based system the bounded contexts serve the analytical data through well-defined output ports, as shown in Figure 16-13.

Figure 16-13. Polyglot data endpoints exposing the analytical data to the consumers

Analytical data should be treated the same as any public API:

• It should be easy to discover the necessary endpoints: the data output ports.

• The analytical endpoints should have a well-defined schema describing the served data and its format.

• The analytical data should be trustworthy, and as with any API, it should have defined and monitored service-level agreements (SLAs).

• The analytical model should be versioned as a regular API and correspondingly manage integration-breaking changes in the model.

Furthermore, since the analytical data is treated as a product, it has to address the needs of its consumers. The bounded context’s team is in charge of ensuring that the resultant model addresses the needs of its consumers. Contrary to the data warehouse and data lake architectures, with data mesh, accountability for data quality is a top- level concern.

The goal of the distributed data management architecture is to allow the fine-grained analytical models to be combined to address the organization’s data analysis needs. For example, if a BI report should reflect data from multiple bounded contexts, it should be able to easily fetch their analytical data if needed, apply local transforma‐ tions, and produce the report.

Finally, different consumers may require the analytical data in different forms. Some may prefer to execute SQL queries, others to fetch analytical data from an object stor‐ age service, and so on. As a result, the data products have to be polyglot, serving the data in formats that suit different consumers’ needs.

To implement the data as a product principle, product teams require adding data- oriented specialists. That’s the missing piece in the cross-functional teams puzzle, which traditionally includes only specialists related to the operational systems.