Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in or
create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision |
Your text |
| Line 1: |
Line 1: |
| 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. | | A '''service model''' is an abstraction of a service, usually created for the purpose of scaling or automation. |
| | |
| 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.
| |