Domains¶
Purpose¶
Domains organize the organization's data and knowledge according to meaningful areas of business, technology, operations, and organizational activity.
A domain provides context for concepts, datasets, metrics, systems, processes, documents, and other assets that share a common area of responsibility or subject matter.
Domains are not isolated data silos. They use the common organizational ontology and may relate to concepts and assets in other domains.
Domains are also not necessarily the same as organizational departments. Organizational structures may change while the underlying areas of organizational meaning remain relatively stable.
Current Domains¶
Finance¶
Data relating to the organization's financial activities, performance, controls, and financial decision making.
Initial scope includes:
- Revenue
- Expenses
- Invoices
- Payments
- Accounts receivable
- Accounts payable
- Budgets
- Financial transactions
- Cash flow
- Financial reporting
- Forecasting
- Financial controls
- Tax and statutory compliance
- Financial risks
- Financial performance
Finance provides financial context to other domains, including Products, Projects, People, Sales and Marketing, and Technology and Engineering.
People¶
Data relating to people within the organization and the organizational structures through which people work.
Initial scope includes:
- Employees
- Contractors
- Roles
- Teams
- Departments
- Organizational structure
- Recruitment
- Employee lifecycle
- Responsibilities
- Skills
- Workforce planning
- Staffing
- Performance
- Attendance
- Leave
- Compensation
- Employee engagement
- Training and development
People provides workforce and organizational capacity context to Projects, Products, Technology and Engineering, Sales and Marketing, and Organizational Operations.
Projects¶
Data relating to projects and coordinated organizational initiatives.
Initial scope includes:
- Projects
- Milestones
- Tasks
- Deliverables
- Resources
- Project teams
- Dependencies
- Project schedules
- Project progress
- Project performance
- Project risks
- Project costs
- Project documentation
- Project outcomes
Projects provides the delivery context connecting organizational objectives with People, Products, Finance, Sales and Marketing, and Technology and Engineering.
Products¶
Data relating to products and services developed, maintained, or delivered by the organization.
Initial scope includes:
- Products
- Product components
- Features
- Releases
- Product requirements
- Product readiness
- Product capabilities
- Customers
- Product usage
- Product performance
- Customer feedback
- Product adoption
- Product revenue
- Product costs
- Product documentation
Products connects market needs and organizational outcomes with Projects, Technology and Engineering, Sales and Marketing, Finance, and Customers.
Sales and Marketing¶
Data relating to customer acquisition, commercial activity, market engagement, marketing activity, business development, partnerships, and external market presence.
Initial scope includes:
- Leads
- Opportunities
- Prospects
- Customers
- Partners
- Proposals
- Sales activities
- Marketing activities
- Business development
- Partnerships
- Sales pipeline
- Meetings
- Conversion
- Customer acquisition
- Customer retention
- Revenue attribution
- Market activity
- Campaigns
- Social media
- Social accounts
- Published content
- Audience metrics
- Content performance
- Engagement
- Reach and impressions
- Platform activity
- Cross platform metrics and KPIs
Social Media is treated as a channel and measurement area within Sales and Marketing rather than as a separate top level domain.
Initial social media sources include:
- X
- TikTok
Technology and Engineering¶
Data relating to the organization's technology capabilities, engineering activities, technical systems, technical investments, and technology related decision making.
Initial scope includes:
- Software engineering
- Engineering teams
- Architecture
- Applications
- Services
- Infrastructure
- Technical delivery
- Technical capacity
- Technical debt
- Engineering quality
- Technology investments
- Cloud and infrastructure costs
- AI engineering
- AI services
- System reliability
- System performance
- Technical incidents
- Technical telemetry
- Observability
Observability is treated as a capability within Technology and Engineering rather than as a separate top level domain.
The Observability scope includes:
- Metrics
- Logs
- Traces
- Services
- Infrastructure
- Requests
- Errors
- Latency
- Availability
- Alerts
- Incidents
- Operational telemetry
Potential observability sources include OpenTelemetry, Prometheus, Loki, and Jaeger.
Technology and Engineering provides the technical context connecting People, Projects, Products, Finance, and organizational outcomes.
Organizational Operations¶
Data relating to the organization's internal processes and day to day operations.
Initial scope includes:
- Processes
- Activities
- Procedures
- Controls
- Responsibilities
- Service levels
- Operational performance
- Organizational workflows
- Internal requests
- Approvals
- Administrative activities
- Cross functional coordination
- Operational communications
Organizational Operations provides context for activities that support the functioning of the organization but do not belong exclusively to another specialized domain.
The domain should remain deliberately broad without becoming a general repository for concepts that belong more naturally to Finance, People, Projects, Products, Sales and Marketing, or Technology and Engineering.
Cross Cutting Organizational Knowledge¶
Knowledge is not treated as a separate organizational domain.
Organizational knowledge can originate from any domain and may describe or connect concepts across multiple domains.
Examples include:
- Documents
- Policies
- Procedures
- Meeting records
- Decisions
- Contracts
- Proposals
- Guidelines
- Lessons learned
- Institutional memory
- Organizational context
Knowledge assets may therefore belong to or reference:
Finance
People
Projects
Products
Sales and Marketing
Technology and Engineering
Organizational Operations
For example, a project decision may originate in Projects but reference People, Products, Finance, and Technology and Engineering.
A policy may originate in Organizational Operations but define processes involving People and Finance.
This allows organizational knowledge to remain connected to the domain context in which it was created without requiring Knowledge to become another top level domain.
Domain Boundaries¶
Domains provide context rather than ownership of the underlying ontology.
For example, Person is a core concept and may appear in:
People
Projects
Finance
Sales and Marketing
Organizational Operations
Technology and Engineering
The concept remains the same even when its domain context changes.
Similarly, Metric may appear across:
Finance
Projects
Products
Sales and Marketing
Technology and Engineering
The definition of the core concept remains common while individual metrics are domain specific.
A Customer may appear in Products and Sales and Marketing.
A Project may reference People, Finance, Products, and Technology and Engineering.
A System may belong to Technology and Engineering while supporting Products, Projects, Finance, or Sales and Marketing.
The domain provides context for the concept without changing its canonical meaning.
Cross Domain Relationships¶
Organizational data is expected to cross domain boundaries.
For example:
Sales and Marketing
↓
Customer Demand
↓
Products
↓
Product Requirements
↓
Projects
↓
Technology and Engineering
↓
Product Delivery
↓
Finance
↓
Revenue / Cost / Profitability
Another example:
People
↓
Capacity / Skills
↓
Projects
↓
Delivery
↓
Products
↓
Customer Outcomes
↓
Sales and Marketing
Another:
Technology and Engineering
↓
System Observability
↓
System Reliability
↓
Product Performance
↓
Customer Experience
↓
Sales and Marketing
Another:
Finance
↓
Budget / Actuals
↓
Projects
↓
Resource Allocation
↓
Products
↓
Business Outcomes
Another:
Sales and Marketing
↓
Revenue / Pipeline
↓
Finance
↓
Cash Flow
↓
Organizational Planning
↓
Projects / Products / People
These connections are a fundamental reason for maintaining a common organizational model.
Domain Evolution¶
Domains are expected to evolve.
A concept initially introduced within one domain may be promoted to the core ontology when it becomes broadly applicable.
Conversely, concepts that prove to be highly domain specific should remain within their domain.
A capability or source may also begin as a distinct area of modelling and later become part of a broader domain when its relationship to the organization becomes clearer.
For example:
Social Media
↓
Sales and Marketing
and:
Observability
↓
Technology and Engineering
The distinction between core concepts, domain concepts, and domain capabilities is therefore based on semantic scope rather than implementation convenience.
Domain Status¶
| Domain | Status | Priority |
|---|---|---|
| Finance | Active | High |
| People | Active | High |
| Projects | Active | High |
| Products | Active | High |
| Sales and Marketing | Active | High |
| Technology and Engineering | Active | High |
| Organizational Operations | Active | Medium |
The domain list is intentionally non exhaustive.
New domains should be introduced only when the organization's data, processes, decisions, or knowledge demonstrate a coherent area of meaning that cannot be represented effectively within an existing domain.
Domain capabilities and subareas may be introduced without creating new top level domains.
For example:
Sales and Marketing
└── Social Media
Technology and Engineering
└── Observability
This allows the model to grow without unnecessarily increasing the number of top level domains.