Model Service
This page explains the service domain of the model. It is the layer where business meaning becomes operational commitment: what is provided, for whom, under what expectations, through which responsibilities, and with what performance implications.
Intro
The service model matters because it is the hinge between business intent and technical realization. A business model can express goals, capabilities, and obligations, but service is where those things begin to take accountable operational form.
That means the service domain is not just a catalog of named services. It is where provider and consumer relationships, commitments, performance expectations, and realised value start to become explicit.
Diagram
The service domain at a high level
At a high level, the service domain should help explain:
- what is being provided
- who provides it and who depends on it
- what responsibilities and expectations exist around it
- what commitments, levels, and conditions apply
- how service performance is interpreted
- how business meaning connects to technical realization
This is why service sits between business and technology. It translates purpose and capability into something operationally accountable.
Service as relationship, not just object
A service should not be treated as only a named thing in a register. In many cases, service is better understood as a structured relationship involving:
- a provider
- a consumer or beneficiary
- an offering or capability in use
- commitments and expectations
- operating conditions
- evidence of delivery and quality
That makes service semantics inherently relational. It is not only about the existence of a service, but about the commitments and outcomes that surround it.
What the service model needs to hold together
A strong service model usually needs to connect several concerns at once:
- service identity and boundaries
- provider and consumer roles
- offerings and dependencies
- obligations and agreements
- service levels and quality expectations
- service performance and incidents
- escalation, continuity, and support structures
- traceability back to business goals and forward to applications, deployment, data, and infrastructure
If these are split into disconnected records, the organisation ends up with service language that sounds coherent but is structurally weak.
How service relates to the other domains
The service model is especially important because it reuses semantics from both above and below.
Above it, service depends on business semantics such as:
- goals
- capabilities
- policies
- accountability
- risk
- performance expectations
Below it, service is realized through technical domains such as:
- applications
- data
- deployment structures
- infrastructure
So service should be read as the translation domain that keeps those layers connected.
Why this matters for ontology
The service domain is one of the clearest places where first-class relationships matter. A mature ontology will likely need to treat things such as provider-consumer relations, commitments, agreements, obligations, and support dependencies as more than simple lines between boxes.
It also needs to distinguish clearly between:
- service definition
- service offering
- service agreement
- actual service delivery
- service incident or interruption
- measured service performance
Those distinctions are what make the service layer useful for governance, operations, and reasoning.
Next direction for this page
The next evolution of this page should make the service semantics more explicit around:
- service boundaries and decomposition
- provider, consumer, and accountability roles
- commitments, agreements, and levels
- incidents, continuity, and performance evidence
- traceability between business capability and technical realization
