Enterprise Data Modelling by Pull
Strategic Article
Enterprise data modelling has traditionally been constrained by the time, cost and cognitive effort required to create and validate a coherent model across a whole organisation. Artificial intelligence changes the economics of generation, but not the need for human judgement. A plausible enterprise model can now be generated rapidly; trustworthy organisational meaning still has to be governed, challenged and validated by people who understand the work.
This article proposes Human–AI Kanban Architecture to reconcile those two realities. It first establishes an enterprise-wide conceptual map. Then pull detailed semantic validation through manageable Level 3 (L3) subject areas, using accountable Data Stewards and people working in the Gemba.
Establish and govern the enterprise map first; progressively validate the street map through L3 Gemba pull.
1. Why the Enterprise Map Comes First
A local data model can be correct within its immediate context and still be wrong for the enterprise. If detailed modelling begins independently in separate functions, systems or projects, the organisation risks accumulating locally sensible but mutually inconsistent definitions, duplicated concepts and incompatible relationship structures.
The analogy is straightforward: before navigating individual streets, we need a map of the highways. Enterprise modelling therefore starts by establishing the larger context and the crucial semantic relationships that hold the organisation together. Only then should we pull detailed areas into deeper validation.
This is not a return to the old idea that the entire enterprise model must be exhaustively completed before it is useful. Human–AI modelling lets you generate a broad conceptual structure quickly. Kanban Architecture then governs the flow of detailed validation.
2. Two Terms Used in This Article
Kanban. A pull-based method for managing work so that the next item is taken on when there is need and capacity, rather than forcing all work through a predetermined batch or project sequence. In this article, Kanban is applied to architecture: detailed modelling and validation are pulled into work in manageable increments while remaining connected to a coherent enterprise model.
Gemba. A Japanese term meaning the actual place where work happens and reality can be observed. In this article, Gemba validation means testing modelled meaning with the people, decisions, exceptions, transactions and conditions found in real operational practice, rather than relying only on documentation or workshop consensus.
Other modelling terms used in this article — including Common Data Model, Business Object, Entity Type and Subject Area — should be read in conjunction with the Adapt, Survive and Flourish Glossary.
Business Object is used in the ArchiMate sense: a significant concept used within a business domain.
3. Governance Is a Precondition, Not an Afterthought
Human–AI data modelling should not begin with a prompt. It begins with governance. The faster AI can generate candidate structures, the more important it becomes to know who is accountable for deciding what is accepted, rejected, challenged or sent back for further validation.
| Foundation | Purpose |
| Enterprise governance | Sets decision rights, modelling standards, controls, change authority, provenance requirements and the rules by which the knowledge base is maintained. |
| Executive BCM ownership | Establishes accountable owners for business capabilities. Initial ownership may follow the current organisational hierarchy, but this is a starting hypothesis rather than a permanent architectural truth. |
| Data Stewardship | Establishes named people accountable for semantic integrity: entity meaning, relationship meaning, definitions, business rules, exceptions and stewardship decisions. |
| Training | Ensures key personnel understand the Knowledge Operating System (KOS), the Human–AI Knowledge Base (HAK) approach, governance responsibilities and the level of data-modelling literacy required to challenge AI-generated structures. |
| Repository discipline | Ensures approved definitions, relationships, validation status, provenance, decisions and versions are preserved in a governed modelling environment. |
Without governance and accountable Data Stewards, AI does not accelerate data modelling; it accelerates data-modelling chaos.
4. Capability Ownership and Data Stewardship
The Business Capability Model (BCM) and the data model require complementary forms of accountability. At the executive level, capability owners are established so the organisation knows who is accountable for a capability’s meaning, performance, and evolution. Initially, those assignments may reasonably follow the current organisational hierarchy because formal authority already exists there.
However, capability ownership should not be confused with the organisation chart. As the enterprise model matures, it may reveal that a capability crosses organisational boundaries, accountability is fragmented, or nominal ownership does not match where the work, knowledge, decisions, and risks actually sit. Ownership can therefore be refined over time.
Data Stewards operate alongside capability owners. Their accountability is semantic integrity. They are not expected to become specialist career data modellers, but they must be trained enough to question definitions, entities, relationships, roles, subtypes, cardinalities, business rules, and exceptions, and to know when an issue requires Gemba validation.
5. The Human–AI Kanban Architecture Flow
The proposed flow is deliberately front-loaded with governance and enterprise context, followed by enterprise semantic modelling, and only then by detailed pull-based validation.
- Governance framework established
- Executive BCM owners, responsibilities and decision rights established
- Data Steward roles, accountabilities and decision rights established
- Key personnel trained in KOS, HAK and the governance approach
- Data Stewards trained in data modelling to the level required by the Human–AI KB Guideline
- Enterprise context established
- BCM L1 validated
- Stakeholder Value Propositions validated
- Enterprise Value Chain validated
- BCM L3 capability definitions and KPIs validated
- Business Objects identified and validated with Data Stewards
- Candidate high-level relationships between Business Objects identified and reviewed with Data Stewards
- Established and candidate enterprise patterns identified and tested
- Enterprise Business Object View of the Common Data Model generated and validated
- L3 Subject Areas established, each with one Home L3 Capability and one Root Entity Type
- One L3 Subject Area pulled for detailed Gemba validation
- Entity Types, relationships, rules, cardinalities, optionality, subtypes, lifecycle conditions and exceptions validated
- Governance and stewardship decisions recorded
- Governed model and repository updated
- Affected enterprise and subject-area views regenerated
- Next L3 Subject Area pulled when there is business need and validation capacity
Generate the whole semantic landscape; validate detailed meaning by pull.
6. The Business Object View of the Common Data Model as the Enterprise Semantic Map
The Business Object View of the Common Data Model is established before detailed Subject Area work because the organisation needs a coherent, mind-sized view of the major things it deals with and the crucial relationships between them. This is the enterprise semantic skeleton: the equivalent of the highway map.
At this stage, the purpose is not to settle every detailed Entity Type, attribute, cardinality, exception or lifecycle rule. It is to establish the major Business Objects and the high-value relationships that connect them. Detailed logical modelling proceeds through L3 Subject Areas while remaining part of the same governed Common Data Model.
Candidate Relationships should deliberately surface important distinctions that organisations often blur. Product–Asset is one example: what the enterprise offers is not necessarily the same thing as the asset it owns, controls, accesses, maintains or uses to provide that offering. Making that distinction explicit early can prevent downstream confusion in systems, reporting and governance.
7. Patterns: Reuse Without Turning Modelling into Dogma
Human–AI modelling creates an opportunity to recognise recurring semantic structures across the enterprise. These can be treated as patterns, but with an important distinction between established patterns and candidate patterns.
An established pattern is a structure the organisation has enough evidence to test and reuse deliberately. A candidate pattern is a recurring structure AI detects or proposes that requires human review before adoption. The Stakeholder Pattern is an example of a structure that can prevent repeated reinvention of roles and relationships in separate subject areas.
AI can therefore assist by asking a useful question rather than declaring a conclusion: “This semantic structure appears in several areas. Is it one enterprise pattern?” Data Stewards decide whether the proposed pattern is meaningful, misleading or context-dependent.
8. L3 Subject Areas as Cognitive Work-in-Progress Limits
The enterprise model can be large because machines can hold and regenerate large structures. Human validation cannot operate effectively at that scale. People need a sufficiently bounded area where they can see the relationships, challenge assumptions, and recognise exceptions without losing the wider context.
Each L3 Subject Area has one Home L3 Capability and one Root Entity Type. It includes the Root Entity Type, its materially dependent Entity Types, and only those peripheral Entity Types needed to understand and validate the root-centred semantic structure. Peripheral Entity Types retain their canonical ownership elsewhere in the Common Data Model.
L3 Subject Areas provide that manageable unit of work. They act as a cognitive work-in-progress limit: small enough for meaningful discussion, but connected to the enterprise-wide Common Data Model and its Business Object View so that local decisions do not drift away from the whole.
This is where Kanban Architecture becomes operational rather than metaphorical. A Subject Area is pulled because of a business need, a risk, a change, a project, a known ambiguity, or available validation capacity. Detailed validation is not performed merely because the model contains an unfinished corner.
9. Gemba Validation: Where the Model Meets Reality
Detailed modelling becomes organisational learning when you test relationships against real work. A relationship that appears obvious on a diagram often contains hidden conditions once practitioners are asked how it actually works.
For example, a model may show that an Order contains an Order Line and that an Order Line references a Service. Gemba validation then asks:
- How is the service priced?
- Is there one price or many?
- Can sales negotiate a lower rate?
- Under what authority?
- What date determines the applicable rate?
- How are commissions affected?
- What happens when the service changes after the order is placed?
The purpose is not merely to make the diagram more detailed. The purpose is to expose meaning, rules, exceptions and consequences that matter to the organisation.
10. Division of Labour Between Humans and AI
The approach depends on a clear division of labour. AI is well suited to rapid generation, pattern detection, relationship proposals, consistency checking, impact analysis and regeneration of affected views. Humans remain responsible for meaning, accountability, judgement and validation of operational reality.
| AI is strong at | Humans remain accountable for |
| Generating candidate enterprise structures at machine scale | Deciding whether those structures represent organisational meaning |
| Detecting recurring patterns and inconsistencies | Approving, rejecting or reframing proposed patterns |
| Producing candidate relationships and subject-area views | Testing those relationships against Gemba reality |
| Regenerating affected views after a change | Making governance and stewardship decisions |
| Maintaining broad coherence across a large model | Accepting accountability for the consequences of meaning |
AI generates breadth. Data Stewards govern meaning. Gemba establishes reality. The repository preserves organisational knowledge.
11. The Model as a Visible Validation Backlog
Once the enterprise Business Object View of the Common Data Model exists, its unresolved semantics become a visible backlog of knowledge work. Relationships, rules and definitions can carry explicit validation states rather than being treated as either “modelled” or “not modelled”.
A practical state model might include:
Proposed → Steward Reviewed → Enterprise Semantically Validated → Awaiting Gemba → Gemba Validated → Governed.
Additional states such as Disputed, Exception Identified or Requires Investigation can be used where needed.
This turns the model from a static documentation artefact into a learning control system. The organisation can see what it currently believes, what has been validated, what remains uncertain and where further investigation is required.
12. Regeneration Changes the Economics of Architecture
Traditional architecture programmes often treat regeneration as expensive rework. Human–AI architecture changes that assumption. When a stakeholder outcome, capability definition, business rule or semantic relationship changes, affected views can be regenerated and compared rather than manually reconstructed.
This is central to Kanban Architecture. The architecture does not have to be frozen so that people can keep up with it. Instead, the governed knowledge base can evolve while validation proceeds at human scale. Change becomes something to trace, compare and learn from rather than something to avoid because the diagrams are too expensive to maintain.
13. Implications for Data Stewardship
The Data Steward role becomes more substantial than maintaining dictionary entries or reviewing data-quality metrics. A steward becomes an accountable participant in enterprise meaning. The practical skill required is not advanced notation; it is the ability to interrogate a model.
A steward should be able to ask: What exactly does this entity type mean? Is it distinct from that one? Is this a role or a party? Does this relationship always exist, or only under certain conditions? Are Product and Asset being confused? Is the model describing a type or an instance? What changes over time? What are the exceptions? Who in the Gemba actually knows?
The data-modelling section of the Human–AI KB Guideline can therefore serve as the basis for a practical Data Steward working aid: not a simplified modelling methodology, but a disciplined set of prompts for challenging semantic meaning.
14. Conclusion
Human–AI Kanban Architecture is not “AI doing data modelling”. Nor is it simply a traditional enterprise data-modelling project completed faster. It is a different operating model for architectural knowledge.
The enterprise-wide Business Object map is generated and governed first. Accountable executives own capabilities. Data Stewards own semantic integrity. Detailed L3 Subject Areas are then pulled into Gemba validation as business need and human capacity require. Validated knowledge returns to the governed model, affected views regenerate, and the cycle continues.
The enterprise map provides coherence.
- Kanban provides flow.
- Gemba provides truth.
- Governance provides accountability.
Human–AI Kanban Architecture: generate holistically, validate where needed, when it’s needed by ‘pull’.