Human–AI Knowledge Development

The Paradigm Shift

For more than forty years, Enterprise Architecture has largely been practised as a project-based discipline.

Teams of specialists produced Business Capability Models, process models, data models and architectural artefacts over weeks or months. These were reviewed, approved and published before gradually becoming outdated as the organisation continued to evolve.

Architecture therefore became a snapshot of organisational understanding at a point in time.

Artificial Intelligence changes that completely.

Business Capability Models, Business Objects, Data Subject Areas, Common Data Models, Value Streams and ArchiMate viewpoints that once required months of specialist effort can now be generated and regenerated in minutes.

This fundamentally changes the bottleneck.

The challenge is no longer producing architectural artefacts.

The challenge becomes developing the organisational capability required to validate, govern and continuously regenerate organisational knowledge.

Architecture therefore moves from document production to knowledge stewardship.

The old paradigm

Traditional Enterprise Architecture often resembled batch manufacturing.

• Projects were commissioned to address a business challenge
• Architects analysed the organisation.
• Models were produced.
• Documents were reviewed.
• Architecture was published.
• The organisation changed.
• The process was repeated when the next issue demanded ‘architecture’.

Frequently, many of the same architectural artefacts were recreated, updated, replaced or lost as knowledge gradually became obsolete.

This was not a continuous learning system. It was a periodic documentation process.

The architecture represented organisational understanding at a point in time. Between projects, the organisation continued to evolve while the architecture increasingly drifted away from operational reality.

The new paradigm

Kanban Architecture introduces a different model.

It does not attempt to model everything in full detail all the time. Instead, it begins from a dynamic organisational knowledge base and pulls the level of architectural detail required to address a real business question, decision or problem.

A business issue creates demand.

The relevant capability, value stream, Data Subject Area, Business Object, process, business rule or scenario view is then generated or refined to the necessary level of detail.

That view is tested with the people who understand and experience the work, validated against Gemba, used to support the decision or resolve the issue that initiated it, and then returned to the repository as improved organisational knowledge.

The organising principle changes from project delivery to continuous flow.

Architecture is no longer produced as a periodic artefact for later reference.

It becomes architecture of the business, developed with the business, governed by the business, used by the business, and continually regenerated for the regeneration of the business.

This is Kanban Architecture.

🤿For a deeper dive, see the following:

• Source Note — Kanban Architecture

The Human–AI Knowledge Base

Kanban Architecture depends on a living organisational knowledge base.

The Human–AI Knowledge Base provides that foundation.

It is not a document library, a set of project artefacts or a collection of disconnected models. It is a continuously developing representation of what the organisation currently understands about itself, its stakeholders, its value, its capabilities, its information, its decisions, its consequences and its operating reality.

The Human–AI Knowledge Base is developed through a repeating cycle:

→ Candidate Stakeholders

→ Stakeholder Outcomes and KPIs

→ Value Propositions and Value Chain

→ BCM L1 and Capability Pledges

→ BCM L2/L3, KPI and Data

→ Gemba Validation

→ Learn, Reframe and Revise

The sequence shows the dominant direction of inquiry, but it is not a waterfall. Each stage creates questions for the others.

• A stakeholder conversation may reveal a missing outcome.
• A value stream may expose a capability that has been overlooked.
• A capability pledge may reveal disagreement about what a capability is expected to deliver.
• A Data Subject Area may expose inconsistent definitions, unclear ownership or missing business rules.
• Gemba may demonstrate that the original framing was wrong.

The cycle therefore moves backwards, forwards and across the Knowledge Base as understanding develops.

The entire cycle operates within Purpose, Ethics and Governance.

Figure 1: Human AI Knowledge Base Cycle

Enterprise Architecture sits within this cycle.

It provides structural representations of the knowledge being developed: Business Capability Models, Value Streams, Business Objects, Data Subject Areas, Common Data Models, ArchiMate viewpoints, process views, relationship models and glossary structures.

These are not separate artefacts maintained independently.

They are different views of the same governed organisational knowledge.

This changes the role of Enterprise Architecture.

Enterprise Architecture does not produce knowledge by itself. It helps make emerging organisational knowledge visible, structured, testable, reusable and governable.

The Knowledge Base is the living system.

Enterprise Architecture is one of the ways that system sees, organises and remembers what it is learning.

Architecture becomes organisational infrastructure

Within the Human–AI Knowledge Base,

• Business Capability Models,
• Business Objects,
• Data Subject Areas,
• Value Streams,
• ArchiMate viewpoints,
• Business Rules,
• Glossary definitions,
• Scenario Profiles,
• and architectural diagrams

all become different representations of the same governed organisational knowledge.

The repository—not the diagram—is the semantic source of truth.

Enterprise Architecture as Knowledge Representation

Enterprise Architecture provides the structural representation of organisational knowledge within the Human–AI Knowledge Base.

It does not create the entire Knowledge Base by itself.

The Knowledge Base also includes stakeholder experience, purpose, ethics, governance, value propositions, Gemba evidence, assumptions, decisions, dialogue, consequences and organisational learning. Enterprise Architecture gives this knowledge a stable structure so it can be seen, tested, reused, governed and regenerated.

In this sense, Enterprise Architecture is not the destination. It is one of the ways the organisation represents what it is learning.

The main architectural representations are:

Business Capability Model

The Business Capability Model describes what the organisation must be capable of doing.

It provides a stable view of organisational capability that is independent of the current organisation chart, systems, projects and processes. Capabilities usually remain recognisable even when technologies, structures and workflows change.

Within the Human–AI Knowledge Base, the BCM helps organise accountability, ownership, capability pledges, performance measures, activities, Data Subject Areas and change priorities.

• At Level 1, the BCM provides an executive view of the major domains of organisational responsibility.
• At Level 2, it provides a management view of related capability groups.
• At Level 3, capability, data, activity, measurement, ownership and Gemba validation begin to converge.

This makes the L3 capability a critical point of organisational learning.

Common Data Model

The Common Data Model describes what the organisation must understand and manage.

Where the BCM asks: What must the organisation be able to do?

the CDM asks: What must the organisation know, define, distinguish, relate and govern?

The CDM provides semantic coherence. It establishes common meaning for important business concepts, relationships, rules and definitions.

This matters because many organisational problems stem not from a lack of data. They stem from conflicting meanings, duplicated definitions, unclear ownership, and untested assumptions.

In the Human–AI Knowledge Base, the CDM is not a giant diagram to be admired from a distance. It is an integrated semantic structure that supports shared understanding, decision-making, governance and learning.

Business Objects

Business Objects provide the high-level enterprise semantic anchors of the Knowledge Base.

They represent important business concepts such as Product, Asset, Agreement, Stakeholder, Location, Application, Order or Service.

Business Objects are useful because they give the organisation a mind-sized enterprise view of what it must understand, govern, and relate.

In ArchiMate terms, a Business Object provides an architectural abstraction. In data-modelling terms, that Business Object may be elaborated through one or more logical Entity Types within the Common Data Model.

This distinction matters.

The Business Object helps people see the enterprise concept.

The detailed Entity Types, attributes, relationships, subtypes and lifecycle rules provide the logical precision needed for governance, integration and operational use.

Data Subject Areas

A Data Subject Area is a mind-sized, root-centred view of the Common Data Model.

It supports detailed Gemba validation without overwhelming people with the full enterprise model.

Each L3 Data Subject Area has:

• one Home L3 Capability;
• one Root Entity Type;
• relevant core or dependent Entity Types;
• only those peripheral Entity Types needed to understand and validate the root.

This prevents the organisation from dragging the whole data model into every conversation.

For example, a Product Development Project Subject Area can focus on the Product Development Project and the entities needed to understand it, while still showing relationships to Product, Product Formulation, Active Ingredient, Additive and related concepts where required.

L3 Capabilities and Data Subject Areas

In Human–AI Knowledge Development, the L3 Capability is the practical level at which capability, work, information, measurement, stewardship and Gemba validation come together.

Each L3 Capability should therefore define one primary L3 Data Subject Area. The L3 Capability provides the operational and governance context. The Data Subject Area provides the root-centred semantic validation view needed to understand that capability in practice.

Each L3 Data Subject Area has:

• one Home L3 Capability;
• one Root Entity Type;
• relevant Core or Dependent Entity Types;
• only those Peripheral Entity Types needed to understand and validate the capability.

If a proposed L3 Data Subject Area appears to contain two independent Root Entity Types, this is treated as a modelling signal rather than additional richness.

The modeller should test whether:

• one Entity Type is actually Core or Dependent on the other;
• one Entity Type is Peripheral and governed elsewhere;
• the issue is better represented through a Value Stream, Process or Scenario view;
• or the L3 Capability is too broad and should be split.

This discipline keeps the architecture mind-sized while preserving enterprise integration.

It also helps ensure that each L3 Capability has a clear scope, coherent information structure, explicit stewardship and a practical basis for Gemba validation.

Section Summary

The point is not to reduce complexity by pretending it does not exist.

The point is to make complexity discussable at human scale.

This is where the golden rule applies:

AI may generate at machine scale. Humans can only validate at human scale.

Data Subject Areas are one of the main mechanisms by which HAK makes human-scale validation possible.

ArchiMate Views

ArchiMate provides a disciplined way of representing architectural knowledge.

Within HAK, do not treat ArchiMate views as separate drawings maintained independently of the Knowledge Base.

They are generated views of governed organisational knowledge.

An ArchiMate view may show Business Objects, capabilities, value streams, roles, processes, applications, technology services or relationships. Each view presents a particular slice of the repository for a particular purpose.

The view helps people see.

The repository preserves meaning.

This distinction is crucial. A polished ArchiMate diagram does not prove that the architecture is true, validated or approved. It represents candidate or governed knowledge at a point in time.

Its authority comes from the evidence, validation status, stewardship and approval record behind it.

Sparx Enterprise Architect

Sparx Enterprise Architect provides a practical repository environment for maintaining structured architectural knowledge.

Within the HAK approach, Sparx is not merely a drawing tool.

It is the persistent structural repository for the governed architecture and the Common Data Model. Business Objects, capabilities, Entity Types, relationships, Data Subject Areas, ArchiMate views, and validation metadata can be stored as connected repository elements rather than as disconnected diagrams. The governance note makes this explicit: diagrams and reports are views of the repository, not separate models.

This changes the repository’s role. The repository becomes organisational memory.

It preserves stable identifiers, relationships, evidence links, validation states, decisions, approved baselines and regeneration history.

XMI then becomes an interchange mechanism for moving governed structures into or out of Sparx. It is not the semantic source of truth. The governed Human–AI Knowledge Base remains the semantic source of truth, supported by human evidence, Gemba validation, and accountable stewardship.

One Repository, Many Views

The important principle is:

One governed organisational knowledge repository. Many generated views.

• A Business Capability Model is one view.
• A Business Object View is one view.
• A Data Subject Area is one view.
• An ArchiMate diagram is one view.
• A Value Stream is one view.
• A HASP radar profile is one view.
• A glossary entry is one view.

Each view makes a particular aspect of organisational knowledge visible, discussable, and useful.

None of them is the whole system.

The Human–AI Knowledge Base is the living system.

Enterprise Architecture provides the structural representations that help the organisation see, test, govern and use what it is learning.

When these representations are validated at Gemba and governed through a persistent repository, architecture becomes more than documentation.

It becomes workwear.

It becomes the business architecture, developed with the business, governed by the business, used by the business, and continually regenerated for the regeneration of the business.

Enterprise Architecture as a Sensemaking Discipline

Meaning evolves through interaction, where people exchange perspectives, challenge assumptions, negotiate definitions, and test ideas against reality.

Enterprise Architecture contains the structure to capture, map, stabilise and communicate this emerging understanding. However, the existence of a model does not guarantee that shared understanding has been established.

Models produced primarily by consultants or specialist architects may accurately represent organisational reality yet still fail to become part of the organisation’s shared mental model.

Shared understanding develops when people participate in creating, challenging, refining, and testing the model against operational reality.

Enterprise Architecture, therefore, has the potential for shared understanding, but only if it is socialised across the organisation. Socialisation is not sitting passively in a presentation as someone ‘walks through’ a model.  Socialisation comes when people can challenge assumptions, question definitions, contribute their own experience, and test the models against the realities of their work.

This process transforms the model from an external artefact into a shared organisational reference point.

The artefacts support learning; they do not replace it.

🤿For a deeper dive, see the following:

• Gemba Tests Everything
• Subject Area — Gemba: Where Learning Becomes Real
• Subject Areas – The Learning Environment

Shared Mental Models and Organisational Meaning

Every organisation operates through mental models. Individuals hold assumptions about customers, products, services, risks, quality, responsibilities, and priorities. Some of these assumptions are shared, while others differ across teams, functions, and individuals.

When important assumptions diverge, coordination becomes more difficult, learning slows, trust diminishes, and organisational coherence suffers.

Enterprise Architecture provides practical mechanisms to capture, structure, and communicate shared understanding as it emerges. Business Capability Models (BCMs) and Common Data Models (CDMs) help make organisational meaning visible, discussable, and reusable.

These models do not create shared understanding on their own. Rather, they provide a stable reference point that helps organisations maintain, refine, and communicate the shared understanding developed through interaction, dialogue, and experience.

🤿For a deeper dive, see the following:

• Shared Mental Models
• Common Data Model

Business Capability Models — Structuring What the Organisation Must Do

A Business Capability Model (BCM) describes: “What the business does.”

Capabilities are independent of organisation charts, systems, and current processes.

Before we start, a cautionary note

The architect’s role is not to reproduce the organisation’s current mental model. It is to help the organisation examine, challenge and improve that mental model.

Organisational language, structures, systems and established practices provide important evidence, but they are not automatically sound architecture. Existing models may reflect historical compromises, organisational silos, duplicated responsibilities, inherited terminology or the current organisation chart. Architects and modellers must respect local knowledge while testing it against sound modelling principles, reusable patterns, semantic coherence and Gemba reality.

Gemba evidence establishes how the organisation actually works. It does not require the architecture simply to reproduce current practice. Where the existing mental model is fragmented, ambiguous or inconsistent, the modelling process should make that visible and help the organisation develop a clearer shared understanding.

BCM example from the books

The BCM offers:

• strategic framework,
• clear ownership,
• defined accountability,
• a transformation context,
• and alignment of investments.

Here is a subset of the NaturFlourish BCM used in Learn, Transform and Navigate.

Figure 2: NaturFlourish BCM – Operations Only

Capability Hierarchy

Level 1 — Executive View

Mind-sized organisational domains.

In the example above, the Level 1 capabilities are:

• Customer Relationship Management
• Brand & Marketing
• Sales & Distribution
• Supply Management
• Product Management
• Manufacturing
• Inventory Management
• Distribution and Logistics

This provides senior leaders with a shared view of the major elements of the organisational value chain.

Level 2 — Management View

Details of a specific level 1:

L1 Capability: Product Management

Definition
The ability to develop, maintain, govern, and evolve the organisation’s product portfolio throughout its lifecycle, ensuring products remain commercially viable, scientifically credible, compliant, and aligned with customer needs.

Capability Owner
Elena Rossi – Head of Product Management

L2 Capability	Definition	Indicative Owner
Product Strategy & Portfolio Management	The ability to define and manage the product portfolio, balancing customer needs, commercial objectives, scientific evidence, and strategic priorities.	Elena Rossi – Product Director
New Product Development	The ability to identify opportunities, formulate, test, validate, and launch new products that meet customer, scientific, regulatory, and commercial requirements.	Dr Sarah Bennett – Product Development Manager
Product Lifecycle Management	The ability to manage products from introduction through growth, maturity, reformulation, and retirement, ensuring continued relevance and performance.	Elena Rossi – Product Portfolio Manager
Packaging & Market Segmentation	The ability to design packaging, positioning, branding, and market segmentation strategies that communicate product value to target customer groups.	Michael Chen – Product Marketing Manager
Product Regulatory Compliance Management	The ability to ensure products comply with TGA requirements, product claims regulations, labelling obligations, and applicable industry standards.	Rachel King – Regulatory Affairs Manager
IP & Patent Management	The ability to identify, protect, maintain, and leverage intellectual property, formulations, trademarks, and patents that support competitive advantage.	David Nguyen – Intellectual Property Manager

 

Level 3 — Operational View

It is the convergence point for capability ownership, business activity, information management, and performance measurement.

This is the engine room for operations:

• This is where data comes to life. In the next section, we will see the New Product Development Subject area.
• Assigned Data Stewards the information for proactive data quality management.
• It is the integration layer where the interfaces are determined with other capabilities in the design of the value chain.
• It is where data is defined for external interfaces with key stakeholders such as Suppliers and Regulators.

Once the BCM reaches this level of development and is validated in Gemba, it provides a highly stable foundation for operational data.

It is a crucial tool used by the team, including Elena, in their discussions with other parts of the business, forming the basis of the Shared Mental Model.

👉 Refer to Subject Area: Shared Mental Models.

This is essential for Knowledge Management within the organisation.

👉 Refer to Subject Area: Knowledge Operating System.

L3 Capability: New Product Development

Definition

The ability to identify, evaluate, formulate, validate, and commercialise new nutraceutical products that meet customer needs, regulatory obligations, scientific standards, and commercial objectives.

Capability Owner: Dr Sarah Bennett – Product Development Manager

The Capability Owner is accountable for:

• new product pipeline performance,
• product formulation quality,
• development cycle time,
• commercial readiness,
• regulatory readiness,
• successful transfer into production.

Data Subject Areas

At Level 3, we define the relationship between a business capability and its data. Each Level 3 capability will deal with many data entities. To manage this complexity, we use Data Subject Areas, which allow us to produce ‘mind-sized’ representations of a particular facet of the capability. Listed below are the Data Subject Areas for New Product Development.

The ‘related’ entities are owned by other business capabilities.

Subject Area 1: Product Formulation

Product Formulation Definition

Product Formulation defines a product’s composition, including active ingredients, excipients, additives, dosage form, and manufacturing specifications required to produce the product consistently.

Attributes

• Formulation ID
• Formulation Name
• Version Number
• Dosage Form
• Stability Rating
• Effective Date
• Status

Related Entities

• Product
• Active Ingredient
• Excipient
• Additive

Active Ingredient

Definition

An Active Ingredient is a substance intended to deliver the primary therapeutic or functional effect of the product.

Key Attributes

• Ingredient ID
• Ingredient Name
• Ingredient Type
• Standard Strength
• Unit of Measure
• TGA Status
• Safety Classification

Excipient

Definition

An Excipient is an inactive substance included in a formulation to aid manufacturing, stability, delivery, or preservation.

Key Attributes

• Excipient ID
• Excipient Name
• Functional Purpose
• Source
• Safety Classification
• TGA Status

Additive

Definition

An Additive is a substance added to improve appearance, flavour, preservation, or shelf life.

Key Attributes

• Additive ID
• Additive Name
• Additive Type
• Regulatory Status
• Maximum Allowable Concentration

Subject Area 2: Product Regulatory Specification

Definition

A Product Regulatory Specification defines the regulatory constraints and obligations that apply to a product and its formulation.

Key Entities

TGA Purpose

Defines the permitted therapeutic purpose.

Attributes:

• Purpose ID
• Purpose Description
• Regulatory Category
• Approval Status

TGA Restricted Ingredient

Defines ingredients subject to regulatory restriction.

Attributes:

• Restricted Ingredient ID
• Ingredient Name
• Restriction Type
• Maximum Dosage
• Permitted Use
• Effective Date

Product Regulatory Requirement

Defines the regulatory obligations applying to a product.

Attributes:

• Requirement ID
• Requirement Description
• Jurisdiction
• Compliance Category
• Effective Date

Subject Area 3: New Product Development Project

 

This introduces project management without overwhelming people.

Definition

A New Product Development Project coordinates the activities required to create, evaluate, approve, manufacture, and launch a new product.

Key Attributes

NPD Project

• Project ID
• Project Name
• Project Sponsor
• Project Manager
• Start Date
• Target Launch Date
• Status
• Business Case Reference

Related Entities

Product

• Product ID
• Product Name
• Product Type
• Product Persona
• Brand

Persona

• Persona ID
• Persona Name
• Age Range
• Need Category
• Lifestyle Segment

Product Persona Fit

• Fit Assessment ID
• Product ID
• Persona ID
• Benefit Rating
• Evidence Rating

 

Indicative KPIs

Pipeline Performance

• Number of active development projects
• Number of new product concepts generated
• Portfolio innovation ratio
• New product revenue contribution

Delivery Performance

• Average development cycle time
• Percentage of projects delivered on schedule
• Percentage of projects delivered within budget

Regulatory Performance

• Regulatory approval success rate
• Percentage of claims supported by acceptable evidence
• Number of regulatory non-conformances

Quality Performance

• Formulation success rate
• Stability test pass rate
• Manufacturing transfer success rate

Commercial Performance

• First-year product revenue
• New product gross margin
• Product launch success rate

Learning and Improvement

• Lessons learned incorporated into future projects
• Percentage of projects completing post-launch review
• Time taken to resolve development issues

 

Common Data Models — Structuring Organisational Meaning

If the BCM describes what the organisation does, the CDM describes what the organisation deals with.

In the previous section, we observed that data is categorised at the Level 3 Business Capabilities.

All Data Subject Areas are integrated within the Common Data Model (CDM). View the CDM at the subject-area level, as creating larger models often becomes impractical because of the overwhelming amount of information.

Here are the representative Data Subject Areas for New Product Areas with the specific data items owned by the capability.

The Product Development Project is the data model for one of the Subject Areas discussed above. Each Entity has its own set of attributes which describe its properties.

Diagram Notes:

• The Product Development Project is a subtype of Project. As shown in the diagram, the business offers various other project types. The business capability ‘Project Management’ manages the Project and oversees planning, approval, execution, and review of all projects.
• Each entity has attributes with specific data types that define their properties.
• Entities are connected through Relationships, which illustrate the links between them. For example, a Product has at least one Product Formation (the ‘crow’s foot’ notation indicates there must be at least one, possibly more). Each Product Formation is associated with exactly one Product.
• The data model captures detailed information about the business capabilities involved, including rules such as those related to Product Formulations mentioned earlier.

 

Figure 3: Product Development Subject Area

 

The examples shown in this Subject Area are deliberately simplified. A small, regulated manufacturer may manage hundreds of business entities and thousands of attributes across customers, products, suppliers, employees, manufacturing operations, quality systems, regulatory obligations, and financial processes.

Subject Areas are not meant to reduce this complexity, but to make it mind-sized and understandable by presenting it in manageable, business-relevant chunks while preserving integration with the broader enterprise model.

This is the practical reality behind Shared Mental Models and one reason why validating models in Gemba is so important. As people work through the details of a capability, they challenge assumptions, clarify definitions, expose dependencies, and make organisational knowledge visible.

In the New Product Development example, conversations about formulations, ingredients, regulatory restrictions, product claims, manufacturing specifications, and customer needs quickly reveal the true complexity of obtaining and maintaining regulatory approval. These discussions are not a by-product of modelling; they are among its primary benefits.

Through these conversations, a common language, shared understanding, and organisational meaning emerge.

The definitions, relationships, and business rules captured during this process can then be incorporated into a shared organisational glossary, providing a single reference point for agreed meanings across the enterprise. While there may never be a single version of the truth, the organisation should agree on a single definition for the terms it uses.

 

BCM and CDM Together

The BCM and CDM perform complementary roles.

 

BCM	CDM
What the business does Describes the capabilities required to operate the organisation.	What the business deals with Describes the information, concepts, and business objects required to operate the organisation.
Capability Defines the business abilities the organisation must possess.	Meaning Defines the concepts and terminology used consistently across and outside the organisation.
Ownership Accountability for establishing and improving a capability, and ensuring it meets its mission to its customers.	Stewardship Establishes the agreed meaning of business terms and information, and negotiating/ delivering on data/information quality metrics.
Action Focuses on the work performed to create value and achieve outcomes.	Understanding Focuses on understanding the information required to support those activities.
Coordination Coordinates activities across the organisation to meet their mission and achieve a common purpose.	Coherence Ensures data and information remain consistent, integrated, and meaningful across the organisation.

 

Together they form a significant part of the organisational Knowledge Base.

 

• The BCM provides structural coordination.
• The CDM provides semantic coherence.
• Together they support organisational learning.

 

Cross-Validation Between BCM and CDM

Many organisations start with a BCM because it provides a straightforward executive overview of the enterprise. However, the BCM and CDM should be seen as interdependent, each validating the other. Experience shows that creating a Common Data Model often reveals gaps, overlaps, ownership disputes, and inconsistencies in the BCM. Conversely, the BCM helps identify missing subjects, ownership responsibilities, and integration needs within the CDM. Mature enterprise modelling treats both the BCM and CDM as complementary, evolving iteratively rather than in sequence. Each serves as a validation mechanism for the other.

At Level 3, every major business entity should have a single, clear capability owner.

Without a designated owner, critical questions emerge:

• Who is responsible for maintaining its quality?
• Who defines its meaning?
• Who is accountable when problems occur?

 

Conversely, every Level 3 capability should own or steward at least one business entity. If a capability has no associated information, ask whether it is truly a capability or merely a collection of activities that belong elsewhere.

 

Developing coherent Data Subject Areas offers an extra layer of validation. If a capability lacks a meaningful set of related entities, definitions, relationships, business rules, and measures, then either the BCM or the CDM is considered incomplete.

Stability Amid Change

 In complexity, change is the only constant:

• Processes undergo continuous improvement and change.
• Systems change as new technologies become available.
• Organisational structures change.
• Projects come and go.

Yet the organisation’s underlying capabilities and information tend to remain remarkably stable over time.

In Adapt, Survive and Flourish, I used a simple thinking exercise to compare The Bank of New South Wales in 1910 with a modern bank. The 1910 bank offers similar capabilities, including Customer Management, Account Management, Transaction Processing, Lending, Risk Management, Financial Management, and Branch Operations. While the technology and processes have changed dramatically, the fundamental capabilities remain recognisable more than a century later.

The same thought experiment applies to information. Customers, Accounts, Loans, Employees, Products, and Transactions remain core concepts regardless of the technology used to manage them. Accounts still have owners, signatories, guarantors, and credit limits. They are still subject to transactions such as Fees, Interest, Withdrawals, and Deposits. The supporting technology is completely different, with clerking using pen and ink in leather-bound journals and ledgers, rather than cloud-based online applications.

For this reason, the BCM and CDM often provide the most stable foundation in an environment of continual organisational change. They become the rock upon which organisations can stand amid the sea of complexity.

Subject Areas as Integration Interfaces

Data Subject Areas also provide a practical way to understand integration across the organisation.

When two capabilities need to interact, the associated Subject Areas reveal:

• What information needs to be shared?
• How is that information specified?
• What quality standards must be met?
• Who is responsible for maintaining it?
• Where are stewardship roles assigned?

In this sense, Subject Areas act as organisational integration interfaces. They provide a common reference point through which capability owners and data stewards can negotiate meaning, ownership, quality expectations, and information exchange.

These discussions are most effective when conducted in Gemba, where assumptions can be challenged and tested against operational reality.

The Organisational Glossary

The combined definitions developed through the BCM, CDM, and Subject Areas provide the foundation for an organisational glossary.

The glossary becomes a key component of the Knowledge Base, providing a shared reference for agreed business meaning across the enterprise.

While organisations may never achieve a single version of the truth, they should strive for a single agreed definition of the terms they use.

Data Quality, Meaning and Trust

Data quality is not primarily a technical problem.

Many data quality failures originate from:

• unclear meaning,
• siloed thinking,
• fragmented ownership,
• multiple versions of the same data, all with different ‘versions of the truth’.
• undocumented and inconsistent definitions,
• and conflicting assumptions.

The act of building Common Data Model in the business helps establish:

• shared meaning,
• agreed definitions of terms, including how values are derived or calculated,
• ownership,
• stewardship,
• consistency across systems, reports, teams, and business processes.

Some of the most significant disagreements within organisations arise not from inaccurate data, but from differing interpretations of how key business measures are defined or calculated. Metrics such as Cost of Goods Sold, Cost of Funds, Customer Profitability, Revenue, and Risk Exposure often become contentious when definitions are unclear or inconsistently applied.

Data Quality Management involves more than just fixing errors; it is a continuous effort to sustain reliable organisational meaning over time.

When team members lack a shared understanding of information, it often leads to disagreements, reconciliation efforts, and poor decision-making.

Poor data creates more than operational errors.

It creates confident mistakes.

For this reason, effective Data Quality Management is primarily preventive, not reactive. As my dear old mum used to say, “Prevention is better than cure.” She was right about most things, and she was certainly right about getting the facts right.

The objective is not simply to find and repair defects after they occur, but to establish shared definitions, ownership, stewardship, business rules, and quality controls that prevent defects from arising in the first place.

Like sunscreen, prevention is far more effective than treatment. It is easier to establish clear meaning and trusted information from the start than to repair damaged trust, reconcile conflicting reports, or recover from poor decisions based on misunderstood data.

The Common Data Model provides much of this preventative foundation by establishing shared meaning, agreed definitions, ownership, and stewardship before information enters operational systems and reporting processes.

For this reason, effective Data Quality Management is primarily preventative rather than corrective. The objective is not simply to find and repair defects after they occur, but to establish shared definitions, ownership, stewardship, business rules, and quality controls that prevent defects from arising in the first place.

Like sunscreen, prevention is far more effective than treatment. It is easier to establish shared understanding before information enters operational systems than to repair damaged trust, reconcile conflicting reports, or recover from poor decisions made using misunderstood data.

This preventative foundation does not emerge from the existence of a Common Data Model alone. It emerges by developing the model with the people who create, use, manage, and depend on the information.

As assumptions are challenged, definitions are negotiated, ownership is clarified, and business rules are tested against operational reality, common language and shared meaning begin to emerge.

The value lies not only in the completed model, but in the conversations required to build it.

When developed and validated in Gemba, the Common Data Model becomes more than a technical artefact. It becomes a mechanism for developing Shared Mental Models across the organisation.

An important aspect of data quality management is the mindset we choose about what we want to see.

It is not just what we can see, but what we choose to notice.

🤿For a deeper dive, see the following: Source Note – Line of Sight.

From Shelfware to Workwear

One of the most common failures of Enterprise Architecture is producing shelfware.

Models are:

• built,
• reviewed,
• approved,
• stored,
• and forgotten.

 

Effective Enterprise Architecture creates workwear.

Models that are applied in the workplace on a regular, ongoing basis to influence:

• Decisions at all levels, from investment down to the integration of a spreadsheet.
• Governance of activities like Data Quality management,
• Strategic and Design Thinking as the core of Shared Mental Models.
• Ownership and accountability from the top floor to the shop floor.
• How knowledge is classified and interpreted, so they are key to learning.

A model that is not used at Gemba has limited value. If it is not owned and accepted locally, then it is of limited use.

The first value comes from creating the model. This is how Shared Mental Models are built, and it is crucial for Design Thinking and Strategic Thinking.

🤿For a deeper dive, see the following:

• Source Note — Shared Mental Models
• Subject Area — Adaptive Thinking Systems, Design Thinking and Strategic Thinking

The enduring value comes from using it.

The difference between shelfware and workwear isn’t the model’s quality. Many technically advanced models become shelfware. The key distinction is in how the model is developed, socialised, and utilised.

When models are developed independently and then presented as final artifacts, the creator retains real ownership and understanding. While people might review, agree with, or even cite them occasionally, these models seldom become integrated into the organisation’s collective understanding.

Workwear emerges differently.

As individuals develop, test, and refine a model, they start to recognise their own work, language, responsibilities, and connections within it. Assumptions are challenged, definitions are clarified, ownership is negotiated, and inconsistencies are revealed. This process transforms the model from simply a diagram into a shared reference point for the organisation.

👉🏻 The value lies not only in the completed artefact, but in the conversations required to create it.

A Business Capability Model, Common Data Model, or Subject Area developed in this way becomes part of the organisation’s shared mental architecture. People use it to explain problems, resolve disagreements, assess impacts, make decisions, and coordinate change.

The model is no longer “the architect’s model, “the vendor’s model”, or “the consultant’s model.”

It becomes the organisation’s model.

 This is the transition from shelfware to workwear.

The most enduring models are rarely the most elegant. They are the models that have been tested, challenged, and continuously refined in Gemba until they become part of how the organisation thinks, learns, and acts.

BCM Overlays — Viewing the Organisation Through Different Lenses

The same capability model can be viewed through multiple lenses.

Examples include:

Investment Plans

Where have we focused in the past, and where should we be focused now? Here is a simple example; note that you can see the whole business at a glance.  A perfect tool for executive discussions and planning.

Figure 4: BCM with Investment Strategy Overlay

 

The possibilities are almost endless, but the result is the same: a mind-sized representation that is perfect for communication and discussion. You can do the same with a spreadsheet, of course, but this is far more accessible and engaging.

Other possibilities:

• Risk and Compliance — Where failure creates consequences.
• Strategy and Value — Where value is created.
• Data and Meaning — Where information integrity matters most.
• AI Opportunity — Where augmentation may provide benefit.
• Transformation — Where investment and change should be focused.

The underlying capability model remains stable and is common for all to relate to.

The perspective changes with the context of use.

Roadmaps, Solution Design and Change

Many Enterprise Architecture methodologies progress architecture through a series of defined steps. I am not going to review or critique these approaches; my concern is with organisational sensemaking, shared understanding, and learning.

Regardless of methodology, Enterprise Architecture provides a bridge between:

• strategy,
• capability,
• information,
• initiatives,

Enterprise Architecture helps organisations translate intent into coordinated action.

Tools such as Strategic Thinking, Design Thinking, and Scenario Planning can use and support Enterprise Architecture by informing roadmaps, solution design, and organisational change.

When supported by shared mental models and a common architectural language:

• Roadmaps become capability-driven rather than project-driven.
• Solutions become capability-aligned rather than technology-driven.
• Change becomes coordinated rather than fragmented.

This is where Enterprise Architecture moves from understanding the organisation to helping shape its future.

Architecture is not an end in itself. Its value emerges when shared understanding informs decisions, guides investment, aligns change, and helps people act with greater coherence.

AI-Assisted Modelling

Artificial Intelligence is rapidly changing the economics of enterprise modelling.

Tasks that once required significant manual effort, such as model generation, pattern discovery, relationship identification, structural analysis, and documentation, can now be completed in minutes rather than days.

AI can accelerate:

• model generation,
• pattern discovery,
• relationship identification,
• structural exploration.

This capability enables organisations to involve a wider audience in modelling efforts. Organisations can now create initial Business Capability Models, Common Data Models, Subject Areas, glossaries, and governance artifacts quickly and improve them through collaboration.

Nonetheless, AI does not eliminate the need for human judgment. It lacks accountability for organisational results:

• It does not own data.
• It does not understand organisational politics.
• It does not experience customer impacts.
• It does not bear responsibility for regulatory compliance.

While AI can recognise patterns and propose structures, it cannot confirm if those structures truly mirror the organisation’s reality.

The most effective approach combines AI speed with the experience, contextual knowledge, and accountability of the people who do the work.

AI accelerates modelling. Humans remain accountable for reality.

Historically, developing comprehensive Business Capability Models, Common Data Models, Subject Areas, glossaries, and governance artefacts required significant specialist expertise, substantial budgets, and lengthy consulting engagements. As a result, many organisations never established the architectural foundations needed to support shared understanding and organisational learning.

🤿For a deeper dive, see the following:

• Source Note: Human–AI Knowledge Base Development Guideline
• Subject Area: Guided Human–AI Collaboration
• Subject Area — Human–AI Kanban Architecture
• Subject Area – Support note for the Human AI Knowledge Base Guideline
• Subject Area: Human–AI Knowledge Base Development

AI is changing this reality.

The Human–AI Knowledge Base Guideline (HAK), developed as part of this body of work, shows how organisations can use AI as an apprentice modeller to accelerate the development of Business Capability Models, Common Data Models, Subject Areas, glossaries, and enterprise knowledge bases.

The approach has been used throughout the development of the models and architectural artefacts presented in this Subject Area and forms a key element of the modelling practices described in Learn, Transform and Navigate.

AI can rapidly generate candidate capabilities, entities, relationships, ownership structures, definitions, and integration patterns. We have also shown it can generate the XML to populate EA tools such as Sparx. This significantly reduces the effort required to establish an initial architectural baseline.

However, the artefacts themselves are not the objective.

As discussed throughout this Subject Area, Shared Mental Models emerge through participation, challenge, validation, and learning. Business Capability Models, Common Data Models, Subject Areas, and glossaries become valuable only when they are tested in Gemba, refined through organisational dialogue, and used as workwear rather than shelfware.

• AI can accelerate artefact creation.
• Only people can create the shared understanding that gives those artefacts meaning.
• The challenge is no longer model production.
• The challenge is organisational learning.

Socialisation, Gemba and Learning

Strong models emerge through:

• dialogue,
• workshops,
• storytelling,
• challenge,
• operational testing,

Socialisation creates understanding.

Gemba validates understanding.

Learning occurs when models encounter reality.

Communication is not understanding.

Shared understanding emerges through participation.

This principle sits at the heart of Enterprise Architecture as a sensemaking discipline.

Business Capability Models, Common Data Models, Subject Areas, glossaries, and governance artefacts do not create Shared Mental Models merely because they exist. Shared understanding emerges when people build, challenge, refine, and validate them against operational reality.

A presentation may communicate a model.

A workshop may explain a model.

Only participation creates ownership and understanding.

This is why Gemba is so important. It provides the reality test that challenges assumptions, exposes inconsistencies, clarifies meaning, and grounds the model in lived experience.

The most valuable outcome is often not the model itself, but the conversations, learning, and shared understanding that emerge while building it.

This is where Enterprise Architecture moves beyond documentation and becomes a mechanism for organisational learning.

🤿 For a deeper dive, see:

• Source Note – Shared Mental Models
• Subject Area – The Learning Environment
• Subject Area — Gemba: Where Learning Becomes Real

Enterprise Architecture and the Knowledge Operating System

Enterprise Architecture occupies the structural layer of the Knowledge Operating System.

 

1. Purpose provides the starting point. It gives the organisation direction and establishes why the work matters. Without purpose, knowledge work can easily become fragmented, technical or self-referential.
2. Purpose is then held within a social field — a Ba — where people can share experience, surface assumptions, challenge meaning and develop trust. Knowledge does not emerge from documents alone. It develops in a shared context where people are willing and able to disclose what they know, test what they believe and listen to what others have experienced.
3. Within that field, the SECI cycle provides the learning dynamic. Tacit knowledge is shared through Socialisation, expressed through Externalisation, Combined with other explicit knowledge, and Internalised through practice. This is how individual experience becomes shared organisational knowledge.
4. Enterprise Architecture then gives that knowledge structural form. The Business Capability Model describes what the organisation must be able to do. The Common Data Model describes what the organisation must understand, distinguish and govern. Together, the BCM and CDM make organisational knowledge visible, testable and reusable.
5. That structured knowledge must then go to Gemba. It must be tested where work, service, relationship and consequence are actually experienced. Gemba challenges the model. It reveals exceptions, workarounds, tacit judgement, conflicting meanings and consequences that formal architecture may miss.
6. Over time, this repeated movement from purpose, through shared learning, into structured architecture and back to Gemba shapes culture. Culture is not treated as a slogan or separate change-management activity. It emerges from the way people learn, validate, govern and act together.

In this sense, culture is the lived expression of the organisation’s knowledge system.

The Business Capability Model and Common Data Model provide the structural foundation upon which organisational knowledge can be stabilised, communicated, and reused.

As discussed throughout this Subject Area, the BCM captures what the organisation does, while the CDM captures what the organisation deals with. Together, they provide a shared reference point that supports coordination, governance, learning, and adaptation.

Within the Knowledge Operating System, Enterprise Architecture performs the Combination role of SECI. It helps organise, integrate, and stabilise organisational knowledge through structures such as Business Capability Models, Common Data Models, Subject Areas, glossaries, policies, standards, and governance artefacts.

However, these structures do not create knowledge on their own.

Knowledge emerges when people interact with them through dialogue, interpretation, challenge, experimentation, and use in practice.

This is why the layers above and below Enterprise Architecture matter.

The social field creates the conditions for learning. SECI provides the learning dynamics.

Enterprise Architecture stabilises what is learned. In the Knowledge Operating System we use the BCM and CDM as the foundation for the Knowledgebase.

Figure 5: BCM and CDM as the Foundation

Gemba tests it against reality.

Culture emerges from repeated cycles of learning and application.

Without a shared architectural foundation, organisations increasingly rely on local interpretation, individual reconciliation, tribal knowledge, and workarounds.

With a shared foundation, organisations develop the capacity to learn, coordinate, govern, and adapt coherently.

🤿 For a deeper exploration of the complete model, see:

• Subject Area – Knowledge Operating System

 

Closing Reflection

Enterprise Architecture is not about producing models.

It is the disciplined creation of shared understanding.

Business Capability Models and Common Data Models are not ends in themselves.

They are tools that help organisations make meaning visible, discussable, governable, and learnable.

When used effectively, they become part of the organisation’s shared knowledge foundation and support its ability to adapt, survive, and flourish.

Return to: Sensemaking Domain