Adopting the pattern is a series of small decisions across a project: where to put each piece of logic, how to version, what to expose. Done well, the layers stay clean; done badly, the layers blur.
- Map the integration to the three layers
For the new feature, identify which calls touch backends (System), which encode business logic (Process), and which shape data for a specific consumer (Experience). Map each call to its layer before writing code.
- Reuse existing System APIs where possible
Search the API Catalog. If a Salesforce or SAP System API already exists, reuse it. Building a parallel System API is the most common anti-pattern and the fastest way to defeat the pattern.
- Build the Process API to encode the workflow
Implement the orchestration in the Process layer. Keep the Process API generic enough for the next consumer to reuse it, but specific enough to model the actual business operation.
- Build the Experience API for this channel
Tailor the response payload to what the channel actually needs. Trim fields aggressively for mobile, add channel-specific enrichment for partner, and so on.
- Publish and govern
Register each new API in the catalog with owner, SLA, and lifecycle status. Configure rate limits and authentication in API Manager. Document deprecation paths up front.
- Putting business logic in System APIs collapses the pattern. The System layer must stay close to the backend, with logic in Process.
- Skipping the Process layer for speed leaves Experience APIs reimplementing the same orchestration. The third Experience API is when the cost shows up.
- The pattern adds latency. For high-frequency low-latency paths, consider caching at the Experience layer or skipping the pattern entirely.
- Without strict naming and ownership conventions, the layers blur within a year and the pattern collapses back to point-to-point.