It is SaaS, so the provider architecture is none of our concern

Fictional educational scenario. It does not describe a specific organisation or provider.

Situation

An organisation buys SaaS and builds its own user channel and integration. The architecture description becomes a diagram labelled “our system → SaaS API”. During review someone says: “We do not operate their servers, so their architecture is none of our concern.”

How the anti-pattern appears

A true statement — the customer does not manage the provider's internal technology — becomes an unsupported conclusion that service behaviour and responsibility boundaries need no review. Uncontrolled components become dependencies nobody has described.

Warning signs

• API documentation and an SLA are treated as the complete solution description.
• Nobody owns failures between the customer channel and SaaS.
• Data location and retention are unclear.
• IAM covers sign-in but omits roles, support access and revocation.
• RTO/RPO describe the platform rather than the complete business journey.
• Customer monitoring ends at the HTTP status code.
• Export and identity/integration shutdown have no exit procedure.

Consequences

During an incident, both organisations may see healthy components while the user cannot complete the process. Unclear ownership delays escalation. Data or versioning constraints may emerge only during implementation. Exit planning starts when the customer already wants to leave. These are possible consequences, not reported events.

A better decision

1. Define the service boundary and both parties' responsibilities.
2. Describe data, identity and integration contracts.
3. Agree quality requirements and how to measure and demonstrate them.
4. Establish monitoring, correlation, incidents, maintenance and recovery.
5. Agree lifecycle and exit before the process depends on the service.
6. Request implementation details when a specific requirement or risk needs them.

Boundary

SaaS deliberately delegates substantial implementation and operations. Effective delegation requires an explicit responsibility contract and evidence for the behaviour the customer depends on. Collecting every internal diagram does not provide that evidence.

“We do not operate their infrastructure” does not mean “we do not need to understand the service.”

SaaS review · Exercise · Weekly