Composable Enterprise
Think of your business data landscape as a flexible system that changes as your business does, not as a rigid machine. Interconnected AI/LLM and analytics data products form an ecosystem that lives and evolves, reconfiguring as the business changes. In this (greatly simplified) example, data products perform different steps across a business and analytics process.
For example, let's look at a simplified example from a Michelin-starred fine-dining tasting menu, focusing on reservations, pacing, and margin control. Breaking down a business problem into data products.
In this case, the general manager, head chef, sommelier, and front-of-house staff all want to give guests a consistent Michelin-star tasting menu experience while keeping costs down, cutting down on waste, and making sure the guests have a good time. They want to ask questions in everyday language, like "Will our pacing hold if we're full at 20:00?" "Which course is driving low satisfaction this week?" or "Do we have enough langoustines for tomorrow's covers, including allergy substitutions?" There are six separate but linked data products that meet these needs. Each one is responsible for a different part of the operational and analytical process.
The Data Product Pyramid is a way to group products by how much value they add.
Decision Products (DPs) indicate which business choice you need to make.
Knowledge Products (KPs) use data from the past to figure out, guess, or model what will happen.
Information Products (IPs) give you historical views and numbers.
Data Services (DSs) collect and make available high-quality data for use by other products and apps.
These products don't all go into a central warehouse; instead, they connect through a data product graph. An LLM uses retrieval-augmented generation (RAG) and a function call to get to the graph. To sum up, restaurant teams ask questions in plain English, the LLM moves through the data product graph, and the right products work together to provide an answer.
To demonstrate this concept, consider a Michelin-starred restaurant as an example to explain how the six data products collaborate to manage reservations, kitchen operations, supplier coordination, and guest feedback.
DP1: A Data Service for reservations and guest profiles
This product takes reservations from the booking platform, phone notes, walk-ins, and requests from the concierge. It makes guest profiles, party size, seating restrictions, and special occasions all the same, turning different operational inputs into a clean, searchable dataset.
It shows two contracts:
A request/response API for getting information about covers, seating plans, guest notes, and dietary restrictions.
A publish/subscribe interface that sends out updates about reservations and profiles (new bookings, cancellations, allergy changes, etc.) in real time.
DP1 is the system's entry point and provides a single view of the upcoming guests and the preparations the team needs to make.
DP2: Knowledge Product for Service Pressure and Prep Risk
As more reservations come in for DP1, this product predicts coursing and pacing pressure, including expected fire times by course, the risk of pass congestion, turn-time assumptions, and stagger strategies. It also looks at prep risk, like the amount of mise-en-place that can be done at each station, the number of staff needed, and the limits on critical ingredients. This turns raw reservations into useful operational insights, which helps the team keep the quality of the tasting menu high.
DP3: Kitchen execution and POS posting as a Knowledge Product
This step is all about making sure that the service for a tasting menu runs smoothly. DP3 handles live order tickets and course fire events; follows operational rules like pacing targets, allergy substitution protocols, comp and void policies, and pairing cadence; and then posts service events to the POS and shift reporting systems without managing the stores that do the work.
DP4—Menu design and margin as a knowledge product
We use sales and service data from DP3, along with recipe costs and waste data, to figure out course-level contribution margin, pairing attach rates, and menu performance. This helps us find a balance between guest satisfaction and profit. This lets the chef and general manager improve the tasting menu's portion sizes, sourcing, and prices while still meeting Michelin-level standards.
DP5: A Data Service that keeps track of inventory and supplier history
DP5 uses the Service Facade pattern to connect systems for inventory, purchasing, and suppliers. This makes it easy to see what's in stock; when it's expected to arrive; lot and quality notes; and past usage. This method keeps downstream users from having to use vendor-specific tools or spreadsheets.
DP6—Protecting the guest experience as a decision product
The decision product takes information from DP1 to DP5 and uses it to figure out what risks there are to the guest experience. It then clearly tells people what they need to do. It might flag a reservation for allergy confirmation, suggest removing a restricted ingredient, recommend adjusting the meal pace, or initiate an emergency preparation plan. At this point, analytics directly affects how the business makes decisions, ensuring that it meets standards and stays healthy.
What the Data Product Graph and LLMs do
The Data Product Graph gives an enterprise-wide, cross-domain view of all six data products, making them easy to find and use. The graph doesn't put all the data in one place; it shows how products relate to each other and how they are made.
As a natural-language interface, the LLM sits on top of this graph:
Users ask the system questions in a conversational way. The LLM finds out which data products are useful. It calls their APIs, puts the results together, and gives a clear answer.
There are many things that LLMs can do. Larger models coordinate interactions across the whole system, while smaller, more specialised models work within individual products.
What this design makes possible
This approach is based on a few important ideas:
The business puts data products into action steps that are important in both operational and analytical models.
There is no central physical warehouse. Data products work as separate, containerised microservices that share data through a virtual data fabric, but they do not share processes.
LLMs are first-class citizens that can be found in everything from point solutions to enterprise-level orchestration.
The graph shows things, but it doesn't store them. The data products themselves still own and show all of the data.
Data products go through a lifecycle, changing, updating, and adapting as quickly as business needs change.
There are many ways to do analytics. Structured data, unstructured data, classical BI, and advanced models all work together and help each other.
Is your data platform set up?
This approach is what a real AI-native, composable business looks like: it's decentralised, flexible, and always focused on business results.
You're not the only one whose current data infrastructure can't handle this kind of ecosystem. We can show you how to build or move toward this model, and we would be happy to assist you with this problem.
