Why Composable Architecture Needs a Dedicated Structured Data Service

The way digital platforms are built is changing. The trend is moving away from monolithic systems that deliver everything from a single source, toward specialized services that each excel at one task.

The idea behind it is simple: Instead of one vendor delivering content management, commerce, search, personalization, and media management in a single package – with all the compromises that entails – you choose the best available service for each function.

Content Management? Contentful, Storyblok, Contentstack - or magnolia, Ibexa, Coremedia, FirstSpirit, TYPO3, Wordpress etc..

Commerce? commercetools, Shopify, Shopware....

Search? Algolia, Constructor, Elasticsearch...

Media Management? Cloudinary, Bynder, Celum...

Payments? Stripe, Adyen...

These services communicate via APIs. They can be combined, swapped, extended. When a better search provider enters the market, you can switch – without rebuilding the entire system. When new requirements emerge, you add services.

This principle – specialized, interchangeable components instead of monolithic suites – is called Composable Architecture. It's an architectural approach, not a specific technology.

MACH is a specific framework that concretizes the composable approach. The acronym stands for four technical principles:

Microservices: Business logic is split into small, independent services. Each service has a clearly defined task and can be developed, deployed, and scaled independently.

API-first: All functionality is primarily exposed through APIs. APIs aren't added as an afterthought – they're the central interface for every interaction.

Cloud-native: Software is built for the cloud – with elastic scaling, automatic updates, distributed infrastructure. True SaaS rather than on-premise software with cloud hosting.

Headless: The presentation layer is completely decoupled from the backend. There's no predefined frontend – content is delivered via API to any interface that needs it.

The MACH Alliance, a non-profit organization, certifies vendors that meet these principles. Over 100 companies are now members.

MACH is a valid, well-thought-out approach – but not the only path to a Composable Architecture.

Whether strictly MACH or pragmatically composable – as soon as specialized services are in use, a common pattern emerges: The frontend aggregates data from multiple sources.

A typical product page might pull data from the following services:

The frontend – whether React app, classic template system, or something in between – pulls this data together and renders the page. For the user, it's transparent. Under the hood, it's a distributed system.

In this setup, there's one function that typically nobody covers: structured data.

Schema.org markup – the JSON-LD code that makes websites machine-readable for search engines and AI systems – needs information from all these sources. A complete Product schema contains:

Plus cross-page schemas: Organization, WebSite, BreadcrumbList, FAQ.

Who puts this together? The commerce platform might generate Product schema – but incomplete and without context. The CMS knows nothing about product data. The PIM doesn't care about schema.org specifications. And the frontend team has other priorities than maintaining schema markup.

The result: Structured data falls through the cracks. It's incomplete, outdated, or missing entirely.

The composable logic provides the answer: When a function requires specialized know-how and doesn't belong to the core competency of existing services, it becomes its own service.

Just as Algolia contributes "Search" to the platform, Cloudinary contributes "Media Management," and Stripe contributes "Payments," there needs to be a service that contributes "Structured Data."

enhancely is that service. It's not an SEO tool with a hundred features. It's not a CMS, not a commerce platform. It's a specialized service with one clear task: generate structured data and deliver it via API.

The approach: enhancely works at the level of the rendered page. The system analyzes what ultimately reaches the user – regardless of which sources the individual data points come from. It recognizes page types, extracts entities, and generates valid schema.org markup.

This means:

Headless-(hybrid) CMS, Composable Commerce, various specialized services. The frontend orchestrates API calls and renders server-side or at the edge. enhancely integrates like any other service: the frontend calls the API and embeds the returned JSON-LD.

The motivation behind all this isn't technical elegance – it's visibility.

AI search systems like ChatGPT, Claude, Perplexity, and Google AI Overviews are changing how people find information. They generate answers by synthesizing content from the web. They decide which sources to cite – and which not to.

Structured data isn't a nice-to-have here. It's the language AI systems prefer to understand. A product page with complete schema – name, price, availability, reviews, all machine-readable – has a higher chance of being cited than a page whose information must be extracted from prose text.

In a setup where data comes from many sources and converges in the frontend, a dedicated service for structured data is the pragmatic way to achieve this visibility. It fits into existing architectures, handles a clearly defined task, and solves a problem that nobody else addresses.