⏱ 20 min read
I’ve seen this play out more than a few times.
A healthcare platform gets through design review with a diagram everyone describes as “clean.” It has the expected logos. A cloud boundary. A Kubernetes box. A database. Maybe an integration engine. A handful of arrows. It looks modern, sensible, and architecture-board friendly.
Then nonfunctional testing begins.
Latency is worse than expected for clinicians during peak appointment windows. Failover behaves in odd ways. Audit evidence is incomplete because the logging path was never modeled properly. The team discovers the video service they treated as “part of the platform” is actually a vendor dependency with its own availability profile and support model. The EHR integration path uses private connectivity in one region, but not in the backup path. And nobody had really noticed that the original deployment view implied synchronous connectivity almost everywhere, even though reminders, notifications, and some audit events actually depend on queues and retries.
The diagram was neat.
It was also misleading.
That matters in any industry. In healthcare, it matters more. Downtime is not just a revenue issue. It disrupts care delivery. Latency is not an abstract SLO debate when a clinician is waiting for patient context during a live consultation. Auditability and isolation are not “security team concerns” off to the side of the architecture. They are part of the architecture.
So yes, UML deployment diagrams still matter. I’d argue they matter more than many teams are willing to admit. EA governance checklist
But only if we stop using them like it’s 2008. In cloud architecture—especially regulated, cloud-native, vendor-heavy healthcare environments—the deployment diagram needs to reflect runtime reality, operational boundaries, managed services, trust zones, and failure behavior. Otherwise it turns into decorative fiction.
The modeling mistakes I keep seeing
There are patterns here, and they’re remarkably consistent across enterprises.
Drawing cloud architecture like it is still virtual machines in a rack
This is the classic one.
Every box becomes a server. Kubernetes gets flattened into one rectangle, as if “cluster” explains anything useful on its own. Serverless is ignored because someone says UML doesn’t fit it well. Managed PostgreSQL gets drawn as though it were installed on a VM the team administers. Kafka is either missing entirely or treated as just another app component instead of what it really is: an operational platform dependency with durability, ordering, replay, and ownership implications. ArchiMate in TOGAF
I get why this happens. A lot of architects learned deployment diagrams in a world where runtime placement mostly did mean physical or virtual servers. But cloud changed the shape of the estate. A managed queue is not “just a box.” An API gateway is not simply a line item in front of an app. A serverless runtime is still a runtime, even if nobody on your team patches the host OS.
If the diagram cannot distinguish between customer-managed workloads and provider-managed services, it is already setting the wrong expectation for operations.
Confusing deployment diagrams with context or integration diagrams
This happens constantly in architecture decks.
Users, external systems, APIs, arrows, labels everywhere. It looks busy and enterprise-ish. But there’s no real execution environment shown. No runtime placement. No clue whether a service runs in a cluster, on a managed platform, in a separate account, behind a private endpoint, or in someone else’s SaaS boundary.
At that point, it isn’t a deployment diagram. It’s a muddled context view.
And that confusion has consequences. If relationships are logical instead of runtime-specific, you can’t reason clearly about resilience. You can’t tell whether a dependency crosses a region boundary. You can’t tell what fails when a subnet is isolated or a managed broker has an outage. You certainly can’t use the picture to support an ops readiness review.
Missing the boundaries that actually matter
This is where cloud diagrams often become dangerously vague.
The boundaries that matter now are not just “production” and “non-production.” They include account or subscription boundaries, VPC or VNet boundaries, subnet segmentation, private endpoints versus public endpoints, region placement, availability zone distribution, tenant isolation zones, and, in healthcare especially, PHI processing boundaries.
I’m pretty opinionated on this: if a deployment diagram in a regulated environment does not make trust boundaries visible, it is incomplete. Maybe it’s useful for a steering committee slide. Fine. But it is still incomplete.
The hard part is not drawing more. The hard part is drawing the right boundaries without drowning the audience in network trivia.
Pretending all nodes are equal
A container cluster, a managed queue, object storage, an API gateway, IAM, a CDN, and a SaaS video platform all show up with the same visual weight. Same kind of box. Same line style. Same sense of ownership.
That is a problem.
Because in the real world, these things are absolutely not equal. They come with different failure modes, different support paths, different change controls, and different operating models. When everything looks the same, people infer the wrong responsibility model. Support teams assume the platform team owns what the cloud provider owns. Security reviewers assume traffic is private when it is actually brokered through a public managed control plane. Delivery teams assume they can tune a managed service the way they tune software they run themselves.
The diagram should help people avoid those mistakes, not invite them.
Over-modeling infrastructure trivia
I’ve also seen the opposite failure mode. The team puts route table IDs, instance types, every security group, every node pool, every subnet CIDR, and all the Terraform-level detail into the view. It becomes unreadable in about thirty seconds.
Usually this happens when engineers are trying to prove rigor.
But rigor is not the same thing as noise.
A good deployment diagram is not an exported inventory report. It should show the details that change risk: resilience design, trust boundaries, operational ownership, public versus private exposure, critical runtime dependencies, data handling zones. It should not try to become the source of truth for every infrastructure setting.
The security fiction problem
And then there’s my favorite bad habit: lock icons everywhere.
A padlock on the API. A padlock on the database. A padlock on the cloud boundary. Maybe a tiny shield near IAM. Everyone feels slightly better.
None of that tells me where TLS terminates. Or how service-to-service identity works. Or where secrets are stored. Or whether admin access goes through a bastion, SSM, privileged workstation, VPN, zero-trust proxy, or something improvised last quarter. It doesn’t tell me how logs leave the workload boundary, where audit data becomes immutable, or whether identity is federated to a hospital directory or maintained locally.
Security decoration is not security modeling. In regulated architecture, that distinction matters a lot.
What a useful deployment diagram should answer
Before getting into examples, it’s worth resetting the purpose.
A deployment diagram is not there to impress architects. Honestly, architects are often the easiest audience to fool because we’ve all seen enough notation to mentally fill in the gaps. The harder audience—and the more important one—is everyone else: operations, security, platform engineering, SRE, delivery teams, auditors, reviewers.
A useful cloud deployment diagram should answer a small set of practical questions:
- Where does the software actually run?
- Which nodes are ephemeral, managed, or persistent?
- Which connections are private, public, brokered, or asynchronous?
- What crosses a trust boundary?
- What must stay in-region?
- What fails if one availability zone dies?
- Who operates each runtime component?
- What can a security reviewer or auditor infer from the picture without a separate oral explanation?
That last point is underrated. If the diagram only works when the lead architect narrates it live, it’s weaker than people think.
The minimal UML you actually need
I’m not interested in turning this into a notation lecture. Most teams need less UML than they think. UML modeling best practices
For cloud deployment modeling, the essentials are enough:
- Node
- Execution environment
- Artifact
- Communication path
- Deployment relationship
- Nested nodes
That’s really it.
In practice, I interpret them fairly loosely, because cloud architecture requires a bit of elasticity in the notation. A node can represent a VM, Kubernetes cluster, managed database service, API gateway runtime, Kafka cluster, object storage endpoint, edge gateway, or even a device gateway if that helps tell the truth. An execution environment might be a Kubernetes namespace, a container runtime, a serverless runtime, or a JVM if that level matters. An artifact can be a container image, a deployable package, a rules bundle, an ML model, or a config package.
Communication paths matter more than teams usually think. Not every line needs a protocol label, but the important ones should have one. HTTPS over the public internet is not the same thing as private gRPC over east-west networking, and neither is the same as event publication to Kafka.
A few stereotypes help a lot:
<> <> <> <> <> <> <>
My practical rule is simple: if you need fifteen custom stereotypes before the diagram becomes understandable, the diagram is carrying too much burden. Split the view.
A telehealth platform: the version teams usually draw
Let’s use a realistic example.
Say you’re modeling a telehealth platform with a clinician web app, patient mobile app, appointment scheduling, video session orchestration, EHR integration, notifications, and audit logging.
What many teams draw is predictable. One big cloud box. Inside it: Web App, App Server, Kubernetes, Database, Integration Engine. Lines from everything to everything. Maybe a small “Video Service” box shown inside the cloud because it feels architecturally tidy. Audit logging hangs off the app tier like an accessory.
It looks okay at first glance.
It is not okay.
Here’s what that bad diagram hides:
- the video platform is vendor-hosted SaaS, outside your control boundary
- identity relies on federation to an external IdP
- patient-facing traffic and clinician/admin traffic often have different exposure and risk profiles
- reminders and follow-ups are asynchronous, not direct synchronous calls
- the transactional database is managed, with backup and replication characteristics that matter
- EHR integration often relies on private connectivity or a brokered interface engine
- observability and immutable audit capture are separate concerns and separate paths
This is exactly the kind of diagram that passes governance and then causes trouble in delivery. Why? Because it makes the platform look more internally coherent and more operationally uniform than it really is. EA governance checklist
Rebuilding the telehealth deployment diagram properly
The fix is not to add fifty icons. It’s to build the picture in the order reality operates.
Start with edge and access
First, show the access layer.
Patient mobile and web users typically come through CDN/WAF and then a public API gateway or ingress path. Clinician portal traffic may share some of that edge layer, or it may use a separate route with stronger access controls, MFA expectations, and SSO federation. The identity provider should be visible, because the authentication flow shapes runtime behavior. If you use enterprise SSO for clinicians and consumer identity for patients, that separation matters.
Also show where TLS terminates. I know some people think that’s “too detailed” for architecture diagrams. Sometimes it is. In healthcare-facing systems, it often isn’t. It changes trust assumptions.
A simple Mermaid sketch can make the point:
It’s not perfectly UML-pure notation, but it’s honest. I’ll take honest over pure any day.
Then place the application runtime
Now show where the software actually runs.
For core business services, a Kubernetes cluster may be the main runtime node. Inside it, you can show execution environments such as namespaces or workload groupings. You do not need every microservice replica. You do want meaningful workload separation: scheduling service, patient profile service, telehealth orchestration, notification service, maybe a separate admin/reporting workload.
This is where a lot of architects overdo the artifacts. The container images are artifacts. Fine. Show them if it helps trace deployables to runtimes. But don’t let artifact detail swallow the deployment story.
The runtime view should answer a simple question: if this service misbehaves, where is it running and what platform does it depend on?
Show managed services as managed services
This sounds obvious, but it gets botched all the time.
The relational database should appear as a managed service node, not as “Postgres on server.” Object storage should be explicit if session artifacts, consent documents, exports, or uploaded files land there. If reminders and integration events flow through Kafka, a managed event bus, or a queue, model that broker as a node. Not as an arrow.
That is especially important with asynchronous behavior. In healthcare platforms, queues and event streams are often what prevent temporary downstream failures from becoming user-visible outages. If you don’t show the broker, reviewers assume direct coupling.
Secrets management and key management should also be visible when they materially shape runtime posture. Not in obsessive detail—just enough to show the control point exists.
Add the healthcare-specific boundaries
This is where the diagram starts becoming genuinely useful.
Mark the PHI-processing boundary. Sometimes that’s a namespace grouping. Sometimes subnet segmentation. Sometimes an account boundary. The exact mechanism varies, but the placement should be obvious. Likewise, if de-identified analytics takes a separate path from operational workflows, show the split. That separation is often important for both compliance and blast radius control.
If EHR integration runs through a private endpoint or dedicated broker, make that explicit. And the vendor video platform should sit outside the direct control boundary. That is not a cosmetic choice. It is an operational truth. If the telehealth session fails because the vendor’s signaling API has issues, your support process, fallback behavior, and SLA position all depend on knowing that boundary exists.
Finally, show the failure behavior that matters
Not every deployment diagram needs failover notes. This one does.
Show multi-AZ cluster placement if the architecture depends on it. Show database primary/standby or replication if regional resilience is part of the design. Show queue buffering when downstream systems are unavailable. If the video vendor API fails, indicate degraded mode: maybe appointment management continues, session launch is retried, the clinician sees a fallback workflow, audit still records intent and failure.
These are not edge cases. They are the architecture.
I’ve found that when teams force themselves to show degraded behavior on the deployment view, weak assumptions surface quickly. Usually around vendor dependencies, asynchronous processing, and operational ownership.
Mapping cloud elements into UML deployment diagrams without lying
Here’s the translation table I wish more teams used early.
That “without lying” part is deliberate. A deployment diagram can be simplified. It just shouldn’t simplify away the truth.
Remote patient monitoring is actually a great deployment-diagram use case
A lot of teams assume deployment diagrams are mainly for web apps. I disagree. Remote patient monitoring is often a better fit because runtime placement and boundary clarity really matter.
Imagine a platform where home devices send readings, an ingestion API receives telemetry, a rules engine evaluates thresholds, a care management app displays alerts, data lands in an operational store and an analytics lake, and integration pushes events to a nurse call center and the EHR.
Teams often model this badly by omitting the device layer entirely, collapsing ingestion and processing into one service, and drawing direct calls from ingestion to every downstream consumer. That misses the architecture.
A better deployment structure would show:
- a device gateway or edge connectivity node
- a cloud ingestion endpoint
- Kafka or another event streaming platform
- stream processing/runtime node for threshold evaluation
- care management application runtime
- operational datastore for current state and alert workflow
- long-term object storage or lake for raw telemetry/history
- alerting service
- integration engine to EHR and call center
Why do I like this example? Because it forces teams to acknowledge intermittency, burst traffic, replay, dead-letter handling, and the separation between operational and analytical concerns.
Here’s a compact sketch:
A few healthcare-specific details are worth showing here:
Device identity and certificate handling. Tenant segmentation by provider organization. Reliability of the alert path. PHI retention zones. The de-identification path for analytics or research.
And some mistakes are worth calling out explicitly because they’re common:
- direct synchronous calls from ingestion to all downstream services
- storing raw telemetry and alert workflow state in the same database
- forgetting dead-letter handling and replay paths
- drawing analytics as if it shares the same operational blast radius as alerting
That last one catches teams out. Operational state and analytical history may both involve patient data, but they rarely belong in the same runtime and failure domain.
When deployment diagrams are the wrong tool
Worth saying plainly: not every architecture problem wants a deployment diagram.
If you need workflow timing, use sequence diagrams or event-flow views. If you need capability ownership, use application or component maps. If you need low-level network implementation detail, use cloud network diagrams or infrastructure-as-code views. If you’re talking to executives, a simplified context view is usually better.
The practical answer in enterprise architecture is not to choose one diagram. It’s to use the deployment diagram alongside the others. free Sparx EA maturity assessment
I’ve had good outcomes with a small set: context, deployment, sequence for one critical path, and a security/control overlay. Not glamorous. Very effective.
Clinical imaging exchange in a hybrid cloud
Hybrid is where deployment diagrams really earn their keep.
Take a clinical imaging exchange scenario: hospital imaging systems remain on-prem, the clinician portal is cloud-hosted, metadata index services run in the cloud, image retrieval goes through a secure gateway, and archival storage is split between on-prem PACS and cloud archive tiers.
This is common enough that nobody should pretend healthcare estates are cloud-only now.
What matters in the diagram?
Show the on-prem data center nodes. Show the secure connectivity node, and not as “just a line.” VPN, private link, direct connect, secure gateway—whatever the mechanism is, it changes latency, operational dependency, and support ownership. Show the cloud VPC or VNet boundary. Show metadata services in Kubernetes or app service runtime. Show the DICOM gateway or protocol translation component. Show archive storage tiers. Show IAM federation with the hospital directory. Show audit and access logging across both environments.
This kind of architecture is where vague diagrams become actively harmful. If you don’t show where protocol translation occurs, support teams will misdiagnose retrieval issues. If you hide the latency-sensitive image retrieval path, users experience “random slowness” that was entirely predictable. If you skip the admin access path, auditors will ask exactly the questions the architecture team should have preempted. And if you fail to represent split operational ownership across infra, app, and vendor teams, incident response will be chaos.
I’ve lived through enough hybrid incidents to be blunt here: a deployment diagram that hides ownership boundaries is not mature architecture.
How much detail is enough? A brutally practical rule set
People ask this all the time, and the answer is less elegant than they want.
Include detail if it changes one of these:
- resilience decisions
- security posture
- compliance scope
- cost or operational ownership
- failure behavior
Omit detail if it’s mainly:
- deployment automation noise
- low-level networking no audience needs
- elasticity clutter at per-instance level
- implementation detail already covered elsewhere in platform documentation
A useful heuristic is simple. The deployment diagram should survive three reviews:
- security review
- operations readiness review
- architecture governance review
If all three ask, “where does this actually run?” the diagram is not finished.
I’d add another test from experience: if an on-call engineer cannot look at the diagram during an incident and quickly understand which dependencies are inside your control boundary and which are not, the diagram is too abstract.
What good cloud deployment diagrams look like in regulated enterprises
They are usually less flashy than the bad ones.
Good diagrams use color or boundary styles for trust zones. Different line styles for synchronous versus asynchronous communication. Explicit stereotypes for managed versus customer-managed. Ownership labels where operational ambiguity would hurt. Region or AZ notation only where resilience depends on it. External dependency treatment that is honest about SaaS and partner platforms.
Useful annotations help too:
- data classification markers
- RTO/RPO notes where relevant
- admin access path
- logging and monitoring path
- failover note
- a short “not shown” assumptions section
I like that last one more than most architects do. “Not shown” is healthy. It prevents false precision. It tells readers what the diagram is intentionally leaving out instead of letting them imagine it was forgotten.
A mistakes-first checklist for reviewing a deployment diagram
Use this in reviews. Seriously.
- Are runtime nodes clearly distinct from logical components?
- Are managed services shown as managed services?
- Are external vendors outside your control boundary?
- Are trust boundaries visible?
- Is PHI handling placement obvious?
- Can someone identify public versus private exposure?
- Is asynchronous communication modeled explicitly where it exists?
- Can you infer resilience posture from the diagram?
- Is operational ownership visible enough to be useful?
- Are observability and audit paths represented?
- Does the diagram hide any major integration dependency?
- Has the team shown too much infrastructure detail in the wrong places?
If a diagram fails three or four of those, I usually stop debating notation and ask the team to redraw it from scratch. That’s faster.
The uncomfortable truth
Most bad deployment diagrams fail for the same reason: teams want one picture that satisfies everyone.
It won’t.
Cloud architecture—especially in healthcare—punishes ambiguity. The estate includes managed services, SaaS dependencies, IAM federation, Kafka or other event backbones, private integrations, public entry points, regulated data zones, and shared platform components owned by different teams. If the deployment view smooths all that into a tidy set of boxes, it may look good on a slide, but it will teach the wrong lesson.
UML deployment diagrams are still useful. Very useful, actually.
But only when they reflect actual runtime placement, actual operational responsibility, actual failure boundaries, and actual regulated-data handling. Less decoration. More truth.
That’s the standard I’d use.
Because the best deployment diagram is not the prettiest one. It’s the one that prevents a bad assumption before production does.
FAQ
Is UML still relevant for cloud-native architecture?
Yes, if you use it pragmatically. The notation matters less than the discipline of showing runtime placement, boundaries, and operational truth. I wouldn’t force strict textbook UML on cloud teams, but I would absolutely keep the deployment-view mindset.
How do I represent Kubernetes without making the diagram unreadable?
Show the cluster as a node. Use namespaces or workload groupings as execution environments only when separation matters. Don’t model every pod replica. That’s observability noise, not architecture communication.
Should serverless appear in a deployment diagram?
Definitely. It’s still runtime placement. Show the function runtime, the trigger source, and the dependencies. The fact that there’s no server you patch does not mean there is no deployment architecture.
How do I show managed services and SaaS dependencies honestly?
Put them in their own nodes. Label them as managed or external. Keep SaaS outside your control boundary. If your app depends on a vendor API for a core workflow, the diagram should make that dependency impossible to miss.
How much security detail belongs on the diagram?
Enough to show trust boundaries, exposure, identity path, secrets or key-management dependency, logging path, and admin access path when those materially affect risk. Not enough to turn the diagram into a firewall rule sheet.
Can one deployment diagram cover both engineering and audit audiences?
Sometimes, but not always. In practice, one primary deployment view plus a light compliance/security overlay works better. Trying to make one picture answer every question usually produces either clutter or vagueness. Often both.
Frequently Asked Questions
Can UML be used in Agile development?
Yes — UML and Agile are compatible when used proportionately. Component diagrams suit sprint planning, sequence diagrams clarify integration scenarios, and class diagrams align domain models. Use diagrams to resolve specific ambiguities, not to document everything upfront.
Which UML diagrams are most useful in enterprise architecture?
Component diagrams for application structure, Deployment diagrams for infrastructure topology, Sequence diagrams for runtime interactions, Class diagrams for domain models, and State Machine diagrams for lifecycle modelling.
How does UML relate to ArchiMate?
UML models internal software design. ArchiMate models enterprise-level architecture across business, application, and technology layers. Both coexist in Sparx EA with full traceability from EA views down to UML design models.