Organizational Data Model¶
The Organizational Data Model defines the canonical data, semantic, knowledge, and governance model of the organization.
It provides a common structure for describing:
- organizational concepts
- people, teams, and departments
- systems and data sources
- processes and operational activities
- datasets and documents
- metrics and KPIs
- relationships between organizational entities
- source fields and their canonical meanings
- operational and technical telemetry
- organizational performance and outcomes
The model is a living system. It evolves as organizational domains are discovered, defined, mapped, validated, and used.
Explore the Model¶
Ontology¶
The ontology defines the minimum stable concepts and relationships used to describe the organization.
The ontology provides the semantic foundation for the rest of the model. It is intentionally kept small and is expanded only when real domains demonstrate that additional concepts are necessary.
Data Dictionary¶
The Data Dictionary contains canonical definitions for the organization's concepts, metrics, KPIs, and data assets.
Definitions are maintained as machine readable YAML and validated against schemas before being published through the documentation site.
Domains¶
Domains apply the model to specific areas of the organization.
A domain is not necessarily the same thing as an organizational department. Domains represent coherent areas of organizational meaning, data, processes, systems, measurements, and decisions.
Each domain may contain different combinations of:
- domain concepts
- source systems
- source fields
- field matrices
- canonical mappings
- metrics
- KPIs
- operational definitions
- supporting documentation
Finance¶
The Finance domain models financial information, systems, processes, controls, and measurements used by the organization.
The domain includes areas such as revenue, expenditure, cash flow, budgets, financial performance, receivables, payables, compliance, and financial risk.
Finance provides the financial context required by other domains for planning, resource allocation, performance measurement, and decision making.
People¶
The People domain models people related information and organizational structures.
The domain includes areas such as employees, teams, organizational structure, recruitment, staffing, performance, attendance, leave, compensation, engagement, skills, and workforce planning.
People provides the workforce context required to understand organizational capacity and performance.
Projects¶
The Projects domain models projects, project activities, delivery information, resources, dependencies, risks, and related organizational data.
The domain provides the organizational context for understanding what work is being undertaken, how that work is progressing, what resources are committed, and where delivery risks exist.
Projects may connect to Products, Technology & Engineering, Finance, People, and Sales & Marketing.
Products¶
The Products domain models the organization's products, their lifecycle, capabilities, supporting systems, market needs, and associated measurements.
The domain includes information related to product development, feature delivery, product readiness, product performance, customer feedback, adoption, revenue contribution, and product outcomes.
Products connects market demand with Projects, Technology & Engineering, Sales & Marketing, Finance, and organizational outcomes.
Sales & Marketing¶
The Sales & Marketing domain models the organization's commercial activity, market engagement, and external market presence.
The domain includes:
- sales
- marketing
- business development
- partnerships
- leads and opportunities
- proposals
- meetings
- pipeline
- conversion
- customer acquisition
- customer retention
- market activity
- social media
- web analytics
Social Media and Web Analytics are treated as channels and measurement areas within Sales & Marketing rather than as separate organizational domains.
The domain provides the commercial context required to understand how organizational products and services move from market awareness through engagement, opportunity, conversion, customer relationships, partnerships, and revenue generation.
Technology & Engineering¶
The Technology & Engineering domain models the organization's technology capabilities, engineering activities, technical investments, and technology related decision making.
The domain includes:
- software engineering
- architecture
- infrastructure
- technical delivery
- technical capacity
- technical debt
- technology investment
- engineering quality
- AI engineering
- AI services
- system reliability
- observability
- technical telemetry
Observability is treated as a capability within Technology & Engineering rather than as a separate organizational domain.
The Observability area models telemetry generated by applications and supporting infrastructure, including metrics, logs, traces, events, and other operational signals.
This distinction allows the model to preserve observability as an important technical capability without making infrastructure specific terminology a top level organizational domain.
Technology & Engineering connects technical activity and system behaviour with Projects, Products, People, Finance, and organizational outcomes.
Organizational Operations¶
The Organizational Operations domain models the cross functional processes and operational activities through which the organization functions.
This domain provides a place for operational concepts that do not belong exclusively to Finance, People, Projects, Products, Sales & Marketing, Technology & Engineering, or another specialized domain.
It may include areas such as:
- internal processes
- administrative workflows
- organizational coordination
- operational requests
- approvals
- cross functional activities
- internal communications
- operational procedures
Organizational Operations should remain deliberately broad but should not become a dumping ground for concepts that belong more naturally to an established domain.
How the Model Fits Together¶
The model separates organizational meaning from the systems and sources that happen to represent that meaning.
A simplified flow is:
Source Systems
↓
Source Fields / Telemetry
↓
Field Matrix
↓
Canonical Mappings
↓
Canonical Concepts
↓
Metrics / KPIs / Data Assets
↓
Organizational Knowledge
↓
Decision Making
The exact path differs by domain.
For example, a technical metric may originate from an OpenTelemetry instrument within Technology & Engineering, while a social media metric may originate from a platform API within Sales & Marketing.
A financial metric may originate from an accounting system, while a sales metric may originate from a CRM or manually maintained commercial pipeline.
All of these can ultimately map into concepts that have meaning within the organizational model.
A source field is therefore not automatically a canonical definition.
The model distinguishes between:
- what a source calls something
- what the organization means by it
- how that meaning is measured
- where the information comes from
- how the information is used
- which organizational decisions depend on it
This separation allows different systems to be integrated without forcing their terminology or structures into the organization's semantic model.
From Sources to Meaning¶
Each domain can progressively move through a common modelling process:
Domain Discovery
↓
Source Identification
↓
Source Fields / Attributes
↓
Field Matrix
↓
Canonical Mappings
↓
Canonical Definitions
↓
Metrics and KPIs
↓
Ontology Relationships
↓
Organizational Decisions
Not every domain needs every layer immediately.
A domain can begin with an overview and source discovery and become more structured as its requirements become better understood.
This prevents the model from requiring a complete ontology or data dictionary before useful work can begin.
From Metrics to Decisions¶
The organizational model recognizes that metrics exist because someone uses them to understand performance, identify problems, or make decisions.
A metric should therefore be understood in relation to:
Measurement
↓
Interpretation
↓
Target / Threshold
↓
Decision
↓
Action
Not every measurement is a KPI.
Some measurements are operational signals.
Some are supporting metrics.
Some have formal targets.
Some trigger action only when they change significantly.
The model should preserve these distinctions rather than treating every reported number as a KPI.
Cross Domain Relationships¶
The organizational model is intentionally connected.
Organizational decisions frequently require information from multiple domains.
For example:
Products
↓
Product readiness
↓
Sales & Marketing
↓
Pipeline / opportunities
↓
Finance
↓
Revenue / cash flow
Another example:
Projects
↓
Delivery progress
↓
People
↓
Capacity / staffing
↓
Technology & Engineering
↓
Technical constraints
↓
Products
↓
Product delivery
Another:
Finance
↓
Budget / actuals
↓
Technology & Engineering
↓
Infrastructure and engineering spend
↓
Projects
↓
Delivery investment
↓
Products
↓
Business impact
Another:
Sales & Marketing
↓
Customer demand
↓
Products
↓
Product requirements
↓
Projects
↓
Delivery
↓
Technology & Engineering
↓
Technical implementation
↓
Finance
↓
Revenue / cost / profitability
These relationships are part of the reason the organizational model exists.
The objective is not simply to document individual domains, but to establish a common semantic layer through which information from different domains can be understood together.
Repository as Source of Truth¶
The repository is the source of truth for the organizational model.
Machine Readable Definitions
↓
Schema Validation
↓
Generated Documentation
↓
Human Review
↓
Evolving Organizational Model
Where structured definitions exist, they should be maintained in machine readable form and validated before publication.
Documentation provides the human readable representation of the model, while the underlying definitions provide the structured representation that can later support data engineering, governance, lineage, search, and AI systems.
Model Philosophy¶
The model follows several principles.
Start Small¶
The objective is not to create a massive ontology before the organization has enough evidence to justify one.
The model begins with a minimum stable set of concepts and expands when real domains expose gaps.
Separate Meaning from Representation¶
A database column, API field, telemetry attribute, or spreadsheet heading is a representation of information.
It is not necessarily the organization's canonical meaning.
Model Real Domains¶
Domains should be developed from actual organizational systems, processes, data, and decisions rather than theoretical classifications.
A domain should exist because there is a coherent body of organizational meaning that needs to be modelled.
Preserve Source Context¶
Source terminology and structure remain important because they explain where information originates and how it is represented.
Canonical mappings connect that source context to the organizational model rather than replacing it.
Connect Metrics to Decisions¶
Metrics should be understood in the context of the decisions they support.
Where appropriate, the model should capture targets, thresholds, interpretation, decision relevance, and downstream action.
Avoid Organizational Chart Thinking¶
The data model should not simply reproduce the company's current organizational structure.
Departments and job titles may change.
The model should instead represent relatively durable areas of organizational meaning, while allowing organizational structures to change around them.
Evolve Through Evidence¶
When a domain exposes a missing concept, relationship, metric, or definition, the model can evolve.
The objective is therefore not perfection at the beginning.
The objective is to establish a durable semantic foundation that becomes more precise as organizational knowledge grows.
Current State¶
The model currently contains structured, canonical definitions across seven domains.
Sales & Marketing and Technology & Engineering established the source-to-canonical mapping pattern first, using external platform data (including social media sources) and OpenTelemetry technical telemetry (metrics, logs, traces) respectively.
Building on that pattern, the organizational KPI discovery work has since produced canonical metric, KPI, and data-asset definitions across:
- Finance
- People
- Projects
- Products
- Sales & Marketing
- Technology & Engineering
Each of these six domains now has a governed set of metrics, KPIs, and data assets in the Data Dictionary, validated against the model's schemas.
Organizational Operations remains at the requirements stage: cross-functional operational concepts have been identified as a gap the model should eventually cover, but no canonical definitions have been created for this domain yet.
The domains will continue to become more detailed as their underlying systems, processes, data assets, metrics, and organizational concepts are discovered and validated, and as domain overview pages, ontology relationships, and field-level mappings are built out to match the depth already established for Sales & Marketing and Technology & Engineering.
Where the Model Is Going¶
The Organizational Data Model is intended to become a shared semantic foundation for the organization's data ecosystem.
Over time it can support:
- data integration
- data governance
- data lineage
- data quality
- organizational reporting
- metric standardization
- institutional memory
- knowledge discovery
- AI systems
- cross domain analysis
- decision support
The model does not attempt to solve all of these problems directly.
Its primary purpose is to establish a consistent understanding of:
what the organization has, what it means, where it comes from, how it relates, how it is measured, and which decisions depend on it.