Framing the Subject Area

Most organisations allocate substantial resources to systems, processes, projects, and structures. However, far fewer focus on building a unified shared understanding of what the organisation does, the information it relies on, how responsibilities are assigned, how decisions are made, and how to coordinate change.

This often results in fragmentation, inefficiency and confusion resulting from:

• siloed thinking where different areas develop their own terminology and interpretations,
• duplicated effort and data redundancy, with each business area managing its own version of a specific aspect, for example, Sales, Customer Service, and Marketing having separate Customer Contact preferences,
• inconsistent data caused by redundancy and varying definitions of the same data,
• disconnected initiatives where different business areas and projects pursue their own goals without considering cross-business dependencies,
• and technology reflecting organisational politics rather than the actual organisational structure.

Enterprise Architecture offers a way to tackle these issues. On this website, it is not primarily a tool for managing technology, but a sensemaking discipline.

Its goal is to help organisations build shared understanding to make sense of their world and to develop, sustain, and adapt a common knowledge base that facilitates learning, coordination, governance, and flexibility.

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 more information on this aspect, see:

 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 for capturing, structuring, and communicating 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 by themselves. Rather, they provide a stable reference point that helps organisations maintain, refine, and communicate the shared understanding developed through interaction, dialogue, and experience.

For more information on this aspect, see:

Source Note – Shared Mental Models

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.

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.

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 Source Notes:

Shared Mental Models

Source Note: Knowledge Operating System

🤿For a deeper dive

👉 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, the relationship between a business capability and its data is defined. 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 the composition of a product, 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). The CDM should be viewed at the subject-area level, as creating larger models often becomes impractical due to 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.

Data Subject Area  – Product Development Project

Diagram Notes:

• The Product Development Project is a subtype of Project. As shown in the diagram, the business offers various other project types. The Project is managed by the business capability ‘Project Management,’ a support function responsible for overseeing 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.

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.

The purpose of Subject Areas is not to reduce this complexity, but to make it 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 it is so important to validate models in Gemba. As people work through the details of a capability, assumptions are challenged, definitions are clarified, dependencies are exposed, and organisational knowledge becomes 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 one of its primary benefits.

It is through these conversations that 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 meaning across the enterprise. While there may never be a single version of the truth, there should be a single agreed definition for the terms used by the organisation.

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 offers a straightforward executive overview of the enterprise. However, the BCM and CDM should be seen as interdependent, validating each other. Experience indicates 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, it is worth asking 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 underlying capabilities and information of the organisation 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 versus cloud-based online applications.

For this reason, the BCM and CDM often provide the most stable foundation available 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 mechanism for understanding 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 organizational meaning over time.

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

Many major organisational disputes stem not from inaccurate data but from differing interpretations of how key business metrics are defined or calculated. Metrics like Cost of Goods Sold, Cost of Funds, Customer Profitability, Revenue, and Risk Exposure can become highly contentious if their definitions are unclear or applied inconsistently.

Poor data creates more than operational errors, it creates confident mistakes.

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 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.

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.

Have a look at Source Note – Line of Sight.

From Shelfware to Workwear

One of the most common failures of Enterprise Architecture is the production of 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 form investment down to 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 shop floor.
• How knowledge is classified, interpreted so they are key to earning.

A model that is not used at Gemba has limited value. 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, 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 about the quality of the model. 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 real ownership and understanding stay with the creator. 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 engage in the development, testing, and refinement of 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 vendors’ 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 have focused on the past, and where should we be focused now? Here is a simple example, note you can see the whole business at a glance.  A perfect tool for executive discussions and planning.

BCM Overlay of Investment Strategy

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 consequence.
• 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

There are a plethora of Enterprise Architecture methodologies that 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,
• and solutions.

Enterprise Architecture helps organisations translate intent into coordinated action.

Tools such as Strategic Thinking, Design Thinking, and Scenario Planning can be used alongside Enterprise Architecture to inform 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

10. 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 organizations to involve a wider audience in modelling efforts. Initial Business Capability Models, Common Data Models, Subject Areas, glossaries, and governance artifacts can now be created swiftly and improved 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 the speed of AI with the experience, contextual knowledge, and accountability of the people who perform 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 developed the architectural foundations needed to support shared understanding and organisational learning.

AI is changing this reality.

For a more detailed discussion, see:  Subject Area: Guided Human–AI Collaboration

The Human–AI Business Modelling Guideline, developed as part of this body of work, demonstrates 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. On top of this, we have 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 the creation of the artefacts.

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 participate in building, challenging, refining, and validating 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.

🤿 This material is covered in greater detail elsewhere. For a deeper dive, see:

Subject Area — The Learning Environment

Subject Area — Gemba: Where Learning Becomes Real

Source Note — Shared Mental Models

 

Enterprise Architecture and the Knowledge Operating System

Enterprise Architecture occupies the structural layer of the Knowledge Operating 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 by themselves.

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 are so important.

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.

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 the production of 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.