What it is
Data modelling is more than drawing diagrams that represent data.
It is the structured negotiation, clarification and governance of shared meaning across an organisation.
A data model represents the organisation’s shared understanding of its world:
- what the things are that the organisation deals with,
- how they relate to each other and capability,
- what matters about them,
- how they change,
- who is accountable for their meaning,
- and how the results of organisational activity are represented in data.
The model is therefore not simply a technical artefact.
It is part of the organisation’s Knowledge Base.
At its best, data modelling creates a coherent semantic structure that connects people, capabilities, processes, systems, information, reporting, analytics and AI around a common understanding of organisational reality.
When meaning fragments, communication breaks down, silos harden, interpretations polarise and coordinated action becomes increasingly difficult.
Why shared meaning matters
Most organisations do not suffer from a shortage of data. They suffer from fragmented meaning.
Different parts of the organisation may use the same word differently:
- Customer
- Product
- Asset
- Agreement
- Service
- Risk
- Incident
- Capability
At the same time, several different terms may be used for the same underlying concept.
This produces:
- inconsistent definitions,
- competing and confusing reports,
- duplicate data,
- integration complexity,
- local workarounds,
- weak Data Quality Management,
- confused accountability,
- and poor decision quality.
Over time, different parts of the organisation develop their own interpretation of reality.
- Systems reinforce those interpretations.
- Processes embed them.
- Reports reproduce them.
- AI may then analyse or regenerate them at even greater scale.
The result is not merely poor data quality. It is organisational fragmentation.
Fragmented meaning produces fragile, fragmented organisations.
Data models are organisational meaning systems
A well-developed common data model provides stable reference points for:
- shared language,
- definitions,
- relationships,
- governance,
- organisational memory,
- data quality,
- analytics,
- system integration,
- AI use,
- and organisational learning.
Stability is crucial as:
- Systems may change.
- Applications may be replaced.
- Processes may evolve.
- Organisational structures may be reorganised.
Yet many of the core things that the organisation deals with remain comparatively stable.
Consider the data used by the Bank of New South Wales in 1910.It had:
- Branches
- Customers
- Accounts
- Agreements
- Transactions
- Loan Applications
- Transaction and Customer Risks
A modern bank deals with the same concepts such even though the technology used and processes to manage them may be completely different from those used by the Bank of New South Wales a century earlier.
This relative stability is why the Business Capability Model and the Common Data Model form such important part as the stable foundation of the organisational Knowledge Base.
The BCM provides a stable view of what the organisation must be capable of doing.
The data model provides a stable view of what the organisation deals with and how those things relate.
Together, they provide structure for organisational meaning.
Shared meaning comes before technology
Vendor platforms such as SAP, Oracle, Salesforce and others contain sophisticated internal data structures.
Those structures are necessary for the software to work.
They are not automatically the organisation’s shared mental model.
Vendor data models reflect:
- software functionality,
- generic industry assumptions,
- technical constraints,
- accumulated implementation patterns,
- and the mental models of external designers.
They may be excellent.
But they do not automatically represent:
- local organisational language,
- stakeholder meaning,
- governance boundaries,
- operational exceptions,
- tacit knowledge,
- or the lived reality of work.
Without an enterprise semantic model, the organisation can gradually adapt its language and assumptions to the software rather than the software being aligned to organisational meaning.
Applications support operations. The Knowledge Base preserves organisational meaning.
Governance comes before modelling
Human–AI data modelling should not begin with AI generating an ERD.
It begins with governance. Before enterprise modelling can be trusted, several foundations need to exist.
Enterprise Governance establishes decision rights, standards, controls and the mechanisms through which changes to organisational knowledge are accepted.
Business Capability Model ownership establishes executive accountability for capabilities. Initially, this may reasonably follow the existing organisational hierarchy.
That is a practical starting point, not a permanent assumption.
As the architecture develops, capability ownership may need to change to reflect end-to-end responsibility, value flow and operational reality rather than organisational silos.
Data Stewardship establishes named people who are accountable for semantic integrity and data quality.
Data Stewards need sufficient modelling literacy to:
- review AI-generated structures,
- challenge entity definitions,
- question relationships,
- identify ambiguity,
- recognise modelling patterns,
- and determine when deeper Gemba validation is required.
The objective is not to turn every Data Steward into a specialist professional data modeller.
The objective is to enable them to ask:
“Does this model actually mean what we think it means?”
Without governance, ownership and accountable Data Stewards, AI does not remove modelling complexity.
It will accelerate data modelling chaos.
The Conceptual Data Model — the enterprise highway map
Before detailed modelling begins, the organisation needs an enterprise semantic map.
This is the role of the Conceptual Data Model.
The Conceptual Data Model establishes:
- Principal Entities,
- important Secondary Entities,
- significant relationships,
- common definitions,
- and recurring semantic patterns.
It provides the enterprise-wide view before detailed modelling is undertaken within particular Subject Areas.
The analogy is simple: Map the highways before drawing the street maps.
Without the enterprise map, local models may each be internally correct yet collectively inconsistent.
The organisation then ends up attempting to assemble an enterprise model from disconnected local views.
The Conceptual Data Model reverses that.
It establishes coherence first.
Principal Entities and enterprise patterns
Principal Entities represent the major things the organisation deals with.
Secondary Entities are introduced where they are needed to clarify important properties, roles, events, classifications or lifecycle states.
The relationships between entities are often where much of the organisation’s meaning sits.
Some of those relationships may form recurring patterns. These should not be assumed in advance; they should emerge from modelling and then be tested.
For example, the organisation may discover a recurring Stakeholder structure in which a Stakeholder participates in different roles and relationships with other Principal Entities. Rather than independently modelling Customer, Supplier, Employee, Partner and similar concepts in isolation, the model can test whether they share a common underlying structure.
Similarly, exploring potential relationships is one of the first tasks in data modelling. In our banking example, we might explore:
- Stakeholder to Account
- Account to Product
- Agreement to Account
- Transaction to Account
- Loan Application to Agreement
- Application to Transaction Risk
These relationships are not accepted simply because they appear plausible. They are candidate relationships to be examined, clarified and validated.
AI can help detect recurring structures, suggest candidate relationships and identify possible patterns across the enterprise model. These remain hypotheses until reviewed and validated by Data Stewards.
Patterns are discovered and tested, not imposed.
Relationships between Principal and Secondary Entities are where much of the organisation’s meaning becomes visible. Some may reveal recurring patterns or important distinctions that need to be tested and governed. AI can help identify candidate structures and relationships, but these remain hypotheses until reviewed and validated by Data Stewards.
They are hypotheses to be tested.
AI may detect recurring structures and ask: “Is this the same semantic pattern appearing in several areas?”
Data Stewards determine whether it is.
Many-to-many relationships are questions
Many-to-many relationships are often useful during early discovery.
They should not normally survive unquestioned into a governed Conceptual Data Model.
An unresolved M:M relationship often hides an important business concept.
For example:
Stakeholder M:M Role
may actually represent:
Stakeholder → Stakeholder Role Assignment → Role
The thing in the middle may carry meaning such as:
- effective dates,
- status,
- authority,
- jurisdiction,
- organisational context,
- approval,
- lifecycle,
- or source.
Similarly:
Product M:M Asset
may conceal a meaningful Product–Asset relationship with its own definition and rules.
For this reason:
A many-to-many relationship is a question, not an answer.
A useful Data Steward challenge is:
“What is the thing in the middle?”
The answer often reveals organisational meaning that would otherwise remain hidden.
Data modelling is storytelling made explicit
At its core, data modelling is also a way of making organisational stories explicit.
Consider a simple retail story.
Jenny places an order for a Victa Model 350 Electric lawnmower.
That story contains concepts such as:
- Customer
- Order
- Order Line
- Product
and relationships such as:
- Customer places Order
- Order contains Order Line
- Order Line references Product
The conceptual model describes the meaning.
The physical implementation records the actual instance:
Jenny, Order A456, Product 7658, quantity one, pickup, delivery date, and so on.
This illustrates two important levels.
Conceptual — the organisation’s shared understanding of its world.
Physical — how that understanding is realised in systems, files and databases.
The critical issue is alignment.
When physical systems drift away from the conceptual model, the system no longer reflects organisational meaning accurately.
The consequences appear in:
- operational workarounds,
- data quality problems,
- reporting inconsistency,
- integration failure,
- and poor decisions.
Subject Areas make complexity human-sized
An enterprise Conceptual Data Model will contain a large number of entities, their attributes and their relationships.
Humans cannot validate them all at once.
Detailed modelling therefore proceeds through Subject Areas.
A Subject Area is a coherent, mind-sized portion of the Common Data Model that can be examined by the people who understand the operational reality.
This is where the emerging idea of Human–AI Kanban Architecture becomes important.
The Common Data Model provides the whole landscape.
Subject Areas provide manageable units of human validation.
AI may generate at machine scale. Humans can only validate at human scale.
AI can produce model in 15 minutes that could take humans 15 months to validate.
The Subject Area becomes a cognitive work-in-progress limit.
An enterprise Conceptual Data Model establishes the broad semantic map of the organisation: its major entities and their important relationships.
The Common Data Model develops from this foundation as a mosaic of detailed, validated Subject Areas.
Humans cannot validate the whole Common Data Model at once.
Detailed modelling therefore proceeds through Subject Areas.
A Subject Area is a coherent, mind-sized portion of the Common Data Model that can be examined in detail by the people who understand the operational reality.
This is where the emerging idea of Human–AI Kanban Architecture becomes important.
The Conceptual Data Model provides the enterprise landscape.
Subject Areas progressively build and validate the Common Data Model.
AI may generate at machine scale. Humans can only validate at human scale.
AI can produce in 15 minutes a model that may take humans 15 months to properly validate.
The Subject Area becomes a cognitive work-in-progress limit.
That also gives us a much sharper three-level distinction:
Conceptual Data Model = enterprise map
Subject Areas = mind-sized detailed slices
Common Data Model = governed mosaic of validated Subject Areas
Gemba establishes operational reality
Gemba, originating in the Toyota Production System tradition, refers to the actual place where work happens and where reality can be observed.
Models must eventually be tested there.
At Gemba, apparently simple relationships often reveal complexity.
For example:
- Can a Product have several prices?
- Can sales negotiate a different price?
- Who has authority to approve that?
- Which price applies to an Agreement?
- How does the price affect commission?
- Can a Stakeholder hold several Roles simultaneously?
- When does a Role begin or end?
- What happens when an Asset changes ownership?
These questions expose:
- business rules,
- cardinalities,
- subtypes,
- exceptions,
- lifecycle conditions,
- hidden authority,
- and tacit knowledge.
The model becomes more accurate through this process.
More importantly, the organisation develops shared understanding.
AI can propose relationships. Gemba establishes operational reality.
Data modelling as socialisation
Strong models are rarely created in isolation.
The modelling process itself creates organisational learning through:
- dialogue,
- challenge,
- storytelling,
- negotiation,
- reflection,
- and validation.
Different organisational domains contribute different views.
For example:
- Product tells the formulation story.
- Regulatory defines constraints.
- Marketing contributes the customer lens.
- Operations describes execution.
- Finance introduces pricing and accounting meaning.
- Risk introduces obligations, exposure and consequence.
These stories should not simply be merged mechanically.
They need to be reconciled.
That process surfaces:
- assumptions,
- contradictions,
- competing definitions,
- unspoken rules,
- and tacit knowledge.
This aligns closely with SECI and the development of shared mental models.
The model is not the outcome. Shared understanding is.
What data modelling reveals — and why governance is necessary
Data modelling often exposes organisational problems that are otherwise difficult to see.
These problems are not resolved by better diagrams alone.
Governance establishes ownership, decision rights, stewardship, controlled change and escalation. It also has a key educational role: ensuring that the people responsible for capabilities, data and decisions understand the concepts, standards and modelling practices they are expected to govern.
Without governance, the same issues simply reappear in different systems, reports and business units.
Competing definitions
Different areas use the same concept differently.
The result may be:
- conflicting reports,
- inconsistent systems,
- disputes about meaning,
- and poor decision quality.
The intervention is to surface and negotiate meaning explicitly, then assign accountable ownership for the agreed definition.
Conceptual–physical drift
Drift occurs when the organisation’s systems and physical data structures no longer reflect the agreed concepts, definitions and relationships in the conceptual model.
The result is:
- different systems representing the same concept differently,
- duplicated or conflicting data,
- manual reconciliation and workarounds,
- increasing integration complexity,
- inconsistent reporting and decisions,
- and operational friction.
The intervention is to identify where physical implementations have diverged from the governed conceptual model and realign them through Data Stewardship, system change and Gemba validation.
Fragmented meaning
Different domains develop incompatible local interpretations.
The result is organisational fragmentation, siloed thinking and local optimisation.
The intervention is shared modelling and structured socialisation, supported by governance that establishes common definitions and resolves conflicts across organisational boundaries.
Hidden definition power
Some people or functions effectively control organisational definitions without that authority being explicit.
The result is invisible decision power.
The intervention is to make semantic ownership, Data Stewardship and decision rights explicit.
Abstraction risk
A model simplifies reality too aggressively.
Important exceptions, edge cases or stakeholder consequences disappear.
The intervention is Gemba testing against real scenarios and boundary conditions, with governance determining how exceptions, risks and unresolved issues are recorded and acted upon.
Data modelling exposes ambiguity. Governance determines how that ambiguity is resolved, owned and controlled over time.
Data modelling and ethics
Modelling involves decisions about:
- what is included,
- what is excluded,
- whose perspective matters,
- what is classified,
- what distinctions are recognised,
- and what complexity is simplified.
These choices influence operational and stakeholder outcomes.
They are therefore not purely technical decisions. They have ethical consequences.
The modeller and Data Steward need to ask:
- Who benefits from this definition?
- Who may be excluded?
- What assumptions have been embedded?
- What consequences become invisible because of abstraction?
- Whose operational reality has been represented?
Data modelling is therefore also an exercise in responsible organisational sensemaking.
Data Quality Management depends on meaning
Traditional Data Quality Management often focuses on:
- accuracy,
- completeness,
- consistency,
- validity,
- timeliness,
- and duplication.
These measures are important.
But they depend on something more fundamental.
What does correct mean?
A shared data model defines:
- what the entity is,
- which attributes belong to it,
- what relationships are valid,
- which values are allowable,
- who is accountable,
- and what rules apply.
Without shared meaning, DQM becomes reactive.
Teams repeatedly clean, reconcile and reinterpret data without addressing the semantic cause.
With governed meaning:
- quality expectations become explicit,
- ownership becomes visible,
- issues can be prevented at source,
- and DQM becomes proactive.
You cannot sustainably manage data quality without managing meaning.
Human–AI data modelling
AI changes the economics of modelling.
It can rapidly generate candidate:
- entities,
- definitions,
- relationships,
- patterns,
- Subject Areas,
- business rules,
- alternative structures,
- and downstream impacts.
The bottleneck is no longer primarily model generation. The bottleneck is trustworthy validation.
This leads to the central Human–AI principle:
AI may generate at machine scale. Humans validate at human scale.
AI can infer, synthesise and propose meaning from large bodies of explicit knowledge.
It is not, however, the organisational authority for determining whether that meaning reflects operational reality.
That authority remains with accountable humans.
The division of responsibility is therefore:
- AI generates and proposes.
- Data Stewards govern semantic integrity.
- BCM Owners govern capability accountability.
- Gemba validates operational reality.
- Governance establishes decision rights and control.
This is a stronger model than treating AI merely as an apprentice.
AI can operate at extraordinary breadth and speed.
The challenge is to ensure that machine-scale generation is bounded by human-scale validation.
Human–AI Kanban Architecture
The emerging Human–AI Kanban Architecture approach extends this logic.
Rather than attempting to completely validate the enterprise model before it can be used:
- establish the enterprise semantic landscape,
- govern the Conceptual Data Model,
- identify mind-sized Subject Areas,
- pull the next area according to business need,
- validate it at Gemba,
- capture rules, exceptions and relationships,
- update the governed repository,
- regenerate affected views,
- then pull the next area.
This changes enterprise modelling from a large project seeking eventual completion into an ongoing organisational learning system.
Generate holistically. Validate by pull. Learn continuously.
The full method is developed in:
SA — Human–AI Kanban Architecture: Enterprise Data Modelling by Pull
The governed model becomes organisational memory
Once validated knowledge is returned to the governed repository, the architecture becomes more than documentation.
It becomes part of the organisational Knowledge Base.
Changes in:
- stakeholder outcomes,
- capabilities,
- entity definitions,
- business rules,
- relationships,
- and operational assumptions
can be incorporated into the governed model.
Affected views can then be regenerated and reconsidered.
The architecture therefore becomes dynamic.
- Not disposable.
- Not shelfware.
- Not rebuilt from scratch every few years.
It becomes a maintained representation of organisational understanding.
This strengthens:
- organisational memory,
- governance,
- integration,
- learning,
- adaptation,
- and resilience.
Practical application
A practical sequence is:
Governance established
→ Executive BCM ownership established
→ Data Stewardship established
→ Relevant personnel trained
→ Enterprise Context understood
→ BCM L1 validated
→ Stakeholder Value Propositions validated
→ Enterprise Value Chain validated
→ BCM L3 definitions and KPIs validated
→ Principal Entities identified and validated
→ Candidate Relationships identified and reviewed
→ Enterprise patterns identified
→ Conceptual Data Model governed
→ Subject Areas defined
→ Pull next Subject Area
→ Gemba validation
→ Capture rules, relationships and exceptions
→ Update governed repository
→ Regenerate affected views
→ Repeat
The detailed mechanics belong in the Human–AI Business Modelling / Knowledge Base Guideline.
This Subject Area establishes the principle.
Where it fits
Data modelling supports several organisational pathways.
For executives, it provides:
- clearer accountability,
- better decision integrity,
- stronger governance,
- reduced fragmentation,
- and a stable enterprise semantic foundation.
For Data Stewards and practitioners, it provides:
- common language,
- explicit ownership,
- disciplined relationship modelling,
- proactive DQM,
- and a basis for system alignment.
For transformation, it provides:
- a stable semantic anchor while systems and structures change,
- visibility of dependencies,
- and protection against conceptual–physical drift.
For Human–AI knowledge development, it provides:
- a governed semantic structure that AI can use, regenerate and extend without losing organisational coherence.
Closing thought
A data model is not simply a diagram.
It is a governed record of how an organisation understands its world.
Its value lies not only in the structure produced, but in the conversations, challenges and shared understanding developed while creating and validating it.
A data model is a record of a conversation about reality — and the consequences of how that reality is defined.