Model Business

This page explains the business domain of the model. It is the part of the knowledge ontology concerned with organisational intent, capability, structure, governance, work, risk, value, performance, and evidence.

The point is not to treat business modelling as a loose collection of strategy words, process diagrams, policy shelves, and performance dashboards. The point is to describe how those things belong to one connected business domain.

Following classic perspectives have been leveraged to develop this:

• Enterprise and Strategic Planning
• Audit Management
• Performance Management
• Practice Management
• Policy Management
• Resource Management
• Compliance Management
• Organisational and Traning Development
• Risk and Reward Management
• Exception Management
• Task Management

Please call out more perspectives that need to be added.

Intro

The business model is where much of the organisation's meaningful structure becomes explicit. It is where identity, purpose, direction, capability, accountability, resources, obligations, risks, measures, and execution all need to relate.

That is why this page matters. The business domain is not just one layer among many. It is the main organisational meaning layer that connects strategy to work, governance to action, and performance to evidence.

Diagram

The business domain at a high level

At a high level, the business model is trying to hold together several major concerns at once:

• organisational identity and direction
• capability, function, and activity
• people, roles, and competence
• resources, offerings, and exchange
• requirements, policy, compliance, and control
• risk, failure, and mitigation
• performance, evidence, and assessment
• tasks, initiatives, and executable work

That breadth is not a flaw. It is the whole reason this domain matters. Business architecture becomes weak when these concerns are split into disconnected management artifacts that cannot explain one another.

Top-level conceptual flow

The easiest way to read the business domain is as a connected flow rather than as isolated subject buckets.

A useful top-level flow is:

1. identity and direction define what the organisation is, why it exists, and where it is trying to go
2. capability and function define what the organisation must be able to do and what stable responsibilities it carries
3. activity and execution define how that work is actually expressed through tasks, initiatives, and operational action
4. resources and offerings define what the organisation uses, produces, exchanges, and delivers
5. policy, requirements, and control define the constraints and obligations that shape permissible action
6. risk and mitigation define how the model accounts for exposure, failure, intervention, and resilience
7. performance, evidence, and assessment define how the organisation judges what happened and what needs to change

That is not a strict one-way pipeline. It is a conceptual flow that helps explain how the main business concerns depend on one another.

Strategy shapes capability. Capability shapes activity. Activity depends on people, roles, and resources. Governance constrains how that activity is allowed to happen. Risk and performance reveal what actually happened. Evidence and assessment then feed back into strategy, control, and change.

Shared subdomains and reused semantics

Another important point is that these are not separate mini-models with their own private truth. Many of the same underlying business concepts are reused across multiple subdomains.

For example:

• a goal can shape capability priorities, task selection, performance assessment, and risk appetite
• a role can appear in governance, execution, approval, accountability, and evidence trails
• a capability can be referenced by strategy, activities, offerings, controls, and performance measures
• a resource can matter simultaneously to value delivery, operational execution, risk exposure, and cost structure
• a requirement can appear in policy, compliance, projects, controls, and audit evidence
• a service or offering context can connect value, channels, activities, responsibilities, and measures

This is one of the main reasons the business domain should be treated as a connected semantic field. The same core structures need to be leveraged repeatedly across different business concerns. If each subdomain invents its own separate version of goals, roles, capabilities, resources, or evidence, the model fragments and the business layer stops being reusable.

So the page should be read as one domain with many perspectives, not many separate domains that happen to be placed next to each other.

Strategic identity and direction

A strong business model needs to represent more than operations. It needs to represent why the organisation exists, what it is trying to become, and how it intends to move.

This is why concepts such as these matter:

• vision
• mission
• values
• principles
• purpose
• strategy
• goals
• objectives
• tactics
• priorities
• opportunities
• impacts

These are not decorative statements. They provide the intentional structure that helps explain why capabilities are developed, why trade-offs are made, and why some work matters more than other work.

If the business model does not preserve this layer properly, then everything below it becomes harder to interpret. Capabilities float without direction. Activities lose strategic meaning. Performance loses context.

Capability, function, and activity

One of the core jobs of the business domain is to distinguish between what the organisation is able to do, what it is set up to do, and what it is actually doing.

Capability

A capability is an organisational ability or disposition. It is something the organisation can do under the right conditions. A capability is not a single process run, a task, or a role.

Function

A function is a relatively stable area of business responsibility. It helps describe how the organisation is organised to carry purpose-bearing work over time.

Activity

An activity is a more concrete unit of work or action. Activities and activity groups are where the model starts to move from enduring structure toward executable and governable work.

These distinctions matter. If capability, function, activity, process, and task are all treated as the same thing, the business model quickly becomes muddy and hard to reuse.

Organisation, roles, and competence

The business domain also needs to represent the agentive structure of the organisation. That includes concepts such as:

• organisation
• role
• job
• stakeholder
• contact
• membership
• authority
• units and departments
• competence
• skill
• competence planning

This matters because business architecture is not only about work design. It is also about who participates, who is responsible, who is authorised, and what competence exists or is missing.

Several distinctions are especially important here:

• an organisation is not just a box on a chart; it is a social agent
• a role is not the same as the person or organisation that currently plays it
• a job is not identical to a role; it is closer to a formal assignment or position structure
• competence and skill should not be collapsed into tasks, teams, or functions

Without this part of the model, business semantics become oddly disembodied.

Resources, offerings, and value exchange

A business model also needs to express what the organisation uses, produces, offers, exchanges, and depends on. That is why the diagram includes concepts such as:

• resources
• resource types and groups
• interfaces and interactions
• offerings
• inputs and outputs
• channels
• products and product lines
• value streams and value stages
• value propositions
• revenue, cost, equity, assets, and materials

This is where the business domain intersects with value creation and delivery. It helps explain:

• what the organisation draws on to operate
• what it creates or offers outwardly
• how value moves across boundaries
• how business meaning connects to economic and operational structure

That prevents the business layer from becoming a purely managerial or abstract planning language.

Requirements, policy, compliance, and control

A serious business model has to be governance-bearing. It cannot only describe what the organisation wants to do. It also has to describe the obligations, constraints, rules, and controls that shape permissible action.

That is why this part of the domain matters:

• requirements
• criteria
• policy
• rules, standards, and guidelines
• laws and regulations
• contracts
• waivers and exceptions
• compliance management
• audit management
• integrity
• corporate social responsibility

This is where the business domain becomes explicitly normative. It starts to express not only desired direction, but also what must be satisfied, what must be controlled, what can be violated, and what needs evidence.

In a stronger runtime-aware model, these structures should support distinctions such as:

• requirement definition
• applicability
• ownership
• review and assessment
• compliance evidence
• waiver or exception state

Risk, failure, and mitigation

Business modelling also has to account for breakdown, exposure, and intervention. The business domain is not only about the organisation at its ideal best. It also needs to explain what can go wrong, why it can go wrong, and what can be done about it.

That is why the risk branch is important:

• risk and reward
• vulnerability
• threat
• issue
• trigger
• event
• failure
• mitigation
• exception
• tolerance
• solution

This part of the domain becomes much clearer when the distinctions are kept strong:

• a risk is not the same as a failure
• a vulnerability is not the same as an actual incident
• a trigger is not the same as a long-term exposure
• a mitigation is not the same as a control already in force
• an exception is not the same as a permanent rule change

This branch is essential if the business model is meant to support governance, resilience, and operational reasoning rather than static description alone.

Performance, evidence, and assessment

One of the strongest features of this business domain is that it includes not just planning and structure, but also evaluation and proof.

That includes concepts such as:

• measures and metrics
• assessments
• evidence
• arguments
• claims
• effectiveness
• efficiency
• sustainability
• KPI, KRI, KQI, SLA, and benchmarks
• planned and actual performance

This matters because the business model should not stop at intention. It should also support judgement. It should help the organisation connect:

• what it intended
• what it did
• what happened
• how it knows
• what should change next

This is where the model becomes much more useful than a typical strategy/process/policy bundle. It becomes a reasoning structure rather than just a documentation structure.

Tasks, initiatives, and executable work

The business domain also needs to connect enduring business meaning to finite execution. That is why this area matters:

• task
• task members
• task attributes
• initiatives
• milestones
• programs
• projects
• schedules
• agendas
• use cases
• canvases

This branch is the bridge from relatively stable business semantics into actual work slices. It is where the organisation turns direction and structure into commitments, plans, and execution.

This area needs careful distinction between:

• normative task or process definitions
• planned work
• scheduled work
• actual task or activity occurrences
• larger initiative and project containers

If these are kept separate, the model can support both governance and execution without confusion.

Why this domain matters for ontology

The business page should not only describe a business architecture catalog. It should also prepare the ground for stronger ontology.

That means the business domain eventually needs to become clearer about questions such as:

• which concepts are enduring entities
• which are roles or positions
• which are relationships that need first-class treatment
• which are events or occurrences
• which are qualities, measures, assessments, or evidence artifacts
• which concepts are normative and which are retrospective

These distinctions are what allow the business layer to become rigorous enough for reuse, reasoning, traceability, and runtime interpretation.

Business modelling as connected domain structure

The main thing this page should make clear is that business modelling is not just about process maps or strategic headings. It is about the connected structure of organisational meaning.

A strong business model links:

• identity and direction
• capability and work
• people and responsibility
• resources and offerings
• obligations and controls
• risk and intervention
• performance and evidence
• execution and learning

That is why this domain is so central. It is where the organisation becomes legible to itself in business terms.

Next direction for this page

The next evolution of this page should strengthen the domain explanation even further by making several semantic distinctions more explicit:

• core ontological categories such as entity, role, relator, event, quality, and artifact
• normative versus retrospective business structures
• clearer separation between capability, function, activity, process, and task
• clearer lifecycle treatment for risk, trigger, failure, mitigation, and exception
• stronger treatment of evidence, argument, claim, and assessment chains

Those refinements would make the page even more useful as a true business-domain entry point into the ontology.