How to share infrastructure without merging product data

Begin with separate product purposes

Write down the purpose of each product before describing shared infrastructure. A customer relationship platform, an education service and a claims workflow may use some of the same technical components while serving different people under different expectations. Purpose should determine the permitted data and action boundary; technical convenience should not silently widen it.

Share capabilities, not entire records

Describe the capability being reused: for example, authenticating a user, delivering a message or routing a bounded request to an authorised service. Then identify the minimum information required for that task. A connection can pass a reference, permission or narrowly defined payload without copying a product's complete record into a group-wide store.

Keep an accountable system of record

For every important field, decision and event, name the authoritative system and its owner. Shared services may process or transport information, but teams should still know where a correction is made, which record prevails and who answers for its quality. Avoid creating several unofficial copies that cannot be reconciled.

Make permission and revocation explicit

Record who may request a connection, who approves it, what scope is granted and how it expires or is withdrawn. Human access and service-to-service access need separate treatment. A permission that cannot be reviewed and revoked is difficult to govern, even when the original integration was reasonable.

Use observable boundaries

Document the expected request, response and failure path. Keep enough event evidence to determine which product requested an action, which shared capability handled it and whether the action completed. Logs should support review without becoming an unnecessary second copy of sensitive content. Define exception handling before an integration is treated as operational.

A boundary record for each connection

1. The product purpose and the people whose data may be involved.
2. The minimum information needed for the shared capability to perform its task.
3. The system of record and the owner responsible for it.
4. Who may request, approve, use and review each connection.
5. What is transferred, derived, logged, retained or explicitly excluded.
6. How access is revoked and how exceptions are investigated.
7. The evidence reviewed before a connection is expanded.

Date the record and update it when the purpose, data, owner or technical path changes. Mark unverified controls as planned or unknown rather than implemented.