⏱ 21 min read
I remember the meeting because the room went quiet in exactly the wrong way.
We were in an enterprise architecture review for a patient engagement platform at a regional healthcare provider that had recently expanded through acquisition. On the call were the CIO, the security lead, an integration architect, a product manager, someone from clinical operations, two vendor architects, and my team. We had diagrams on the screen. A lot of them. Boxes, arrows, interfaces, message brokers, deployment nodes, and enough notation to make everyone feel, at least for a moment, that we were being very rigorous.
And still, no one agreed on what they were actually looking at.
The developers wanted more precision. The CIO wanted the picture simplified. Security wanted trust boundaries called out explicitly. Compliance asked where the audit trail sat relative to PHI movement. The clinical operations lead asked what turned out to be the most useful question in the whole session: “If the EHR interface is down, what actually stops working for patients?”
Nobody answered right away.
That was the real problem. Not whether UML was somehow better than C4 in the abstract. Not whether one was more “architecturally correct.” The problem was that we were treating diagrams as if notation by itself could solve communication. It can’t. In practice, especially in healthcare, the wrong notation creates communication debt. People nod in meetings, leave with different assumptions, and those assumptions eventually come back as rework, security delays, brittle integrations, and confusion during incidents.
After fifteen years in enterprise architecture, a good portion of it in healthcare, I’ve become fairly opinionated about this: UML and C4 are not enemies. They solve different problems. Force either one into the wrong conversation and it will let you down. Use both intentionally, and they complement each other extremely well. free Sparx EA maturity assessment
The trick is not picking the “best” notation. It’s picking the notation that reduces ambiguity for the decision in front of you.
The case: a patient engagement platform under pressure
The platform at the center of this story sounds ordinary on paper, which is usually where architecture problems begin.
It handled appointment reminders, lab result notifications, telehealth intake, medication follow-up, and a handful of patient messaging capabilities. It integrated with the core EHR, the identity provider used by the patient portal, CRM and call center tooling, SMS and email providers, an analytics platform, a consent management capability, and centralized audit logging. Some parts were internal. Some were SaaS. Some came from vendors who insisted they had APIs “ready for enterprise scale,” which, in my experience, usually means you need to ask much more specific questions.
This was exactly the sort of system where architecture notation matters, because the architecture itself is messy in the way real enterprises are messy. You have regulated data flows. Mixed ownership. Clinically adjacent workflows. Operational dependencies that only become obvious when something breaks on a Sunday morning. And in healthcare, unlike in plenty of other industries, these are not abstract concerns. A delayed lab result notification, a consent rule applied incorrectly, or a broken appointment reminder flow can affect patient experience directly and sometimes clinical follow-through as well.
The trigger was a regional merger.
Two organizations had overlapping patient communication tools, different identity patterns, duplicate notification services, and wildly inconsistent documentation. Some of the diagrams lived in PowerPoint. Some were buried in an architecture repository nobody really trusted. Some had been copied from older programs and lightly renamed. We had integration flows drawn six different ways depending on who authored them. One vendor delivered Visio diagrams with proprietary symbols and no legend. Another used UML component notation, sort of, but with custom semantics nobody else interpreted the same way. UML modeling best practices
So we were doing what enterprises often do under pressure: trying to rationalize platforms while the documentation itself was part of the problem.
That made this a useful case for comparing UML and C4, because this wasn’t a greenfield team debating modeling philosophy. This was a live, regulated environment where architecture communication had consequences. UML for microservices
What we got wrong first
I’ll be candid here, because this is where a lot of architecture articles suddenly become suspiciously tidy.
Our early documentation was not good.
One mistake was using UML component diagrams with far too much detail for executive and governance discussions. We had interfaces, dependencies, external services, utility packages, and all the visual density that makes architects feel productive. But what the steering group needed was much simpler: what are the system boundaries, who owns which capability, and where are the major dependencies and risks? We gave them precision when what they needed was orientation. ARB governance with Sparx EA
That bought us exactly nothing.
We also created sequence diagrams so detailed they were obsolete almost immediately. I’ve done this more than once in my career. You start with good intent. You want to clarify behavior. Then every API call, token exchange, queue publish, callback, retry, and logging event ends up on the page. By the time the sprint changes the integration flow, the diagram is already half wrong. It’s technically rich and practically dead.
Another classic error: we mixed concerns in one picture. Logical structure, deployment topology, vendor ownership, and network trust boundaries all in a single diagram. It looked comprehensive. It was actually just confusing. The integration architect focused on payload movement. Security focused on network segments. Product looked at capabilities. Operations looked for runtime responsibilities. Everyone saw their own lens and missed the rest.
We also copied notation habits from another program without asking whether they fit this one. That happens more often than architects like to admit. A previous transformation used a certain diagram style, so we reused it because it felt familiar and “enterprise-grade.” But healthcare platforms are not interchangeable. A claims processing ecosystem and a patient engagement platform may both involve PHI, but they need different architectural storytelling.
The bad assumption underneath all of this was that formal meant better.
It doesn’t.
In this case, the consequences were concrete. Security review took longer because trust boundaries weren’t explicit. The integration team misunderstood where PHI transformation logic lived between the Kafka-based event broker and the downstream notification service. The support team couldn’t really use the diagrams during incident response because they didn’t clearly show runtime ownership. Every time a new vendor came onboard, we ended up re-explaining the architecture verbally because the diagrams didn’t stand on their own.
That was the turning point for me. The issue wasn’t notation purity. It was communication intent.
If a diagram cannot help the person in front of you make a decision, ask a risk question, or troubleshoot a failure, it may still be technically elegant, but it is not doing architecture work.
The questions I ask now before choosing UML or C4
These days I have a simple internal checklist, and it has saved me a lot of wasted effort. ADR template
Who is the audience?
What decision needs to be made?
Is the goal explanation, design, assurance, or analysis?
How long does this diagram need to stay relevant?
Do we need behavioral precision or structural overview?
Will someone outside the delivery team use it later — auditors, support engineers, cyber teams, a vendor, clinical operations?
Those questions matter in any industry, but healthcare raises the stakes. Privacy boundaries matter more. Clinical workflow dependencies are less forgiving. Uptime expectations are high, and ambiguity around third-party integrations is common because half the stack is often shared across business and vendor domains. You also have documentation surviving team turnover. In healthcare, an architecture diagram is rarely just for the team that creates it. Six months later it may resurface in an audit, a security review, a vendor dispute, or an incident bridge.
That changes how I think about notation.
I’m not asking, “Which notation is more expressive?” I’m asking, “Which notation will still be useful when this system is under pressure?”
That usually leads me toward C4 for orientation and UML for precision. UML domain modeling
Not always. But often enough that it has become my default instinct.
Why C4 clicked with non-technical stakeholders
When I explain C4 to business stakeholders, I don’t actually explain C4. I just use it.
System context. Containers. Components. Sometimes code-level views if the engineering team genuinely benefits, though in enterprise practice I use that far less than people assume. The power of C4 is not the labels. It’s the hierarchy. It gives people a ladder from broad context to increasing detail without forcing them to learn a notation language first.
That helped almost immediately in our healthcare case.
For the merger stakeholders, a C4 system context diagram did more in ten minutes than a stack of UML views had done in two weeks. We could show the patient engagement platform in relation to the EHR, IAM, CRM, analytics, notification providers, consent service, and audit platform. We could mark external vendors. We could indicate where PHI crossed boundaries. Most importantly, we could talk about ownership and dependency without drowning the room in syntax.
A container view was where things became practical. We used it to show the patient-facing web and mobile experience, the orchestration services, Kafka-based eventing, the notification engine, identity services, audit store, and integration adapters. The product manager could follow it. Security could challenge it. Operations could see where runtime responsibilities sat. That is a good diagram.
Here’s a simple flavor of the kind of C4-ish picture that actually helped:
Is that formal C4? Not exactly. Do I care? Not much. It communicated the right things to the right people.
That’s one of my stronger opinions: C4 works because it lowers the cost of getting to shared understanding. Teams that are already struggling with documentation discipline do not need more notation overhead. They need a way to make system boundaries, responsibilities, and dependencies visible quickly.
C4 is especially useful in governance settings because people can read it without sitting through a legend lecture. It also scales reasonably well across portfolio discussions. If I’m talking to enterprise leadership about three patient communication capabilities across two merged organizations, C4 gives me a consistent way to show overlap and rationalization options. EA governance checklist
But I don’t think C4 is enough on its own.
The limitation is that it can look deceptively complete. Teams draw a nice context and container set, everyone feels aligned, and then the hard questions remain unanswered. What happens when the EHR publishes an appointment change event out of order? How is consent evaluated at send time versus preference lookup time? What exactly happens when the SMS gateway times out after partial acknowledgement? C4 doesn’t naturally force those conversations.
Which is why I think C4 is often better at starting architecture conversations than finishing the deeper technical ones.
UML still earns its keep
I get impatient with the lazy narrative that UML is old and therefore somehow irrelevant. That’s mostly nonsense. UML is still useful when you need precision, especially around behavior, state, and deployment. The problem is not UML itself. The problem is that teams either overuse it or use it badly.
In our case, sequence diagrams were materially better for a few key workflows.
Appointment booking was one. Lab result notification was another. These involved asynchronous interactions between the EHR, integration services, Kafka topics, consent checks, notification providers, and audit logging. A C4 container diagram showed where those things lived. It did not adequately show the order of events, alternate paths, retries, or timeout behavior. UML sequence diagrams did.
State diagrams were also valuable, particularly for consent lifecycle and notification retry status. In healthcare, state often matters because policy depends on it. “Revoked” is not the same as “expired.” “Pending verification” is not the same as “inherited from external source.” Those distinctions affect legal defensibility, test design, and operational support. A state model made that visible in a way that a structural diagram simply could not.
Component diagrams had a narrower but still useful role. When we needed to make interfaces and dependencies explicit between orchestration services, event handlers, policy evaluators, and audit components, UML component notation gave us a more disciplined way to document it. Not because it was prettier. Because it was more exact.
Deployment diagrams, meanwhile, became important once we got into hybrid hosting and hospital integration runtime. We had cloud-native services in one environment, managed Kafka in another, IAM integration through a shared enterprise service, and on-prem hospital interfaces still running through older middleware. Security and operations needed a deployment view that showed node placement, network zones, and external boundary crossings. UML deployment views were a decent fit there.
The honest caveat is that UML becomes ceremony-heavy very quickly. It assumes more notation literacy than most mixed audiences have. And in practice, most teams use only a small subset well. That’s fine. I would much rather see a team use sequence and state diagrams competently than produce a full UML zoo badly.
If policy and behavior matter, UML is often the more honest tool. If broad communication and structural orientation matter, C4 usually wins.
That’s the real comparison.
A practical comparison
Here’s how I’d summarize it in enterprise healthcare work:
The key point here is not that one column is better. It’s that each one answers different questions.
I’ve found that once teams see this play out in real work, the unhelpful “UML vs C4” debate loses energy very quickly.
The turning point: we stopped asking for one notation to do everything
Eventually, our architecture team admitted the obvious: the debate itself was wasting time. TOGAF training
We reset the documentation approach around review types and risks, not around a preferred modeling ideology. That was one of the better changes we made.
C4 became our default for landscape, context, and most structural communication. UML became targeted and deliberate: sequence for critical workflows, state for policy-driven lifecycles, deployment for runtime topology where hosting and trust zones mattered.
Just as importantly, we stopped requiring every diagram for every project.
That sounds trivial. It isn’t. A lot of architecture practices quietly drown teams by asking for documentation bundles no one will maintain. We replaced that with a lighter mapping:
- Architecture board review: C4 system context and container
- Security review: C4 container plus deployment view and annotated data flows
- Solution design workshop: C4 component plus UML sequence for the risky workflows
- Production readiness: deployment view and a failure-path sequence for operationally critical scenarios
This changed the conversation completely. Architects spent less time arguing about notation and more time isolating what actually needed to be clear.
Notation should follow risk and decision type, not architect preference. I wish more teams would say that plainly.
Example #1: modernizing the appointment reminder service
One of the first places this approach paid off was the appointment reminder modernization.
The old process was batch-based. Overnight jobs pulled appointment data, filtered records, looked up contact preferences, and pushed notifications through a tangle of integrations. It worked until it didn’t, and when it failed, support had very little visibility. The modernization moved us toward an event-driven model: appointment events emitted from the scheduling domain, consumed by a reminder orchestration service, validated against consent and patient communication preferences, and then delivered through channel providers with audit logging at each step.
Stakeholders were all over the map: digital product, integration engineering, patient communications, compliance, and operations.
C4 helped us clarify ownership. We could show the scheduling system as the event producer, Kafka as the transport backbone, the reminder orchestrator as the service responsible for policy-aware scheduling, and delivery providers as external channels. We could show that preference and consent checks were distinct capabilities. That sounds obvious now. It was not obvious in the first design workshop.
UML helped with the hard parts.
We used a sequence diagram for scheduling event ingestion, preference lookup, consent validation, queueing, provider delivery, callback handling, and audit event persistence. And yes, our first attempt was a mess. Every API call went in. Token exchange. Payload transform. Internal cache lookup. Dead-letter detail. It became unreadable.
So we split it.
One diagram for review: happy path plus the major alternate paths.
Another for engineering: more detail around retries, callback correlation, and dead-letter handling.
That was a useful lesson, and I’ve repeated it many times since. The right abstraction level matters more than the notation brand. A bad UML diagram and a bad C4 diagram fail for the same reason: they try to serve too many purposes at once.
A simplified behavioral view looked more like this:
That was enough for most review conversations. The engineering team had a more detailed version elsewhere.
Example #2: consent management across patient channels
Consent was the area where C4 alone stopped being sufficient.
We had multiple systems capturing patient consent in inconsistent ways: portal registration, call center scripts, mobile app preferences, and in some cases consent attributes synchronized from external sources. Legal and compliance needed confidence that enforcement logic was not just documented but unambiguous. Product wanted consistency across channels. Engineering needed to know where enforcement occurred and how stale states were handled.
A C4 diagram showed where the consent service sat in the landscape and which systems depended on it. Useful, yes. But not enough.
The real issue was lifecycle.
Could a consent be granted in one channel and immediately enforceable in another? What happened when consent expired? How did we represent pending verification? What if an external source synchronized a status we considered authoritative for one communication type but not another?
That required a state diagram. There really wasn’t a simpler honest substitute.
We modeled states such as granted, revoked, expired, pending verification, and synchronized from external source, with explicit transitions and triggering events. We then paired that with a sequence diagram showing channel-specific enforcement at send time. In other words: not just where the consent service lived, but how policy was applied when an outbound message was about to leave the platform.
That did two important things. It reduced policy ambiguity, and it improved test case design dramatically. QA could derive scenarios from the state transitions rather than guessing at edge cases. Compliance had something concrete to review. Engineering had less room to improvise.
This is one of those areas where I have a strong view: when policy and behavior intersect, UML often becomes the better tool because it forces you to confront the details you might otherwise hand-wave.
The part architects skip: readability, maintenance, and team behavior
This is the unglamorous section, but it matters more than most notation debates.
The success of architecture documentation is determined less by expressive power and more by boring things: whether diagrams are updated, whether names are consistent, whether the legend is clear, whether more than one person can create them, whether they live somewhere people can actually find them.
C4 has an advantage here. It’s easier to socialize across mixed-skill teams. Product managers won’t create container diagrams, but they can usually read them. Engineers can produce acceptable versions with a bit of coaching. The quality variance is lower.
UML is different. Good UML is very good. Bad UML is extremely common. The quality depends heavily on practitioner skill, and many teams know just enough to create diagrams that look formal while being semantically muddy. I’ve seen sequence diagrams with no clear lifelines, component diagrams that are really deployment diagrams in disguise, and state models that are just flowcharts wearing UML clothes.
Tooling matters too.
If your architecture lives only in heavyweight modeling tools that nobody wants to open, your notation will lose to entropy. In our environment we ended up with a mix: docs-as-code for lightweight structural views, repository-linked diagrams for governed solution records, and a few exportable artifacts for audit and vendor onboarding. The moment updating a diagram feels like a separate project, teams stop doing it.
Healthcare adds another wrinkle: documentation outlives teams. Audits, vendor turnover, operational support, and platform rationalization all pull old diagrams back into circulation. I’ve seen two-year-old architecture sketches become suddenly important during an incident because nobody had anything better. That’s why maintainable “good enough” beats elegant but abandoned models every time.
I mean that literally. Every time.
Common traps when comparing UML and C4
A few traps show up again and again.
Treating C4 as too simplistic for enterprise use. It isn’t. Simplicity is often a feature.
Treating UML as automatically rigorous because it is formal. It isn’t. Sloppy UML is still sloppy, just with better branding.
Using either notation without explicit trust boundaries, data classification markers, or ownership cues. In healthcare, that omission is not minor.
Trying to draw one diagram for all audiences. That is one of the fastest ways to produce diagrams nobody really uses.
Confusing application architecture with business process workflow. They overlap, but they are not the same thing. BPMN training
Over-documenting stable internal areas while under-documenting risky external integrations. I see this constantly.
Ignoring operational failure modes. Architects love happy paths more than they should.
And one that matters in vendor-heavy environments: assuming external partners interpret notation the same way your internal teams do. They often don’t. Be explicit.
A field guide for choosing under delivery pressure
When delivery pressure is real, nobody wants a methodology sermon. So here is the practical version.
If you need shared understanding across business and IT, start with C4.
If you need interaction precision, use a UML sequence diagram.
If lifecycle or status behavior drives policy, use a UML state diagram.
If runtime topology, hosting nodes, network zones, or hybrid placement matter, use a deployment view — UML if that helps your organization, or an equivalent infrastructure view if your teams read that more naturally.
If you’re communicating at portfolio or capability level, favor C4.
If you’re handing off engineering detail for a sensitive workflow, combine both.
Then apply healthcare-specific filters. Ask:
- Does this affect patient safety or clinical follow-through?
- Does it involve PHI movement across boundaries?
- Is there likely to be regulatory or audit scrutiny?
- Is the integration critical and failure-prone?
- Is a vendor responsible for part of the flow?
If the answer to several of those is yes, structural diagrams alone are usually not enough.
My recommendation in most enterprises is to standardize a small approved subset, not a giant notation catalog. The catalog approach looks mature on paper and collapses in practice.
What I would standardize in a healthcare architecture practice
If I were setting the baseline from scratch — and in one organization, I effectively did — I would standardize the following.
A C4 system context diagram for every solution of consequence.
A C4 container diagram for all production systems.
A UML sequence diagram for critical end-to-end workflows involving external systems, especially EHR, IAM, messaging, and eventing integrations.
A UML state diagram only where business policy depends on lifecycle state, such as consent, order status, notification retry state, or clinical task progression.
A deployment view for systems with hybrid cloud, on-prem, or shared integration runtime complexity.
That’s enough for most enterprises. More than that and you often create drag unless you are in a genuinely high-assurance domain.
I would also enforce a few documentation rules because these matter more than people think:
- one primary audience per diagram
- explicit ownership labels
- trust boundaries and PHI or sensitive-data markers
- date, version, and review trigger
- visibly archived obsolete diagrams instead of leaving them to rot ambiguously
That last point is underrated. Nothing damages trust in architecture documentation faster than people not knowing whether a diagram is current.
There are exceptions, of course. If you’re in a safety-critical subdomain, medical device integration, or a heavily regulated processing area, more formal modeling may be warranted. But for most healthcare enterprise platforms, a disciplined subset beats a comprehensive framework nobody sustains.
What finally worked
Back to that patient engagement platform.
Once we reset the documentation approach, architecture reviews got faster. Vendor onboarding improved because we had structural views that people could understand without a guided tour. Security conversations became sharper because trust boundaries and deployment concerns were no longer buried inside general-purpose diagrams. Operations got better failure tracing for the reminder and notification services because we documented exception paths instead of pretending happy flows were enough. Product owners finally had a usable picture of dependency impact when changes were proposed.
More importantly, the room stopped arguing about notation and started talking about risk, responsibility, and behavior.
That, to me, is the real point.
Choosing between UML and C4 is often the wrong framing. The better question is simpler and more useful: which notation best reduces ambiguity for the decision in front of you?
In enterprise healthcare, clarity is not cosmetic. It affects delivery speed, compliance confidence, incident response, and sometimes the patient experience itself.
That’s why I still use both. Just not in the same way, and never by habit.
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.