Model external & third-party systems

Most IT landscapes depend heavily on systems you don’t own — SaaS platforms, public APIs, identity providers, managed databases. Modeling these in Dependra is critical for accurate blast radius analysis: when an external provider goes down, you need to know exactly what breaks internally.

This guide covers common patterns for representing external dependencies.

The Key Principle

External systems use the same component kinds as internal ones. The difference is two fields:

• isExternal: true — marks the component as “not owned by us”
• networkExposure: public — indicates it’s reachable over the public internet

The component kind still describes what it is functionally (Web API, Database, Identity Provider, etc.). This means blast radius analysis traces through external dependencies the same way it traces through internal ones.

Common Patterns

External SaaS Application

For a full SaaS product your organization depends on (e.g., Salesforce, Slack, Datadog):

1. Create an Application with isExternal: true and lifecycle state production
2. Add one or more Components representing the integration points:
   • Kind: Web API (if you call its API) or Integration (if it pushes/pulls data)
   • isExternal: true, networkExposure: public

Example — Slack:

• Application: “Slack” (isExternal: true)
  • Component: “Slack API” (kind: Web API, external, public)
  • Component: “Slack Webhooks” (kind: Integration, external, public)

Public API

For a standalone API you consume that isn’t a full SaaS product (e.g., Stripe Payments API, a government open data API):

• Component: kind Web API, isExternal: true, networkExposure: public
• You don’t need an Application wrapper if it’s just a single API endpoint

Example — Stripe:

• Component: “Stripe Payments API” (kind: Web API, external, public)

Then add a dependency from your internal payment component to the Stripe component.

Identity Provider

For external auth services (e.g., Auth0, Okta, Azure AD, Google Workspace):

• Component: kind Identity, isExternal: true, networkExposure: public

Example — Azure AD:

• Component: “Azure AD” (kind: Identity, external, public)

Managed Database

For database-as-a-service offerings (e.g., PlanetScale, Supabase, MongoDB Atlas, AWS RDS):

• Component: kind Database, isExternal: true
• Set networkExposure to private if it’s accessed over a private network (VPC peering), or public if accessed over the internet

Example — PlanetScale:

• Component: “PlanetScale Orders DB” (kind: Database, external)

Managed Messaging / Event Streaming

For managed messaging services (e.g., Confluent Cloud, AWS SNS/SQS, Azure Service Bus):

• Component: kind EventBus, isExternal: true

Example — Confluent Cloud:

• Component: “Confluent Kafka” (kind: EventBus, external)

Cloud Storage

For managed object storage (e.g., AWS S3, Cloudflare R2, Azure Blob Storage):

• Component: kind Storage, isExternal: true

Example — AWS S3:

• Component: “S3 Document Store” (kind: Storage, external)

CDN / Infrastructure Service

For infrastructure-layer services (e.g., Cloudflare, Akamai, AWS CloudFront):

• Component: kind Infrastructure, isExternal: true, networkExposure: public

Example — Cloudflare:

• Component: “Cloudflare CDN” (kind: Infrastructure, external, public)

Adding Dependencies

Once your external systems are modeled, connect them to your internal components:

1. Navigate to the Canvas view
2. Draw a dependency edge from your internal component to the external one
3. Set the dependency mode (sync/async) and whether it’s required

For example: Orders API → depends on → Stripe Payments API (sync, required)

This means when you run blast radius on Stripe, Dependra will show that your Orders API — and everything downstream of it — is impacted.

Organizing External Systems

A few approaches that work well:

• Dedicated Product Suite — Create a “Third-Party Services” or “External Dependencies” product suite to group all external applications together. This keeps them visually separate from your internal landscape.
• Inline with consumers — Place external components inside the application that uses them. This works when only one internal application depends on a given external service.
• Tags — Use tags like third-party, saas, or managed to cross-cut across product suites.

What’s Next?

With your external dependencies modeled, you can:

• Run blast radius analysis to see internal impact when an external provider fails
• Use the Canvas to visualize the full dependency graph, including external boundaries
• Filter components by Scope (External only) to review all third-party dependencies at a glance