⏱ 22 min read
A slightly contrarian essay for chief architects in regulated energy enterprises
There is a piece of UML advice that never quite goes away:
Use sequence diagrams for time. Use communication diagrams for structure.
That guidance is not wrong. It is just too thin to help when you are making actual architecture decisions inside a regulated energy enterprise, where diagrams are rarely just classroom notation and rarely even just design aids. They become governance evidence. They become onboarding material for teams inheriting integrations long after the original program has moved on. They end up in audit packs. They get pulled into architecture review boards by people who did not create them and may not even like UML in the first place.
That changes the question.
In utilities, transmission operations, retail energy, DER orchestration, AMI programs, outage management, and market messaging, what matters is usually not notation purity. What matters is whether the artifact survives contact with reality: cross-team comprehension, versioning across a three-year transformation, operational support handover, control evidence, and the very specific kind of misunderstanding the diagram is likely to create when it is incomplete.
That last point matters more than many architects are comfortable admitting. The useful question is not which diagram is better. It is which diagram fails more safely for this audience, in this context, for this decision. TOGAF roadmap template
That is a different standard. In practice, at least in my experience, it leads to different choices than the standard UML advice.
Start with the uncomfortable truth
Most architecture teams choose the wrong interaction diagram for political reasons.
Not technical ones. Political ones.
They pick what the solution architects already know. They pick what the modeling tool exports cleanly into PowerPoint. They pick what the vendor SI already baked into its methodology deck. They pick what looks polished in a steering committee. They pick what a regulator, PMO lead, or assurance manager finds visually reassuring, even when it is the wrong view for the problem.
In energy companies, the bias is usually toward sequence diagrams. They look rigorous. They look engineering-heavy. They signal seriousness. A tall vertical stack of lifelines and messages gives off an air of discipline, even when the architecture problem is not temporal behavior at all, but unclear ownership, hidden intermediaries, or badly chosen orchestration boundaries.
Communication diagrams suffer from the opposite bias. They look lighter. To some people they feel a bit dated. They are often dismissed as “high level” in the unhelpful, pejorative sense, as though compactness automatically means lack of rigor.
I think that bias causes real damage, especially in OT/IT integration work.
I have seen sequence diagrams used where the central issue was not “what happens first?” but “who is actually responsible for what?” and “why are these two systems coupled directly at all?” In those cases, the sequence diagram did not clarify the architecture. It obscured it. It converted a structural problem into a chronology problem, which is often a very convenient way to postpone harder decisions.
So yes, this is the contrarian position: sequence diagrams are overused in enterprise architecture discussions, and communication diagrams are undervalued—particularly in regulated energy environments where the architecture has to be explainable across operations, engineering, compliance, cyber, and delivery. Sparx EA training
Before definitions, look at a real scenario
Take outage restoration orchestration after a grid fault.
A feeder fault is detected in SCADA. An event enters the outage management system. OMS creates or updates the incident. GIS provides asset context. Field workforce management receives dispatch triggers. The customer information system updates affected accounts. Notification platforms begin outbound messages. A market or regulatory reporting pipeline captures event obligations. Depending on the utility, you may also have a cloud event bus, Kafka topics carrying outage state changes, IAM policy checks for operator actions, and one or two awkward middleware components everyone insists are temporary.
Now ask a program team to document the interaction.
What usually happens? They build a sequence diagram. It starts simply enough. SCADA to integration layer. Integration layer to OMS. OMS to GIS. OMS to WFM. OMS to CIS. CIS to notification service. Acknowledge here. Retry there. Alternate path for false positive. Manual intervention if the crew confirms no visible damage. Escalation if the restoration estimate changes. Another branch if the field switch operation requires control room approval. Another if a regulator-specific outage threshold is crossed.
By the time it is finished, it has twelve or fifteen lifelines, alt frames, notes, timers, and enough arrows to look reassuringly sophisticated.
And it is almost unreadable.
The control room lead can follow the first third. The business operations manager drops out halfway through. The security architect wants to know where IAM enforcement actually happens. The regulatory reporting team is not even sure whether they are looking at a design artifact or an aspirational process narrative. Meanwhile the real architectural issue—that customer notification is too tightly coupled to OMS state transitions, and that there is a hidden dependency on a middleware broker nobody truly owns—gets buried under process drama.
That is where a communication diagram is often the better first move.
Not because it is “better” in the abstract. Because it quickly shows who talks to whom. It surfaces hidden intermediaries. It reveals whether OMS is orchestrating too much. It makes duplicate notification paths visible. It exposes the shape of the integration problem before the team gets lost in timing detail.
And in outage orchestration, shape matters. More than people sometimes expect.
If the architecture has quietly made customer notifications a direct peer interaction with OMS instead of routing them through an event-driven orchestration layer with policy controls, that is not a sequencing issue. It is a coupling and ownership issue. A communication diagram can make that visible in five minutes. A sequence diagram can hide it for fifty.
What sequence diagrams are genuinely good at
I am not anti-sequence diagram. Not even close.
A sequence diagram emphasizes time-ordered message flow. It is absolutely the right tool when ordering, latency, branching, acknowledgements, retries, asynchronous behavior, or race conditions matter.
And in energy architecture, those things often matter a great deal.
If you are validating meter event processing, sequence diagrams help. If you are showing retry and timeout behavior in market message exchanges, they help. If you are clarifying command/response timing in DER control integration, especially across aggregator, DMS/EMS, and market operator boundaries, they help. If you are exposing race conditions in near-real-time workflows—say, outage restoration status colliding with customer communications updates—they help a lot.
There are situations where I would insist on a sequence diagram before approving the design. Emergency load shedding coordination is one. Protection-event escalation timing is another. Remote disconnect under vulnerable customer controls is another. When timing and order are operationally material, a communication diagram on its own is not enough.
But here is the trap: teams often mistake temporal precision for architectural clarity.
I have seen excellent-looking sequence diagrams that captured retries to the millisecond, modeled asynchronous Kafka publish/subscribe patterns correctly, distinguished command acknowledgement from execution confirmation, and still did not answer the most important enterprise question: why are responsibilities distributed this way, and which team owns the control points?
A detailed diagram can still be strategically useless.
This is where architects get seduced. Sequence diagrams encourage you to document the unfolding drama of a process. Every exception. Every branch. Every technical hop. Every “and then this happens.” That can feel rigorous. It can also become a kind of narrative theater that stands in for actual design decisions.
I have sat in workshops where a team spent two hours arguing over the exact order of internal service calls in a cloud integration running on Kubernetes, while nobody confronted the fact that the MDM platform was acting as an accidental orchestration engine for policy decisions it should never have owned in the first place.
That is not rigor. That is avoidance with arrows.
Communication diagrams deserve more respect
A communication diagram emphasizes participating elements and the message relationships between them, rather than the long vertical progression of time.
That sounds less glamorous. In practice, it is often more useful for enterprise architecture conversations. Sparx EA guide
Why? Because enterprise architecture is frequently less about one scenario unfolding over time and more about understanding collaboration patterns, service boundaries, intermediaries, dependency concentration, and responsibility allocation. Those are exactly the things communication diagrams make easier to discuss.
They are compact. They can be read in a room with mixed technical and business stakeholders. They expose brittle integration hubs. They reveal when a supposedly event-driven landscape is actually a web of direct dependencies. They help identify whether an ESB, iPaaS, Kafka backbone, API gateway, or IAM policy engine is a healthy control point or a hidden single point of institutional fragility.
In energy programs, I find them especially valuable for AMI ecosystem interaction mapping, demand response partner integrations, asset data synchronization across EAM, GIS, and analytics platforms, and any architecture problem where OT, IT, and market-facing participants all need to be visible at once.
A communication diagram also has a useful forcing effect. It makes you decide who the actors really are.
That sounds obvious. It is not.
In one AMI modernization effort, the initial sequence diagrams showed CIS, billing, MDM, head-end, and field service interactions. Fine. But when we stepped back and built a communication view, we discovered the architecture team had omitted the policy engine that held disconnect eligibility rules, the cloud IAM service authorizing operator-triggered exceptions, and the audit repository where regulator-challenge evidence was retained. Those were not minor details. They were governance-critical participants. The sequence view had nudged the team toward focusing on message order between visible systems. The communication view forced them to acknowledge the control architecture.
That is why I keep arguing that communication diagrams are underused. If the issue is dependency shape, sequence diagrams can hide the real problem.
In regulated environments, notation is not the decision
This is where many UML articles lose the plot.
In regulated industry, diagrams are not just design artifacts. They become evidence.
Evidence in architecture review boards. Evidence in project controls. Evidence in compliance traceability. Evidence during operational turnover. Sometimes evidence during incident retrospectives, when everyone suddenly cares very much about what the architecture was “intended” to do.
So the question shifts.
Which diagram best supports defensible decision-making? Which one survives versioning over a three-year transformation program? Which one can still be interpreted six months later by a control room integration lead, a cyber assurance analyst, and an external auditor who was not in the original workshop?
That is the real standard.
And because that is the standard, notation choice should always be tied to governance purpose. Every interaction diagram should declare its intended use: analysis, design, assurance, audit support, incident review, onboarding. If you do not say what the diagram is for, people will project their own needs onto it and then complain that UML is inadequate, when the actual failure was governance ambiguity.
I feel strongly about this because I have seen too many repositories full of orphaned diagrams with no declared purpose and no maintenance owner. They become fossils. Worse than that, they become misleading fossils.
A practical comparison
Here is the blunt version.
That last column is usually where the pain sits.
Choose based on failure mode, not elegance
This, to me, is the central claim.
When the diagram is wrong, incomplete, or stale—and eventually it will be—which misunderstanding is it most likely to create?
Sequence diagrams fail in very specific ways. They create a false sense of precision. They sprawl. They encourage accidental omission because adding one more lifeline makes the diagram unreadable, so teams quietly leave out stakeholders. They often overemphasize the happy path and underplay structural ownership issues.
Communication diagrams fail differently. They can underplay timing-critical behavior. They can mask retries, race conditions, and asynchronous complexity. They can make an operational flow look simpler than it really is.
Neither notation is innocent.
But in energy, where safety, reliability, and compliance matter, the least dangerous misunderstanding often matters more than perfect completeness. If I am in an architecture review for a transformation where the bigger risk is hidden dependency concentration and unclear ownership across vendor boundaries, I would rather have a communication diagram that slightly underplays timing than a sprawling sequence diagram that gives everyone false comfort while concealing the structural problem.
That is not elegant UML doctrine. It is risk management.
Case study: remote meter disconnect in a regulated utility
This is a good example because it is both operational and regulated.
A delinquency event originates in CIS. Billing or a risk system performs eligibility checks. A command is issued through MDM to the AMI head-end. The meter receives the disconnect command. Acknowledgement comes back. There is an exception route for vulnerable customer protections. Audit evidence must be retained because, sooner or later, someone will challenge a disconnect decision.
If you start with a communication diagram, several useful things happen immediately.
You identify all participants, including the ones teams often forget: the policy engine containing customer protection rules, the IAM component authorizing operator overrides, the audit repository, and sometimes the outbound notification service that warns the customer before action. You also make visible whether MDM is actually orchestrating the business decision or simply passing commands through. That distinction matters operationally and contractually. It changes vendor-boundary risk. It changes upgrade impact. It changes accountability.
Then, once responsibilities are clear, the sequence diagram becomes indispensable.
Now you need approval order. Timeout windows. The difference between command acceptance and actual disconnect confirmation. Exception handling for failed disconnects. Asynchronous callbacks from the head-end. What happens if Kafka publishes the disconnect event but the audit write fails. Whether the vulnerability check must be revalidated before execution if the original eligibility decision is stale.
That is where sequence earns its keep.
The lesson is simple: in this workflow, communication is often the better first artifact, and sequence the better second artifact.
Yet teams regularly do the reverse. They jump straight to sequence because it feels more engineering-heavy. Then they spend weeks refining timing detail without ever resolving responsibility ambiguity.
I have seen that movie more than once.
What these diagrams look like when the architecture is bad
This is a section many polite articles skip. They should not.
One of the best uses of both diagram types is diagnostic embarrassment.
A bad sequence diagram tells on the architecture in one way. You see excessive back-and-forth chatter. Synchronous calls crossing unreliable network zones between OT and enterprise IT. Application-layer polling disguised as orchestration. Manual approval steps awkwardly inserted into the middle of supposedly automated control flows. Repeated call chains through cloud APIs where an event-driven pattern would be safer and cheaper.
A bad communication diagram tells on it differently. Too many direct peer-to-peer links. Hidden central dependency on an ESB or iPaaS component everyone claims is “just transport” even though half the business logic lives there. Duplicate notification paths. Compliance controls bolted onto the edge instead of embedded into the architecture. IAM shown as an afterthought rather than as part of the interaction fabric.
I remember a giant sequence diagram from a market integration program that nobody maintained after the first release. It had been exported from a design tool into Visio, then annotated in PowerPoint, then copied into a governance pack. Six months later, operations relied on it during an incident review. It still showed synchronous API acknowledgements where the implementation had moved to asynchronous Kafka events. The diagram looked authoritative and was wrong in exactly the dangerous way: it encouraged people to assume immediate confirmation semantics that no longer existed.
That was not a notation problem. But sequence diagrams are particularly prone to becoming dangerously stale because their level of detail ages badly.
The reverse problem happens too. I once saw a communication diagram for outage notification that looked tidy, almost elegant. OMS, notification service, CRM, mobile app, call center platform. Clean links. Nice labels. What it hid was a critical regulatory timing dependency: customers in one jurisdiction had to receive a communication within a defined window after outage classification, and the architecture depended on a batch enrichment step that could delay message release. The communication view made the ecosystem understandable, but it masked the operational timing risk. We needed sequence to surface the compliance hazard.
So yes: if the diagram is ugly, the architecture may be telling the truth for once.
Resist the “one standard diagram” mandate
Chief architects love consistency. I understand why. Repositories are chaotic. Delivery teams improvise. Assurance becomes impossible if every team invents its own notation and naming.
But standardizing on one interaction diagram type across the enterprise is a mistake.
It sounds like governance maturity. Often it is just convenience dressed up as discipline.
Interaction concerns differ across strategy, solution design, integration assurance, and audit evidence. The view that helps an architecture board evaluate coupling is not always the view that helps an operations lead assess timeout behavior. Forcing one diagram type across all use cases produces consistency at the expense of usefulness.
A better policy is simpler and tougher at the same time:
Standardize decision criteria. Standardize metadata and naming conventions. Standardize repository placement, traceability, ownership, and review cadence. But do not force a single diagram type across all use cases.
A governance rule I like is this: every critical interaction must have one primary view and, where risk justifies it, one complementary view. Primary and complementary should be chosen intentionally, not by template.
That gives you consistency without stupidity.
Across the energy value chain, the answer changes
In transmission operations, I want a sequence diagram for protection-event escalation timing. Order matters. Latency matters. Fallback matters. But I also want a communication view showing relationships among the control center, EMS, historian, incident systems, cyber monitoring, and operator collaboration tools.
In retail energy and customer channels, I often start with a communication diagram for outage notifications across CRM, notification platform, OMS, mobile app, and call center systems. Then I use sequence for consent capture and message sequencing where regulatory rules apply.
In generation asset maintenance, communication works well to show EAM, condition monitoring platform, data lake, planning tool, contractor portal, and IAM control boundaries. Sequence becomes useful for work-order creation after anomaly detection, especially where approval and exception routes matter.
In distributed energy resources, I usually need both. Sequence for dispatch acknowledgement and fallback timing. Communication for aggregator, DMS/EMS, market gateway, telemetry platform, compliance logging, and cloud eventing relationships.
The answer changes by question, not by doctrine.
That sounds obvious, but plenty of architecture standards still behave as if diagram choice should be settled centrally for neatness.
The selection framework I actually use
Not a textbook matrix. Just a few blunt questions.
What decision is being made?
Who has to understand the artifact?
Is timing or ordering materially risky?
Is ownership or coupling ambiguity the bigger problem?
Will this artifact be maintained through delivery, or is it only a point-in-time analysis aid?
Is the audience reviewing current state, target state, or a transition architecture?
From those questions, some practical heuristics fall out.
Use communication diagrams first when you are untangling actor and system relationships, especially in messy estates with multiple vendors, cloud services, Kafka topics, IAM dependencies, and unclear orchestration ownership.
Use sequence diagrams when validating behavior under operational, safety, or regulatory constraints.
Use both for high-risk workflows—but give them different jobs. “Both” is not a cop-out if the views are intentionally staged and not duplicative. It is only lazy when the second diagram merely redraws the first with more arrows.
Here is a small example in Mermaid just to show the distinction.
A communication-style context for remote disconnect:
And then the risky path in sequence form:
Two views. Two different questions answered.
That is the point.
Common mistakes with both
With sequence diagrams, teams include every microservice and technical hop. They fail to label synchronous versus asynchronous interactions. They ignore exception paths. They mix implementation detail with business interaction level. Worst of all, they produce one giant diagram instead of layered views.
With communication diagrams, teams use vague connection labels like “integrates with” or “sends data,” which is almost useless. They omit middleware, policy engines, and audit components because those make the picture messier. They pretend message numbering alone explains critical timing. They make target-state architecture look indistinguishable from current-state sprawl because they are too timid to express design intent.
The mistake common to both is even more basic: they do not state what architectural question the diagram is meant to answer.
If that sentence is missing, I already distrust the artifact a little.
Auditors do not care about your notation preferences
This part should be said plainly.
Auditors and regulators care about traceability, control points, accountability, exception handling, and evidence of design intent. They do not care that your team prefers sequence because it feels more technical, or communication because it is easier to draw.
If your sequence diagram is beautiful but cannot show control ownership, it may fail governance needs.
If your communication diagram is tidy but hides sequencing that is crucial to safety or compliance, it is equally weak.
In regulated energy environments, usefulness beats modeling orthodoxy every time.
I have never once seen an auditor praise notation purity. I have seen plenty ask, very reasonably, “Who owns this decision point?” and “How do you know this control was intended to happen before execution?” Those are architecture questions first and UML questions a distant second.
How to combine the two without creating maintenance hell
This is where teams usually overcomplicate things.
You do not need two fully independent sets of diagrams multiplying into repository entropy. What you need is one canonical interaction inventory and scoped derivative views.
Define the scenario. Define the actors and systems. Define the key messages and control points. Then derive a communication view for context and a sequence excerpt for one risky path. Keep each diagram focused on a single scenario. Assign ownership for updates. Version by architecture decision, not by meeting date.
That last habit matters. “v12_final_reallyfinal” is not architecture governance.
A documentation pattern I like is simple:
- one-page communication diagram for context
- one-page sequence excerpt for the risky path
- a short architecture note listing assumptions, controls, non-functional implications, and open issues
That is usually enough. It stays alive. People can actually read it. It does not become repository compost.
What I would choose in three difficult energy scenarios
Emergency load shedding coordination? Sequence first. No hesitation. Order, response timing, acknowledgement semantics, and fallback paths are operationally critical. I would add a communication view later to clarify institutional boundaries and external participants.
Enterprise asset data integration modernization? Communication first. The real issue is coupling, ownership, and topology: EAM, GIS, data lake, analytics, cloud integration services, master data stewardship, IAM trust boundaries. Sequence only for a few high-risk update paths, such as asset status changes feeding maintenance planning.
Outage communications transformation? Start with communication. You need to expose orchestration ownership across OMS, CRM, notification platforms, mobile app, call center systems, cloud messaging, and compliance logging. Then sequence the key notification journeys where regulatory timing commitments apply.
That is not theory. It is just where the pain usually is.
Closing argument
The better architect is not the one who knows the UML rulebook most thoroughly.
Sequence diagrams are not inherently more rigorous. Communication diagrams are not inherently simplistic. Maturity lies in choosing the view that makes the risk visible, the decision defensible, and the artifact maintainable by people who did not create it.
So the real question is not “Which diagram should we choose?” in the abstract.
It is this:
Which view helps this regulated enterprise make a safer, clearer, more governable decision?
That is the standard I would use. And if I sound skeptical of sequence-diagram-first habits, it is because I have watched too many teams hide structural confusion inside detailed chronology. In regulated energy, that is not a harmless modeling preference. It shapes what people think is true about the architecture.
And in this industry, the wrong diagram does not just confuse people; it can normalize the wrong assumptions.
FAQ
Are communication diagrams outdated?
No. Underused, yes. Outdated, no. They are often a better fit for enterprise architecture conversations than teams admit. ArchiMate in TOGAF
Can BPMN replace either of these diagrams?
Sometimes, for business process analysis, yes. But BPMN is not a substitute for showing architectural participants, technical controls, and interaction topology with enough precision. BPMN training
Should we use sequence for APIs and communication for enterprise views?
That is a reasonable heuristic, but it is still too simplistic. Some enterprise risks are temporal. Some API discussions are really about ownership and dependency shape.
How much implementation detail is too much?
As soon as the detail stops helping the decision at hand. If adding Kubernetes services, Kafka topics, or IAM token exchanges clarifies risk, include them. If they just make the diagram look impressive, stop.
What should be retained for audit evidence versus delivery documentation?
Keep the artifacts that show control intent, accountability, key exception paths, and architecture decisions. Not every delivery-level sequence deserves long-term retention. Some are scaffolding. Knowing the difference matters.
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.