Service model: Difference between revisions
No edit summary |
(much expanded, linked to relevant stuff here) |
||
| Line 1: | Line 1: | ||
A '''service model''' is an abstraction of a service, usually created for the purpose of scaling or automation. | A '''service model''' is an abstraction of a service, usually created for the purpose of scaling or automation. A [[consultant]], [[guild]] or [[faction]] will almost always have some pre-existing abstractions or assumptions to apply to this kind of task. | ||
It integrates several other models that are often difficult to scale or automate: a [[trust model]] (e.g. [[audit regime]] based on [[nonprofit]] [[faction]]s) and [[revenue model]] (e.g. [[self-funding]] [[healthy signal infrastructure]]) for instance. | |||
The most reliable way to work out a service model is with [[story fragment]]s that establish how the [[end user]] will comprehend or use the service in its newly deployed scale or level of automation. These stories are used to create a sort of [[mutual cognition]] or shared illusion of how the service "should" work. This can be compiled into [[best cases]]/[[visions]] and [[worst cases]]/[[threats]] as it becomes clear which features are desirable versus troublesome. | |||
Like any abstraction, service models must hide some detail and focus on others. It is impossible to know which details can be safely hidden or which must be fully explored, without some conception of the [[comprehensive outcome]] of the service in real use in the real world. That can't be created without some [[scenario analysis]], including possible failures of the trust or revenue assumptions. | |||
Latest revision as of 16:48, 25 November 2003
A service model is an abstraction of a service, usually created for the purpose of scaling or automation. A consultant, guild or faction will almost always have some pre-existing abstractions or assumptions to apply to this kind of task.
It integrates several other models that are often difficult to scale or automate: a trust model (e.g. audit regime based on nonprofit factions) and revenue model (e.g. self-funding healthy signal infrastructure) for instance.
The most reliable way to work out a service model is with story fragments that establish how the end user will comprehend or use the service in its newly deployed scale or level of automation. These stories are used to create a sort of mutual cognition or shared illusion of how the service "should" work. This can be compiled into best cases/visions and worst cases/threats as it becomes clear which features are desirable versus troublesome.
Like any abstraction, service models must hide some detail and focus on others. It is impossible to know which details can be safely hidden or which must be fully explored, without some conception of the comprehensive outcome of the service in real use in the real world. That can't be created without some scenario analysis, including possible failures of the trust or revenue assumptions.