⏱ 24 min read
I have been in more than one workshop where somebody said, with total confidence, “we need the target data model,” and five different people around the table nodded while imagining five different artifacts.
One of those sessions took place in Brussels, in a room full of entirely sensible professionals: policy officers, a delivery vendor, two solution architects, a database lead, a data governance colleague, and the interoperability team. We were discussing a grants platform that had to support several programmes, multiple agencies, multilingual content, audit obligations, and handover across contractors over time. In other words, fairly typical public-sector complexity.
The first architect put a UML class diagram on the screen. Boxes, attributes, relationships, a few multiplicities. Perfectly reasonable. UML modeling best practices
The database team immediately asked where the keys were.
A policy lead then said the model felt too technical because they had expected a conceptual view of applicants, beneficiaries, calls, and agreements “in business terms.” The interoperability lead was uncomfortable because the diagram said very little about exchange payloads or canonical structures for data moving between the portal, the case management platform, and the reporting warehouse. Meanwhile, the vendor was trying to infer implementation scope from a diagram that had never really been intended to carry that kind of weight.
Everyone stayed polite. In my experience, that is often the warning sign.
Nobody wanted to derail the meeting by saying the obvious thing out loud: we were using the same phrase—data model—to mean different questions, different audiences, and different levels of abstraction. So the workshop drifted on, a kind of agreement seemed to exist, and the real disagreement surfaced later in procurement clarifications and then again during implementation. By the time the first integration sprint started, the team discovered that what had been approved as a “model” was not enough to design persistent storage, not enough to support reconciliation rules, and not quite right for explaining the business domain either.
This is the central point, and it matters more than the notation debate usually suggests: UML and entity-relationship diagrams are not competing versions of the same thing. They answer different architectural questions. Problems start when an institution uses one as a stand-in for the other, or worse, expects a single diagram to satisfy governance, procurement, implementation, and business communication all at once.
That almost never ends well.
Why this matters more in EU institutions than in ordinary corporate IT
In a small commercial product team, misuse of models can still cause damage, but the blast radius is usually limited. The people are closer together. The landscape is narrower. Often the same people who draw the model are also the people who build and run the software.
That is not the world most EU institutions live in.
Here, the stakes are different. Data is multilingual. Legal traceability matters. Systems exchange information across institutional boundaries and national contexts. Applications tend to live a long time—often longer than delivery teams, and sometimes longer than the programme structures around them. Delivery is frequently outsourced, often under framework contracts, with work passing from one supplier to another. And the audiences for architecture models are mixed in a very practical sense, not a theoretical one: policy teams, enterprise architects, security colleagues, data stewards, procurement officers, and implementation vendors all need to derive something useful from the artifacts. Sparx EA guide
That creates a very specific kind of failure mode.
A diagram can look formal enough to pass a review board and still be the wrong instrument for the decision in front of the institution. Procurement documents then inherit that ambiguity. Vendors make reasonable assumptions, but not the same assumptions. Integration points become brittle because one team thought they were working from a conceptual information model while another treated it as a logical data design. Months later, the first visible symptoms show up during reporting, audit preparation, reconciliation, or change requests.
In public administration, bad modeling is rarely dramatic at first. It does not usually fail loudly on day one. It sits quietly in the background and then becomes expensive at handover points—during integration, during audit, during contractor transition, during legislative change, during data correction exercises.
I have seen governance boards spend an hour debating notation while missing the more important question entirely: what decision is this diagram actually supposed to support?
That is the real anchor.
The real question is not “Which notation is better?” but “What decision are we trying to support?”
This is where teams often get unstuck. It is also where a surprising number of arguments simply evaporate.
If the conversation is about behavior, responsibility, lifecycle, or interaction, UML often earns its place. Not because it is fashionable, and not because CASE tools still ship with it, but because it lets you express more than static structure. It can show who does what, in what order, under what conditions, and how an object or concept changes over time.
If the conversation is about persistent storage, keys, relational cardinality, normalization, historical records, and integrity constraints, ERD is usually the sharper tool. It forces a useful kind of discipline. It makes ambiguity much harder to hide.
That distinction sounds obvious when written down. In practice, teams blur it all the time.
Architects are usually trying to support one or more of these decisions:
- What are the core concepts in the domain?
- How should data be stored and related over time?
- Which application owns which responsibilities?
- What does a message or event payload need to contain?
- How do legal or policy concepts map into implementable structures?
- What needs to be master data, reference data, or transactional data?
- Where do we need history, auditability, or temporal validity?
Different questions need different models.
And yes, there is overlap. A UML class diagram and a conceptual ERD can look very similar on the page. Boxes, lines, attributes, multiplicities. That visual similarity is exactly why this debate keeps resurfacing. But appearance is not the same as purpose. Intent matters more than shape.
A grounded example: grants management across institutions and agencies
Let’s use a domain that almost everybody in EU public-sector architecture has encountered in one form or another: grants.
It is a good example because it is both data-heavy and process-heavy. There are grant programmes, calls for proposals, applicants, beneficiary organisations, evaluators, agreements, amendments, payments, recoveries, supporting documents, and audit trails. Some actors are internal, others external. Some steps happen in a portal, some in a back-office case management system, some in a finance platform, some in a document repository, and usually something ends up in a data warehouse or reporting lake.
This is also the kind of domain where people say “data model” and mean very different things.
The policy team wants to clarify business concepts and statuses.
The portal team wants to understand submission and validation steps.
The data team wants to define relational integrity.
The integration team wants canonical exchange structures.
The security team wants to know who can act in which context.
The audit people want traceability.
Same domain. Very different architectural decisions.
That is exactly why one model is not enough.
UML, but only the parts architects actually use
I am not especially interested in reciting the full UML catalog here. Most enterprise architecture teams do not use the whole language in practice, and pretending otherwise just adds ceremony. On real projects, the useful subset is usually smaller: Sparx EA maturity assessment
- class diagrams
- sequence diagrams
- activity diagrams
- state diagrams
- component diagrams, sometimes
That is more than enough to be productive.
The first thing UML contributes in enterprise architecture is semantic range. A class diagram can represent conceptual structure without collapsing immediately into table design. It can show associations, specializations, composition, constraints, and roles in a way that mixed audiences can often discuss more easily in the early stages. A state diagram can make lifecycle explicit. A sequence diagram can expose service interactions and timing. An activity diagram can be useful when process branching matters and BPMN would be overkill for the conversation. BPMN training
A practical note, though: many teams say “UML” when they really only mean class diagrams. This is one of the quieter sources of endless confusion. They ask for a UML model but really want a conceptual object view. Or they ask for a UML data model and get a set of classes that stop somewhere between business analysis and software design.
That middle ground is where misunderstandings multiply.
Class diagrams are particularly tricky because they can look deceptively similar to ERDs, especially to audiences who are not invested in notation distinctions. The same box-and-line structure appears, but the semantics are not identical, and the downstream use certainly is not.
First pass on the grants domain: where UML helps immediately
Suppose we sketch a conceptual class diagram for a grants domain with these elements:
GrantProgrammeCallForProposalProposalApplicantBeneficiaryOrganisationEvaluationGrantAgreementPayment
At this stage, the value is not in pretending we have designed the database. The value is in making meaning visible.
A GrantProgramme contains multiple CallForProposal instances. A Proposal is submitted in response to a call. An Applicant may be an organisation, a consortium lead, or, in some cases, an individual. A GrantAgreement comes into existence only after approval. A Payment belongs to an agreement but may have different types—pre-financing, interim, final settlement, recovery adjustment.
Now UML starts to show things that matter beyond storage.
You can model that a Proposal moves through statuses: draft, submitted, admissible, under evaluation, selected, rejected, contracted. That status progression is not just an attribute; it is a governed lifecycle. In institutional systems, that distinction matters because transitions have consequences: notifications, deadlines, locking rules, eligibility checks, audit records.
You can show that Evaluation is performed by actors with roles. One evaluator might be primary, another secondary, and a panel chair may confirm a consolidated result. If there is a conflict-of-interest declaration, that may sit within the evaluation process without being part of the core proposal entity itself.
You can represent specialization if there are multiple applicant types. Perhaps there are PublicBodyApplicant, ResearchInstitutionApplicant, and PrivateEntityApplicant variants with different mandatory data and validation rules. In a conceptual conversation, UML handles that quite cleanly.
You can also use composition carefully where lifecycle genuinely matters. If an EvaluationComment cannot exist independently of an EvaluationSession, that tells a different story from a loose association.
And this is where UML becomes more than a static picture.
A state diagram for Proposal can make explicit what many business discussions otherwise leave implied:
That diagram is not a database schema. For this particular conversation, it is better than a database schema. Policy and operations stakeholders usually understand this kind of view much faster than they understand normalized persistence structures.
Likewise, a sequence diagram for proposal submission across systems can expose design choices early: the applicant portal submits to a validation service, which checks eligibility rules, invokes an IAM service for user context, stores a case in a grants back office, pushes metadata to Kafka for downstream processing, and emits an event for document registration.
You do not need a textbook-perfect sequence diagram to get value from it. Even a lightweight interaction view helps answer questions like:
- Which system is authoritative at each step?
- Where are synchronous dependencies risky?
- Which validations happen before persistence, and which after?
- Where should an event be emitted?
- How does the user-facing portal remain responsive if downstream systems are slow?
In cloud-heavy environments, this matters. Teams may be splitting services across managed databases, API gateways, event brokers, and document stores. A UML interaction view can reveal whether the architecture is turning a straightforward submission into a brittle chain of synchronous calls.
But—and this is a big but—if the team stops here, they still do not have a strong database design. They have a better shared understanding of the domain in motion. That is valuable. It is not the same thing.
The same domain through an ERD lens: where the model becomes implementable
At some point, architecture has to stop being tastefully abstract and become useful to delivery.
That is where an ERD earns its keep.
Now we are no longer mainly asking what a Proposal means in business terms or how it changes state. We are asking how persistent data should be structured so that the system can actually run, report, reconcile, and survive scrutiny.
The entities often become more explicit, and sometimes less elegant:
PROGRAMMECALLPROPOSALORGANISATIONPERSONPROPOSAL_PARTICIPANTEVALUATION_RESULTAGREEMENTPAYMENT_TRANSACTIONDOCUMENT_REFERENCESTATUS_HISTORYREFERENCE_CODESET
This is also the point where some comforting simplifications disappear.
The many-to-many relationship between proposals and participating organisations is no longer a friendly line on a class diagram. It becomes an associative entity such as PROPOSAL_PARTICIPANT, possibly with attributes like role, legal status, financial share, start date, end date, and validation state.
Primary keys and foreign keys now matter. Surrogate keys versus natural keys matter. Optionality matters in stored records, not just as conceptual multiplicity. Historical snapshots versus current-state fields need explicit treatment. Lookup values and reference data stop being decorative and become operational dependencies.
Here is a simplified illustration:
This is still not a full physical design, but the center of gravity has shifted toward persistence, and that is healthy.
ERD clarifies things UML class diagrams often leave under-specified in delivery contexts:
- how many-to-many relationships are resolved
- what the actual key strategy is
- where referential integrity must be enforced
- where data duplication is tolerated or prohibited
- how temporal validity is represented
- whether status is current-state only or accompanied by a history table
- how reference data is separated from transaction data
One institutional wrinkle appears almost every time: the same organisation exists under different identifiers in different systems.
In a workshop, people often speak as if “organisation” is one single stable thing. Then the finance system uses one identifier, the participant register another, an external interoperability platform another, and historical records include previous legal names. This is exactly the point where ERD forces an uncomfortable but necessary conversation about mastering, reconciliation, cross-reference tables, and surrogate keys.
That conversation is not glamorous. It is also where project estimates start becoming real.
Because once you model identity properly, you discover whether you need a matching service, whether your MDM scope was understated, whether reporting joins will be expensive, and whether downstream systems can cope with identifier changes. None of that is visible in a high-level class diagram.
And in EU institutional environments, where reporting, auditability, and contractor handover are not side concerns, this kind of precision is not optional.
A meeting table people actually use
I like simple tools that survive contact with reality. This one usually helps.
That last row matters more than people often realise.
Where teams get this wrong — and I see this constantly
Let me be candid. Most modeling problems I run into are not caused by tools. They are caused by wishful thinking.
1. Using UML class diagrams as if they were production-ready data models
This is probably the most common issue.
The diagram looks tidy. It has boxes, attributes, and multiplicities. It feels structured enough to circulate. But then delivery starts, and basic implementation questions remain unanswered: where are the keys, how are many-to-many relationships resolved, how is history stored, what is optional at persistence level, what is the lookup strategy, how do we deal with code lists, what is the indexing implication?
A class diagram can support those discussions, certainly, but it does not magically become a logical or physical data model just because somebody exported it from Sparx or another repository tool. Sparx EA best practices
2. Using ERDs to communicate business meaning to non-technical stakeholders
This goes wrong in a different way.
People nod through the review because they recognise some terms, but they are not really discussing meaning anymore. They are looking at a structure they cannot easily challenge. The result is fake consensus. Later, business users say, “that is not what we meant by beneficiary” or “participant is not the same as applicant in all programme types,” and everyone behaves as if this were unexpected.
I am never surprised by it.
3. Mixing conceptual, logical, and physical concerns in one drawing
Deadline pressure encourages this. Outsourced projects are especially prone to it because teams try to minimise the number of artifacts. So one diagram ends up carrying conceptual business terms, logical entity relationships, physical table naming conventions, API payload hints, and implementation notes.
It becomes unreadable. Worse, it becomes misleading.
4. Trying to create one master diagram for every purpose
This is an instinct I understand and distrust.
Governance wants a single source of truth. Delivery wants practical detail. Business wants readability. Architects want traceability. The temptation is to produce one grand diagram that satisfies everyone.
It almost never does.
A good architecture repository should contain multiple views of the same domain, each with a declared purpose. That is not duplication. It is viewpoint discipline.
5. Modeling legal concepts literally without translating them into system and data responsibilities
This one is very common in institutional contexts.
A regulation or programme guide may use terms with careful legal nuance. That nuance matters. But if the architecture team copies those labels directly into models without translating them into operational responsibility and persistence rules, the implementation becomes mushy.
I once saw beneficiary, participant, applicant, and contractor treated as roughly interchangeable labels because everyone assumed the distinctions could be sorted out later. They could not. Payment integration failed because finance needed to know exactly which legal entity was entitled to receive funds, under what agreement, in which role, and with what validity period. The earlier models had not forced that precision, so the problem arrived late and expensively.
That is the pattern: vague semantics upstream, pain downstream.
The uncomfortable overlap: yes, UML class diagrams and ERDs can look similar
This is where the debate gets stuck, because both camps can point to examples that look almost identical.
Yes, both use boxes.
Yes, both can show attributes.
Yes, both can show relationships and multiplicity.
But the real dividing line is not visual. It is semantic and intentional.
A UML class may represent a conceptual object, a software abstraction, a domain concept, or part of an object-oriented design. An ERD entity is usually anchored more directly to persistent data structures, even when the ERD is still conceptual or logical rather than physical.
That difference changes how people read the model and what they expect to derive from it.
Architecture repositories often make this worse. Over time, teams borrow notation inconsistently. Somebody uses crow’s foot notation inside a class diagram. Somebody else adds database column types to a conceptual model. Another team models events as classes. Six months later, nobody is quite sure what level of abstraction they are looking at.
In my experience, the bigger problem is not notation purity. It is the discipline of naming the viewpoint.
Every diagram should say, somewhere visible:
- purpose
- intended audience
- abstraction level
- whether it is conceptual, logical, or physical
- whether it is structural or behavioral
That tiny bit of discipline prevents a surprising amount of nonsense.
A second example: identity and access in a multilingual institutional platform
Identity and access management is another useful domain because teams often underestimate how quickly it moves from process-heavy to deeply relational.
Imagine a multilingual institutional platform supporting staff users, external experts, organisation representatives, delegates, financial signatories, and auditors. Roles differ by programme, by case, and by time period. Authentication may depend on EU Login or another federated identity service. Authorization may be local, contextual, and time-bound.
In workshops, this often starts as a procedural discussion.
How is an external expert invited?
Who approves an organisation representative?
What happens when a delegate is revoked?
When does an account become active?
How are role changes audited?
For that stage, UML is very useful.
A sequence diagram can show interaction between the portal, IAM service, role management component, notification service, and audit service. A state diagram can describe account activation or delegation lifecycle. An activity view can clarify approval branching and exception paths.
But the implementation reality is relational.
A user can hold multiple roles.
A role may be valid only for a specific programme or case.
Delegation may be temporary.
Revocation history must be preserved.
Audit records need actor, target, timestamp, reason, and source system.
Some entitlements derive from organisation affiliation, others from explicit assignment.
This is where ERD becomes indispensable. You need structures such as user-role-context relationships, temporal validity records, junction entities, and history tables. If Kafka events are used to propagate role changes downstream, then the persistent model needs to support replay, sequencing, and audit consistency. If cloud IAM is federated with internal authorization logic, then the boundary between identity assertion and local access persistence must be very clear.
I have seen elegant role models drawn in UML that were impossible to persist cleanly because nobody had modeled the junction entities and time validity properly. The workflow looked neat; the storage model was a mess.
Access management looks procedural in workshops. It becomes relational in implementation.
That lesson repeats.
If you only have time for one model first, which should it be?
This is the question people ask when the schedule is already under pressure.
The honest answer is: it depends on where the risk sits.
If you are early in discovery and the bigger risk is conceptual ambiguity—policy-heavy language, uncertain business meaning, disagreement about actor roles—start with conceptual UML-oriented modeling. Get the domain language, responsibilities, and lifecycle clear enough that people stop talking past one another.
If you are mobilising delivery on a relational platform, with reporting obligations and audit requirements already known, move to ERD sooner than feels comfortable. I would rather have a slightly rough but honest logical ERD early than a polished conceptual diagram that delays hard data decisions.
If the programme is integration-heavy, do both early, but not in one artifact. Use UML interaction views to understand system choreography and a logical ERD to anchor persistent structures and shared identifiers.
A sequencing pattern I trust is simple:
- domain glossary
- conceptual UML class view
- lifecycle and interaction diagrams where they matter
- logical ERD
- physical data model
Real projects do not follow those steps neatly. Public-sector programmes are messy. Discovery overlaps with procurement. Delivery starts while governance is still refining terms. Suppliers inherit half-finished artifacts. That is fine, actually. The problem is not overlap. The problem is forgetting which question each artifact is supposed to answer.
How this plays out in governance, procurement, and vendor management
This is where enterprise architecture stops being a modeling debate and becomes operational.
Governance boards do not need notation purity. They need decision support. If the board is deciding whether the business domain has been understood, a conceptual UML view may be enough. If it is deciding whether delivery can proceed into data migration and reporting design, then a logical ERD and data ownership view are much more relevant.
Procurement is where ambiguity turns into contractual debt.
Tender documents should distinguish clearly between conceptual information models, logical data models, physical schemas, interface payload definitions, and process or lifecycle views. If the requirement simply says “supplier shall provide UML data model,” you are inviting an elegant but insufficient deliverable. And the supplier will not necessarily be wrong. They will optimise for what was asked.
Acceptance criteria should name required artifacts explicitly:
- conceptual domain model
- process or lifecycle views where relevant
- logical ERD
- interface contracts or payload structures
- traceability to business terms
- data ownership and mastering assumptions
That level of precision matters even more when systems are handed from one contractor to another. I have seen successor suppliers spend weeks reverse-engineering intentions that should have been obvious from the architecture artifacts. The institution then pays twice: once for the original delivery, and again for the rediscovery.
Vendor management has a similar dynamic. Suppliers become very good at whatever the institution consistently asks for. If you ask only for polished high-level diagrams, you will get polished high-level diagrams. If you ask only for physical schemas, you may get implementation detail with weak conceptual traceability. The architecture function needs to define a minimum modeling package per work package and hold teams to it.
In cloud and event-driven environments, I would add one more point: data models and event contracts need to be related, but not confused. A Kafka topic payload is not simply a table row in transit. It reflects integration intent, versioning strategy, and bounded context choices. UML can help express conceptual meaning and interaction; ERD can help anchor persistent truth. Both matter. Neither should pretend to be the other.
Practical rules of thumb I trust more than methodology posters
These are not elegant, but they save projects.
Don’t use ERDs to explain behavior.
Don’t use class diagrams as a substitute for relational design.
If audit, reporting, reconciliation, or migration matter, your ERD deserves serious attention early.
If stakeholder misunderstanding is the bigger risk, begin with conceptual UML.
If the same box means business object in one meeting and database table in another, stop and relabel it.
One domain may need several diagrams. That is not duplication. That is architecture.
If you cannot explain why a diagram exists, it probably should not be in the repository.
If a procurement package says “data model” without defining the abstraction level, fix that before publication.
If IAM looks simple in workshop slides, assume the persistent model is more complex than people think.
If event-driven integration is in scope, model both the interaction and the persisted source of truth. Otherwise your Kafka estate will become an expensive mythology generator.
These heuristics are less glamorous than formal modeling debates. I trust them more.
A compact comparison, without pretending symmetry
UML’s real strength is that it helps you understand the domain in motion. It is good at concepts, responsibilities, interaction, and lifecycle. It aligns reasonably well with software and service design, especially when you need to connect business understanding to component behavior. Used well, it is a bridge language.
Its blind spot is obvious: lazy use of class diagrams as ersatz data models. That is where good intentions go to die.
ERD’s strength is precision around persistence. It is excellent for keys, integrity rules, normalization, many-to-many resolution, history structures, and the kinds of decisions that determine whether reporting, reconciliation, and long-term maintainability will hold up. It is where data quality conversations become serious.
Its blind spot is equally obvious: it does not explain dynamic behavior well. It is a poor tool for showing process flow, responsibilities over time, or interaction sequencing.
So my synthesis is simple.
Use UML to understand the domain in motion.
Use ERD to make the domain durable in data.
That is usually enough to cut through most unproductive arguments.
The model review that finally went well
Let me go back to the kind of workshop I started with, because the ending matters too.
A few months after that earlier grants session, we ran another review. Same broad domain. Similar mix of stakeholders. This time, though, the team was much more explicit.
First, we showed a conceptual UML class view to establish shared meaning: programme, call, proposal, applicant, beneficiary, agreement, payment, evaluator. The labels had definitions. The relationships were there to support understanding, not to fake implementation detail.
Then we showed a state view for proposal lifecycle and a sequence view for submission and validation across the portal, IAM, validation service, and case system. Suddenly the policy people, operations colleagues, and solution teams were discussing the same thing.
Only after that did we move to the logical ERD. There, the conversation changed—as it should. Keys, associative entities, temporal validity, organisation mastering, audit tables, status history, reporting implications. The database and integration concerns stopped competing with the conceptual discussion because they finally had the right artifact.
The result was not perfection. It never is.
But governance decisions were cleaner. Procurement language improved. Vendor handover became less risky. Rework in reporting and integration dropped because assumptions were visible earlier. People disagreed where they should disagree, instead of hiding behind diagrams that meant different things to different readers.
That is the real goal.
The right tool is not chosen by notation loyalty. It is chosen by the architectural decision in front of you.
And in EU institutional environments—where systems often outlive programmes, contracts, and even organisational structures—that discipline is not academic. It is operational resilience.
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.