Complexity Lens – 2015 Conference

Nanyang Technological University
July 9 – 10, 2015

Emerging Patterns – 2015 Conference

Nanyang Technological University
March 2 – 4, 2015

SL Vargo, RF Lusch – Recent developments of Service-Dominant Logic (readings)

Foundations of Service-Dominant Logic

Service Ecosystems

Innovation, Institutionalization, and Technology

Value Co-creation

Experience and Engagement

Modeling Service Systems with LSS-USDL

After Cardoso, Lopes, and Poels – Service systems, concepts, and modeling – Ch 4 Modeling and programming (2014).

Here we consider how a service system can be modeled with LSS-USDL using semantic web languages and technologies. Later we will consider:

  • how a service system model can be accessed and queried programmatically (we chose Python because stable software libraries to access and modify RDF models are available)
  • how a service system model can be annotated with background knowledge from the Linked Data Cloud (we chose DBpedia since it is one of the largest existing knowledge basis)


The methodology we have followed consisted in

  • looking at the IM service as a flow of interactions
  • using the LSS-USDL model to capture each interaction

In other words, each interaction was analyzed by answering the questions: who, why, where, when, what, and how. The answers to these questions provided detailed information about the more relevant interaction features, such as: roles, goals, locations, time, resources, and processes, completing the model information.


The modeling exercise with Turtle and using the LSS-USDL model begins by specifying a set of prefixes. Prefixes are a convenient method for representing a name space URI with a short string. Prefixes facilitate the reference to other ontologies in an easy and unambiguous way. Each prefix refers to a basilar ontology which is used to model the service.

There are some common ontologies used by many models or instances: rdf, rdfs, owl, and xml. The most specialized ontologies we have used are:

  • GoodRelations (gr) [1] references the GoodRelations ontology, a standardized vocabulary to describe product, price, store, and company data.
  • Friend of a Friend (foaf) is an ontology describing persons, their activities, and their relations to other people and objects.
  • Time Ontology (time) covers basic temporal relations. The ontology allows to capture temporal relationships such as before and during.

The use of external vocabularies and ontologies enables to integrate the service instance to a large base of knowledge made available by many organizations and initiatives.


As a first step to build our IM service instance, we define a new instance of service system named IncidentManagementService. It is a new class that inherits all the properties of the class lss-usdl:ServiceSystem. To provide descriptive information to this new service, we used the RDFS predicates label, comments, and the LSS-USDL term hasGoal. See lines 1–4 of Listing 4.2.

The incident management service handles incidents (e.g., failures, questions, or queries reported by users) and consists of the following steps:

  1. Identification
  2. Logging
  3. Classification
  4. Prioritization
  5. Diagnosis
  6. Escalation
  7. Investigation and diagnosis
  8. Resolution and recovery
  9. Closure

Steps were captured as instances of lss-usdl:Interaction with the predicate hasInteraction (Listing 4.2, lines 6–14). Thus, IncidentIdentification, IndicentLogging, etc. are instances of lss-usdl:Interaction.

  1. :IncidentManagementService  an lss-usdl:ServiceSystem ;
  2. rdfs:label “ITIL Incident Management Service”;
  3. rdfs:comment “A service system for Incident Management, based on ITIL specs. The main objective of the incident management process is to resume the regular state of affairs as quickly as possible and minimize the impact on business processes.” ;
  4. lss-usdl:hasGoal :SolveIncident ;
  5. lss-usdl:hasInteraction
  6. :IncidentIdentification ,
  7. :IncidentLogging ,
  8. :IncidentClassification ,
  9. :IncidentPrioritization ,
  10. :InitialDiagnosis ,
  11. :IncidentEscalation ,
  12. :InvestigationDiagnosis ,
  13. :ResolutionRecovery ,
  14. :IncidentClosure .

Listing 4.2 The first building block to construct a service system.

The following sections will detail how each interaction was modeled.

4.2.3 Interactions

Since there are nine interactions (i.e. nine instances of lss-usdl:Interaction, we will only describe two of them, which is sufficient to illustrate how modeling is performed: IncidentLogging and Initial Diagnosis. The complete specification of the interactions can be found at http:// Each interaction answers to six questions: who (roles), why (goals), where (locations), what (resources), when (time), and how (processes). Incident Logging

Essential step in managing incidents is to receive and record them. This is carried out by the Incident Logging interaction. When it is determined that an incident has occurred through a Service Desk telephone call or automatically detected via an event alert, the logging interaction will document the incident. All relevant information describing the incident must be logged so that a full historical record is maintained. Logging should at a minimum record the date and time of the incident, the person/system reporting the incident, and a description of the problem. Listing 4.3 shows the complete specification for this interaction.

  1. :IncidentLogging  a lss-usdl:BackstageInteraction ;
  2. rdfs:label “An incident is logged”;
  3. rdfs:comment”Incidents reported to the Service Desk must be logged with the date and time stamp when they were generated.” ;
  4. lss-usdl:performedBy :ServiceDeskManager ;
  5. lss-usdl:hasGoal :DealWithReportedIncident ;
  6. lss-usdl:hasLocation :ABCompany ;
  7. lss-usdl:belongsToProcess :ITServiceIncidentManagement ;
  8. lss-usdl:consumesResource :ReportData ;
  9. lss-usdl:consumesResource :IncidentData ;
  10. lss-usdl:createsResource :IncidentID ;
  11. lss-usdl:createsResource :IncidentRecord .
  12. lss-usdl:hasTime
  13. [a lss-usdl:Time ;
  14. lss-usdl:hasTemporalEntity :IncidentLoggingTime] ;
  15. :IncidentLoggingTime a time:ProperInterval ;
  16. time:intervalAfter :IncidentIdentificationTime ;
  17. time:intervalBefore :IncidentCategorizationTime .

Listing 4.3 The Incident Identification interaction.

The example illustrates that the interaction is described as a Backstage Interaction, which is performed by the ServiceDeskManager role; it has the DealWithReportedIncident goal; it is performed at the ABCompany location; it belongs to the ITServiceIncidentManagement process; it consumes two knowledge resources (IncidentData and ReportData) and it creates two knowledge resources (IncidentID and IncidentRecord). The interaction has also a temporal entity associated which allows specifying that this interaction occurs before the IncidentCategorization interaction and after the Incident Identification interaction.

The knowledge resources IncidentData and ReportData typically include the following information:

  • Basic information needed to handle the incident, such as date and time of the occurrence, description of the incident, and systems affected.
  • Supporting information for the resolution of the incident that may be asked to the submitter using, possibly, a specific form.

The IncidentRecord will aggregate these information and will assign a reference to the incident to uniquely identify it in both internal processes and when communicating with the person affected by the incident. Initial Diagnosis

The Initial Diagnosis is the fourth step in the incident management process.It follows the incident categorization. The initial diagnosis is the first attempt at resolving an incident. Typically, the technical staff of the Service Desk will carry out an initial diagnosis and will try to understand the incident being reported.He will try to discover the full symptoms of the incident, determine what went wrong, and how to solve the problem. If available, diagnostic scripts and known error information is valuable in allowing an earlier and accurate diagnosis. The interaction described in Listing 4.4 represents the initial diagnosis of an incident performed by the technical staff of the Service Desk.

  1. :InitialDiagnosis a lss-usdl:BackstageInteraction ;
  2. rdfs:label “An initial diagnosis for the incident is performed”;
  3. rdfs:comment”The initial diagnosis of incidents is mainly a human process. The Service Desk technical staff looks at the information within the incident and communicates with the user to diagnose the problem.” ;
  4. lss-usdl:performedBy :TechnicalStaff ;
  5. lss-usdl:hasGoal :HandleIncident ;
  6. lss-usdl:hasTime [a lss-usdl:Time ;
  7. lss-usdl:hasTemporalEntity :InitialDiagnosisTime] ;
  8. lss-usdl:hasLocation :ABCompany ;
  9. lss-usdl:belongsToProcess :ITServiceIncidentManagement ;
  10. lss-usdl:consumesResource :IncidentRecord .
  11. :IncidentInitialDiagnosisTime a time:ProperInterval ;
  12. time:intervalAfter :DetermineIfIncidentIsMajorTime ;
  13. time:intervalBefore :DetermineIfFunctionalScalationIsNeededTime .

Listing 4.4 The Initial Diagnosis.

The interaction is described as a BackstageInteraction which is performed by the ServiceDeskStaff role; it has the HandleIncident goal; it is performed at the ABCompanylocation;it belongs to the ITServiceIncident Management process and it consumes the knowledge resource Incident Report.The interaction has also a temporal entity associated, which allows specifying that it occurs before the DetermineIfFuntionalScalationIsNeeded Time interaction and after the DetermineIfIncidentIsMajorTime interaction.

4.2.4 Roles

Each interaction has a performedBy predicate indicating who is participating in the interaction. In some cases, there are many roles for the same interaction. Roles can belong to an entity. In such a case, the concept Business Entities from GoodRelations is used. While the number of roles depends on the ITIL implementation that a company chooses to make, we have compiled a list of 5 roles which are typical:

  • Service Desk Manager. Functions as the primary point of contact for incidents reported from users. The role owns the results of the service desk function.
  • Problem Manager. Responsible for managing the life-cycle of all problems. The primary objectives are to prevent incidents from happening and to minimize the impact of incidents that cannot be prevented.
  • Incident Manager. The role assigned to the person who owns the results of the Incident Management service and of its effective implementation.
  • Technical Staff. Aggregates the first,second,and third-tier support groups,including specialist support groups and external service providers.
  • End User. The end users and employees of a company that experience difficulties with IT and which rely on services to restore a normal processing as quickly as possible after an incident has occurred.

Listing 4.5 describes these roles using the LSS-USDL model.Each role has a label and a brief description as well as an assignment to a business entity it belongs to.Most of the roles belong to the ABCompany company, except the role ProblemManager which belong to the ExtCompany company.

  1. :ServiceDeskManager a lss-usdl:Role ;
  2. rdfs:label “Service Desk Manager”;
  3. rdfs:comment”Functions as the primary point of contact for incidents reported from users.”;
  4. lss-usdl:belongsToBusinessEntity :ABCompany.
  5. :ProblemManager a lss-usdl:Role ;
  6. rdfs:label”Problem Manager”;
  7. rdfs:comment”Responsible for managing the lifecycle of all problems.”;
  8. lss-usdl:belongsToBusinessEntity :ExtCompany .
  9. :IncidentManager a lss-usdl:Role ;
  10. rdfs:label”Incident Manager”;
  11. rdfs:comment”The person who owns the results of the Incident Management service”;
  12. lss-usdl:belongsToBusinessEntity :ABCompany .
  13. :TechnicalStaff a lss-usdl:Role ;
  14. rdfs:label”Technical Staff”;
  15. rdfs:comment”Support technical staff”;
  16. lss-usdl:belongsToBusinessEntity :ABCCompany .
  17. :EndUser a lss-usdl:Role ;
  18. rdfs:label”End User”;
  19. rdfs:comment”The end users and employees of a company that experience difficulties with IT.” ;
  20. lss-usdl:belongsToBusinessEntity :ABCompany .

Listing 4.5 Modeling roles and business entities

Not all the roles defined were used in the examples of this chapter. The objective was to show how role modeling can be achieved. To structure and organize the many roles that can exist, the knowledge organization systems SKOS can be used to construct a classification schema or a taxonomy.

4.2.5 Goals

The concept of goal has been used in many domains such as business sciences and strategic planning. The objective is to provide a planning framework which links goals with interactions. It is intended to assist ITIL service owners in understanding the effects of interactions on services.

Each interaction has a one, or more, hasGoal predicate(s), indicating the goal(s) a specific interaction occurs. Listing 4.6 shows examples of several goals.

  1. :ReportIncident a lss-usdl:Goal ;
  2. rdfs:label “Report Incident”;
  3. rdfs:comment”A user, technical staff or system reports an incident regarding an IT service.”.
  4. :HandleIncident a lss-usdl:Goal ;
  5. rdfs:label”Handle Incident”;
  6. rdfs:comment”Execute several actions to deal with a reported incident.”.
  7. :RestoreNormalOperation a lss-usdl:Goal ;
  8. rdfs:label”Restore Operation”;
  9. rdfs:comment”Restore the normal service operation as quickly as possible.” .

Listing 4.6 Modeling the goals of interactions.

Since goals are targets for achievements, they should be written in such a way that they express the rationale for the interactions that exist and guides decisions at various levels within the enterprise. Here again, the SKOS can be used to organize goals using, e.g., structured controlled vocabularies.

4.2.6 Locations

The class lss-usdl:Location is concerned with the geographical location of the IM service interactions. Locations can be expressed simply as a list of the places where interactions occur, or they can take a more detailed form by describing how locations are related or detailing the facilities/IT that are available in each location.

Each interaction has a hasLocation predicate indicating where the interaction happens. For the IM service, we have identified two locations: the ServiceDesk Office and the UserOffice. The ServiceDeskOffice represents the location where a user or system can report an incident and the UserOffice location refers to the location where the company staff is working.

  1. :ServiceDeskOffice a lss-usdl:Location ;
  2. rdfs:label “Service Desk Office”.
  3. :UserOffice a lss-usdl:Location ;
  4. rdfs:label”User Office” .

Listing 4.7 Modeling locations within a service system.

The Listing 4.7 shows the definition of both locations. While these locations are concepts that only have a meaning for the company implementing the IM service, another approach to use geographical descriptions. This can be achieved by using, e.g., the GeoNames ontology, a data structure containing over 8.5 million geographical names. The information covers coordinates, administrative divisions, postal codes, amongst others. GeoNames can answer questions such as what are the coordinates for a location; which region or province does a location belong to; and what city or address is near a given GPS latitude / longitude.

4.2.7 Time

Each interaction uses a hasTime predicate to indicate when it occurs. The Time ontology is used for temporal reasoning. Typically, two time modeling options can be defined. The first one, used in this example, defines temporal relationships between interactions using constructs such as before or after.The second,uses time intervals of times point to define when an interaction can occur or occurs. Listing 4.8 exemplifies the use of the concept ProperInterval to describe the temporal dependencies between interactions.

  1. :IncidentIdentificationTime a time:ProperInterval;
  2. time:intervalAfter :IncidentCategorizationTime .
  3. :IncidentCategorizationTime a time:ProperInterval;
  4. time:intervalBefore :IncidentIdentificationTime;
  5. time:intervalAfter :IncidentPrioritizationTime .
  6. :IncidentPrioritizationTime a time:ProperInterval;
  7. time:intervalBefore :IncidentCategorization;
  8. time:intervalAfter :InitialDiagnosisTime .
  9. :InitialDiagnosisTime a time:ProperInterval;
  10. time:intervalBefore :IncidentPrioritizationTime;
  11. time:intervalAfter :InvestigationDiagnosisTime .
  12. time:intervalBefore :InitialDiagnosisTime;
  13. time:intervalAfter :ResolutionRecoveryTime;
  14. time:intervalEquals :scalationFirstTime .
  15. :ResolutionRecoveryTime a time:ProperInterval;
  16. time:intervalBefore :InvestigationDiagnosisTime;
  17. time:intervalAfter :IncidentClosureTime;
  18. time:intervalEquals :scalationSecondTime .
  19. :IncidentClosureTime a time:ProperInterval;
  20. time:intervalBefore :ResolutionRecoveryTime.
  21. :scalationFirstTime a time:TemporalEntity;
  22. rdfs:label “Scalation time for first level”;
  23. rdfs:comment”Need to define hasDurationDescription”.
  24. :scalationSecondTime a time:TemporalEntity;
  25. rdfs:label”Scalation time for second level”;
  26. rdfs:comment”Need to define hasDurationDescription” .

Listing 4.8 Modeling time within a service system.

4.2.8 Resources

Interactions can use the receivesResource, consumesResource, createsResource, or returnsResource predicate to indicate the resources received, consumed, created, or returned. For the IM service, we have defined that the interaction IncidentLogging consumes knowledge from the user in the form of ReportData and IncidentData and creates two new resources: IncidentID and IncidentRecord. Listing 4.9 defines the resource IncidentRecord.

  1. :IncidentRecord a lss-usdl:KnowledgeResource ;
  2. rdfs:label “Incident Record”;
  3. rdfs:comment”An Incident Record generated during the IncidentLogging” ;
  4. owl:sameAs dbpediar:Incident_report .
  5. :Severity a rdf:Property ;
  6. rdfs:domain :IncidentRecord ; 8 rdfs:range xsd:integer .

Listing 4.9 Modeling the resources associated with interactions.

Naturally, the IncidentRecord should include more fields, besides Severity, to reflect the complexity of records, which describe an incident. Our example is simple to convey the principle of resource and their descriptions.

4.2.9 Process

Each interaction belongs to a business process model (concept), which can be specified using the property belongsToProcess (see Listing 4.3). In turn, the process model can be associated with an implementation, which can be made using, e.g., the Business Process Modeling Notation (BPMN) or Event-driven Process Chain (EPC) notations.

  1. :ITServiceIncidentManagement a lss-usdl:Process ;
  2. rdfs:label “Incident Management Business Process Model” ;
  3. lss-usdl:hasBPMN bpmnrep:IM_BPMN .

Listing 4.10 Modeling the process to which interactions belong.

Listing 4.10 shows a process model ITServiceIncidentManagement created to exemplify the use of the property hasBPMN to associate an implementation with the model, which, in this case, can be accessed at bpmnrep:IM_BPMN. While LSS-USDL only includes one property to attach BPMN processes to a service system, this was done as a proof of concept and additional properties can be specified to relate interactions with other process modeling languages.


  1. Jan Van Bon, Arjen de Jong, and Axel Kolthof. Foundations of IT Service Management based on ITIL. Van Haren Publishing, 2007.
  2. Kerstin Gerke, Jorge Cardoso, and Alexander Claus. Measuring the compliance of processeswith reference models. In 17th International Conference on Cooperative Information Systems (CoopIS), Algarve, Portugal, 2009. Springer.
  3. Martin Hepp. Goodrelations: An ontology for describing products and services offers on theweb. In Knowledge Engineering: Practice and Patterns, pages 329–346. Springer, 2008.
  4. ITIL Service Operation. ITIL Series. Stationery Office, 2007.
  1. 2 Step-by-step modeling
  2. 2.1 Prefixes and external vocabularies
  3. 2.2 The Service System

Conceptual models of service and service system

After Cordoso, J, R Lopes, and G Poels – “Conceptual frameworks” in Service Systems: Concepts, modeling, and programming (2014).


This chapter presents four theories from different academic disciplines that provide a comprehensive view of service. According to Gregor’s taxonomy of theory types [6], the theories presented are theories for analysis. This means that they offer concepts to describe, understand and analyze an object of study (i.e., what is), but do not explain or predict phenomena (i.e., why something is or what will be), nor provide prescriptions to create objects or cause events (i.e., how to do something).

The four reviewed theories are suitable for developing a concept base that can be used for selecting concepts when designing a conceptual service system model as the basis for the LSS-USDL service description language. The service concepts described by these theories constitute an interdisciplinary knowledge base that allows achieving rigor when designing the intended model and language, providing a theoretical foundation and justification for their construction [8].

The theories selected for this chapter are:

The Service-Dominant Logic is a descriptive theory of service from the Marketing discipline. It has been proposed as the philosophical basis of the new inter-disciplinary field of Service Science, Management, and Engineering (SSME) – Service Science in short – which studies service systems with the aim of creating the systemic knowledge required for sustainable service innovation [19].

To complement the marketing perspective of service, with its strong emphasis on the creation of customer benefits, the second reviewed theory is drawn from the Operations Management discipline. The Unified Services Theory describes the service production process and allows analyzing the efficiency and quality of this process. Thirdly, a “work system” perspective, i.e., viewing an object of study as a system in which work is performed, allows understanding service as a system (socio-technical or automated) in an organizational context [3]. The Work system metamodel provides an operational view of service systems (and work systems in general) that offers the basis for detailed analysis of the system’s form, function and environment [2].

This operational view is finally complemented by an economic view that also considers aspects related to the exchange of service. This view is obtained through application of the Resource-Event-Agent ontology, originally from the Accounting discipline, as a model of economic exchange. Applying this ontology to service systems has resulted in the Resource-Service-System model of service exchange, which is the fourth theory presented in this chapter.

The combination of theories from multiple disciplines, each offering a partial perspective on service, leads to the creation of a more complete concept base that covers different economic, management, and engineering aspects related to service. This ambition is fully in line with the purpose of the new SSME field as it is with the design of a conceptual model of service system that can serve as the foundation of a white-box service description language. The next sections will present the selected descriptive theories of service. To build the concept base for the intended service system conceptualization, an integrated concept map with concepts from the different theories is gradually constructed throughout Sects. 2.2 to 2.5.


The growing importance of service and service systems and the rising demand for service innovation and, hence, increasing investments in service R&D have often been motivated by the global sectorial shift in gross domestic product and employment from agriculture and industry to service (see, e.g., [9]). The difference between the declining second economic sector and the rising third sector is traditionally (and officially in governmental reports) made on the basis of the output of economic actors, producing either goods (second sector) or services (third sector).

Services are seen as products that are different from goods in terms of the IHIP characteristics: intangibility, heterogeneity, inseparability (of production and consumption), and perishability [13]. From a management perspective, the IHIP characteristics are considered as shortcomings, making it more di cult to properly handle services, e.g., with respect to their design, production, quality assurance, and marketing. To find answers to these shortcomings, dedicated service research disciplines like service management, service operations, service design, service engineering, etc. emerged.


ServiceDominant Logic [20, 10, 22] promotes an economic world view in which all economic exchange is seen as the exchange of service for service. Service is the application of one’s competences for the benefit of someone else. The benefits of service are determined by the beneficiary in terms of value-in-use (i.e., what utility is assigned to the application of competences) and value-in-context (i.e., how are the benefits experienced in the subjective ad hoc context of the beneficiary), rather than value-in-exchange (i.e., what is the monetary value of the service).


The descriptive theory of Service-Dominant Logic is expressed through ten foundational premises (FPs) [23]:

FP1. Service is the fundamental basis of exchange.

FP2. Indirect exchange masks the fundamental basis of exchange.

FP3. Goods are a distribution mechanism for service provision.

FP4. Operant resources are the fundamental source of competitive advantage.

FP5. All economies are service economies.

FP6. The customer is always a co-creator of value.

FP7. The enterprise cannot deliver value, but only offer value propositions.

FP8. A service-centered view is inherently customer-oriented and relational.

FP9. All social and economic actors are resource integrators.

FP10. Value is always uniquely and phenomenologically determined by the beneficiary.

FP1 asserts that what economic actors exchange in service is the application of each other’s competences. Economic actors specialize in what they are best at doing based on their own knowledge and skills. Economic exchange occurs when actors apply their own specialized competences for the benefit of others; thus, all economies are service economies (FP5). FP6 (value co-creation) asserts that the service beneficiary is always involved in the creation of value as he is the sole determiner of value (value-in-use and value-in-context) (FP10) and the actor who applies specialized competences (i.e., operant resources) can only offer value propositions (FP7) which help to create value with and for the beneficiary. FP9 (resource integration) asserts that economic actors need to integrate the resources they acquire as service beneficiaries into their own resources in order to survive and prosper, and to continue being able to apply specialized competences themselves.


The concept map of Figure 1 summarizes the key concepts that Service-Dominant Logic uses to describe service. Resources are of two kinds as determined by the service context under consideration: operant resources represent competences (i.e., knowledge and skills) or their embodiments (e.g., persons, organizational units, software agents, automated devices) that act upon other resources; Operand resources are resources that are acted upon or with like passive resources such as tools, materials, and data, but possibly also resources that may be active in another service context like persons, machines, and software. Actors exchange services by providing resources. The acting of operant resources on operand resources is what is called service, meaning an actor applying competences for the benefit of another actor. Through the exchange of service for service actors integrate resources that are made available, accessible or more valuable (as determined by the service beneficiary) by other actors, into their own resources. Value is always co-created by the beneficiary actor. It is the beneficiary actor who determines whether a service resulted in value. Therefore, an actor can only offer a value proposition concerning some service and cannot solely create value for the beneficiary actor.

Concept map Service-Dominant Logic

Figure 1. Concept map Service-Dominant Logic.


The Unified Services Theory [18] was developed for providing a distinctive, yet integrative paradigm and common language for service management researchers. It is meant as a descriptive theory that defines concepts relevant to service management from a primarily, though not exclusive production perspective. As opposed to the Service-Dominant Logic, the Unified Services Theory recognizes the distinction between services and non-services. Its operational implications, therefore, address the challenges that are unique to the management of service processes.


The theory does not define the concept of service directly, but talks about service processes. The object of study is the production process. An enterprise is a production system consisting of possibly multiple production processes.

The basic tenet of the Unified Services Theory is that a service process is a production process in which each individual consumer provides significant inputs. Inputs are resources available to production. Consumer inputs can be of three kinds: the consumer himself (e.g., going to a hairdresser), information provided by the consumer (e.g., providing information to a solicitor for preparing a legal case) or tangible belongings of the consumer (e.g., getting one’s car repaired). Inputs that are not considered significant and hence do not allow qualifying a production process as a service process are general consumer feedback (e.g., a market research that provides ideas and requirements for a new product and, thus, informs production processes) and selecting and consuming the output from production processes. The latter activity is part of a consumption process in which consumers extract value by interacting with the output of production processes or with the service providers themselves.

The operational implications of the theory for service management focus strongly on what makes a production process a service process, i.e., the necessity of consumer inputs. For instance, according to the theory service quality depends in large part on the quality of the inputs that the consumer provides. Also, service processes can be made more efficient by reducing the variability in consumer inputs. Overall, it is the presence of consumer inputs that makes service processes harder to manage than non-service processes. The consumer-producer interaction required for service processes implies that consumers are also suppliers and, hence, service supply chains are always bidirectional [16].


The main concepts of the Unified Services Theory are shown in Figure 2. A process is a series of actions. Amongst different kinds of processes are production and consumption processes. Note that the theory also defines other kinds of processes like business processes and IT processes [17], but these are at this moment not relevant for understanding service.

A production process is a process that transforms inputs into outputs. An input is a resource available to production. Generally, the producers that own the production processes provide inputs to these processes.

Service processes are production processes in which also consumers provide or make available input resources (either themselves or information they have or their property). An output is a result of production. Consumers select outputs from production processes to satisfy their needs. The extraction of value, which is the satisfaction of consumers’ needs, is performed in consumption processes.

A concept not explicitly shown but present in the chain of relations in the concept map is that of consumer-producer interaction, which is bi-directional. Consumers influence producers by providing production inputs and producers influence consumers by acting on the consumer inputs.

Concept map Unified Services Theory

Figure 2. Concept map Unified Services Theory.


Joining the concept maps of the Service-Dominant Logic and the Unified Services Theory is not an easy operation, given their fundamentally different view of service. While service is defined as a process in the Service-Dominant Logic, it is not the same as the service process as intended by the Unified Services Theory which employs a more restricted meaning and distinguishes between service and non-service situations (such distinction would be nonsense in Service-Dominant Logic). While service in the Service-Dominant Logic requires co-creation between the producer/provider and consumer/beneficiary, the acts of the service provider (or producer) and beneficiary (or consumer) might overlap completely or partially but also be completely independent in space and time; hence, the resource integration and resulting value capture by the beneficiary might happen long after and in a different location than the provider’s activities.

This scenario is consistent with what happens in the consumption process of the Unified Services Theory where the consumer may extract value from outputs of non-service production processes without any interaction with the producer. However, to qualify as a service process, the production process needs consumer inputs, which implies some degree of overlap in time and space between producer and consumer activities. As noted in [18], this interaction is, however, not as restrictive as requiring co-production as the provision of the consumer’s labor is only one possible type of consumer input into the production process.


The notion of value as satisfying needs in the Unified Services Theory is close to the notion of value-in-use in the Service-Dominant Logic, hence, value seems a common concept in both maps. Also in both theories it is the consumer/beneficiary that determines and captures the value. The resource integration in the Service-Dominant Logic and the value extraction to satisfy needs in the Unified Services Theory are, therefore, similar. To integrate both concept maps, value can, therefore, be used an anchor point. Further we see that consumer and producer in the Unified Services Theory are specializations (and actually roles) of actor in the Service-Dominant Logic. The inputs in the Unified Services Theory are resources in the Service-Dominant Logic.

As the purpose of the conceptual model we develop in this chapter is the creation of a concept base for the design of a white-box service description language and the Unified Services Theory offers more details on the “internals” of service, we start the integration from the concept map of this theory. Given the differences between both theories, the integrated concept map should allow for multiple interpretations of concepts to co-exist. Hence, we include in the concept map of Figure 3 concepts from the Service-Dominant Logic to extend the concept map for the Unified Services Theory (Figure 2), without claiming to have integrated the theories themselves.

Additions from the Service-Dominant Logic are the concepts of service, value co-creation and value proposition (though the latter concept is a component of the Unified Services Theory concept of business process, not shown here). Also, the distinction between operant and operand resources is added, e.g., a consumer providing his labor to the service process (i.e., co-production) would allow qualifying the consumer as an operant resource that is applied in the service (process). Also service exchange is a new element not covered by the Unified Services Theory. A further elaboration of the exchange nature of service is given in Sect. 2.5, where we introduce the Resource-Service-System Model. In general we can see that the extension with concepts from the Service-Dominant Logic allows widening the Unified Services Theory’s scope of service processes to service exchanges.


The Work System Meta-model [4] is an extension of the Work System Theory [1]. The Work System Theory defines a work system as a “system in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific products/services for specific internal and/or external customers” (p. 75, [1]). Services are defined as acts performed to produce outcomes for the benefit of others. The Work System Theory encompasses a descriptive framework called Work System Framework that can be used to describe and analyze work systems. Given that service systems are work systems and most work systems are service systems (except those work systems not directed at others), the Work System Framework can be used to describe service systems. While the Work System Framework is intended to provide summary-level descriptions of work systems, the Work System Meta-model expresses a more detailed operational view on work systems. In the remainder we will focus our discussion on concepts that might provide for interesting new additions to our current concept base (as in Figure 3).

Integrated concept map of the Unified Services Theory and the Service-Dominant Logic

Figure 3. Integrated concept map of the Unified Services Theory and the Service-Dominant Logic.


The main concepts of interest of the Work system meta-model are shown in Figure 4. A service system is a work system in which work is performed for the benefit of internal or external customers to the enterprise that offers the service. The benefits for an internal customer are other than for performing work activities within the service system itself. The service system contains service system activities that use resources and produce products/services. Resources can be technological entities, informational entities, (human) participants or other resources. The term product/service refers to a bundle of tangible and/or intangible acts and outcomes that may be more goods-like or more services-like. Note that Work System Theory recognizes the traditional distinction between goods and services but does not consider it important to understand service systems. Service system activities are performed by actor roles which can be performed by automated agents (which is a technological entity and a totally automated service system on its own right), non-customer participants (e.g., an employee of the enterprise) or customer participants (i.e., in case of co-production). Products/services may be used as resources for other activities within the same service system, however, at least one product/service produced by an activity of the service system contributes to a product/service to the customer, meaning physical things, information, acts and/or outcomes used or received by a customer work system in which they facilitate the creation of value for the customer.

Concept map of Work System Meta-model - simplified

Figure 4. Concept map of Work System Meta-model (simplified).


Comparing the Work System Meta-model with the Unified Services theory, we see that the distinction between provider service system and customer work system is similar to that of production process and consumption process in the Unified Services Theory. Though not shown in Figure 4, the Work System Meta-model includes the concept of (business) process when two or more service system activities “are sufficiently interrelated and sequential enough to be considered a process” [4]. Hence, the production and consumption process are part of the provider, respectively customer work systems and contain themselves work system activities. A work system perspective, thus, allows describing Unified Services Theory processes in more detail, for instance by showing that the outputs of production process activities might be used as inputs for other activities within the same or different production process (belonging to the same provider work system), and, thus, not all outputs are directed at internal or external customers. Likewise, it can also show the resources of different kinds that are used as inputs in individual production process activities, whereas the Unified Services Theory focuses on different kinds of consumer inputs into the overall service process.


The Work System Meta-model is also interesting as it can help bridging the Unified Services Theory and the Service-Dominant Logic. The service brought about by the provider service system does not directly create value for the customer, but “facilitates” value creation [7], which is done in the customer work system. The product/service for customer is, thus, similar to the output of production processes that is selected for consumption processes in which value is extracted to satisfy consumer needs. Although the customer always has certain responsibilities, customer participation in service system activities (in the sense of co-production) is optional, so the absence of a distinction between service systems (or service production processes as in the Unified Services Theory) and “non-service” systems (or non-service production processes as in the Unified Services Theory) is similar to the Service-Dominant Logic where all economic activity is service (i.e., Foundational Premise FP5). Also, the definition of service is very similar to that of the Service Dominant Logic.

An apparent difference with the Service-Dominant Logic is the view of value co-creation which is optional in the Work System Meta-model but strictly required for service in the Service-Dominant Logic. The difference is actually more a difference in definition as the value creation in the customer work system based on the products/services of the provider service system is what resource integrators (FP9) do and what qualifies as value co-creation in the Service-Dominant Logic. The Work System Meta-model employs a more restrictive notion of value co-creation as customer work system activities that coincide in time and location with provider service system activities, implying that value co-creation is a more narrow form of co-production. More important is that the service system produces a “service as a process” (as in the Service-Dominant Logic), which facilitates value creation by customers/consumers (as in the Unified Services Theory).

The concept map in Figure 5 shows how the Work System Meta-model can be linked to both the Unified Services Theory and the Service-Dominant Logic. The product/service for customer is equated with the output that the consumer selects for the consumption process in the Unified Services Theory. Hence, the value for customer created by the customer work system is the value that is extracted in the consumption process performed by the consumer. The link with the Service-Dominant Logic is that service is performed by the service system.

Concept map of the Unified Services Theory, Service-Dominant Logic, and the Work System Meta-model

Figure 5. Concept map of the Unified Services Theory, Service-Dominant Logic, and the Work System Meta-model.


The Resource-Service-System model [15, 14] interprets the Resource-Event-Agent (REA) Model of economic exchange [5] according to the Service-Dominant Logic. In REA, economic exchange results from the economic reciprocal actions (called economic events) of independent entities (called economic agents) that provide each other the resources that they control (called economic resources).


Rooted in Accounting, REA employs the traditional economic classification of products as goods and services, hence, services are a type of resource exchanged between economic agents. This means that a service resource (e.g., a consulting service) and the event that transfers this resource from a providing agent to a receiving agent (e.g., the contracting and executing of the consulting service) are explicitly distinguished, whereas such distinction is not recognized in the Service-Dominant Logic (i.e., the consulting process is the service).

The Resource-Service-System model, therefore, replaces the REA notion of economic resource by the Service-Dominant Logic notion of operant/operand resource (see the concept map in Figure 6), the REA notion of economic event by the Service-Dominant Logic notion of service (as operant resources acting upon operand resources (e.g., as service target) or with operand resources (e.g., as tools or appliances)), and the REA notion of economic agent by that of service system entity. The latter concept is inspired by systems thinking in Service Science [12], where service systems are seen as supra-systems composed of sub-systems (i.e., service system entities) that improve their state (and, hence, the state of the supra-system) through service exchange.

As dynamic configurations of resources, service system entities possess the means to engage in service exchanges with other service system entities. Based on the REA axiom of economic reciprocity in economic exchange, also described as the duality of economic events, the Resource-Service-System model posits that service exchange is the reification of the dual relationship between economic reciprocal events as a series of actions and interactions undertaken by service system entities. Figure 6 shows that a service exchange is composed of service system interactions which are described by an interaction episode [11]. Such an interaction episode represents a series of activities, separately or jointly performed by the service system entities, as they occur in reality and, thus, lead to a certain outcome or interaction episode type. The purpose of service exchange is mutually beneficial value co-creation, meaning that service system entities engaging in service exchange employ their resources to integrate them with the exchange partner’s resources in order to jointly create value for all parties. Whereas mutually beneficial value co-creation is the intended favorable outcome of service exchange, the model recognizes other possible (and unfavorable) outcomes in line with the ISPAR model of service interaction outcomes [11].

Concept map of the Resource-Service-System Model

Figure 6. Concept map of the Resource-Service-System Model.


The Resource-Service-System Model fully adheres to the service-dominant economic world view put forward by the Service-Dominant Logic. Therefore, both descriptive theories are very similar and concepts like operant/operand resource and service are shared. Further, while the Service-Dominant Logic does not employ the term service system, it is clear that the actor concept is the same as the service system entity concept in the Resource-Service-System Model. The integrated concept map of Fig. 2.7, therefore, replaces the actor concept by the service system entity concept. Nevertheless, adding the Resource-Service-System Model further enriches the conceptual model of service that we gradually built throughout this section. First, the Resource-Service-System Model stresses more than the Service-Dominant Logic does that in an economic context, service is exchanged for service through interactions between service system entities. The kernel concept of the model is service exchange, not service. As a corollary, while the Service-Dominant Logic focuses on value co-creation as the creation of value by two actors for one of them, the Resource-Service-System Model clarifies that the purpose of service exchange is mutually beneficial value co-creation, i.e., value is created jointly for both service beneficiaries. Second, the Resource-Service-System Model recognizes (like the work system perspective described in [4] does) that this intended outcome might differ from the actual outcome of the interactions between service system entities.


The detailing of service exchange in terms of interactions between service system entities, in the form of joint and/or separate activities, provides for bridges with the two theories that focus more on the production/operational side of service processes and systems. Clearly, a service system activity as in the Work System Meta-model is an activity as defined by the Resource-Service-System Model, however, this is also true for an activity in the customer work system (coinciding or not with a provide service system activity). The concept of interaction episode is defined similarly to the concept of process in the Unified Services Theory, though it is used to represent the actual conduct of the activities in a single instance of service execution and should, therefore, be distinguished from a process “model”. The service system concept of the Work System Meta-model is different from the service system entity in the Resource-Service-System model as a service system entity (or actor in the Service-Dominant Logic; hence, producer/consumer in the Unified Services Theory) needs a work system (containing production processes) to perform a service.

A service system entity can itself be a resource in a “larger” work system. This is consistent with the systemic view of the Resource-Service-System Model (i.e. a service system entity can be used as an operant resource that acts in a service that is exchanged by the supra-entity controlling the entity), but also covers scenarios like consumers that are used as input in service processes according to the Unified Services Theory and fully automated service systems that perform actor roles in activities of a higher-level service system as made possibly by the Work System Meta-model. The operational details of the Work System Meta-model surpass that of the Resource-Service-System model, but on the other hand service exchange as a concept is missing, which makes the integration valuable as it allows creating a more complete concept base for identifying the elements that compose a service system conceptualization for designing the intended white-box service description language.


At the end of this chapter we wish to stress that the concept map shown in Figure 7 was obtained by gradually integrating the concept maps of the selected theories. Where possible, concepts from different theories with identical or very similar definitions were united. This way also relationships that cross theoretical boundaries could be established. The map shown in Figure 7 is, however, not a conceptual model of an integrated descriptive theory of service due to some fundamental differences in view on the nature of service and value creation. Therefore, multiple interpretations of service and value creation coexist.

Integrated concept map of four theories of service

Figure 7. Integrated concept map of four theories of service.

All four theories consider service as an “occurrent” or “perdurant” rather than a “continuant” or “endurant”, meaning something that happens rather than something that exists. While the definition of service in the ServiceDominant Logic, the Work System Meta-model, and the Resource-Service-System Model is (almost) identical, i.e., service is defined as a process in which something is done that benefits someone else, the Unified Services Theory, which does not directly define the concept of service, recognizes the existence of non-service processes. But as those non-service processes still produce outputs that consumers turn into benefits, the other three theories would argue that service was brought about.

The real difference in view on service depends on how service is “produced”. The Unified Services Theory is clearly the most restrictive as service processes need individual consumer inputs, which, given the many kinds in which those inputs can exist, is still much broader than requiring services to be co-produced. Co-production is recognized by the Work System Meta-model as customers participating as actors in the provider’s service system activities, however, it is optional. There can be service without co-production, even without individual customer inputs that are made available to the provider’s service system.

All four theories agree that the determination of value is the consumer/customer’s business. For the Service-Dominant Logic and the Resource-Service-System model, this value capture by the service beneficiary is co-creation of value. For the Work System Meta-model, this value capture, by the customer work system (or as in the Unified Services Theory, consumer’s consumption process) is not co-creation unless activities in the customer work system coincide with activities in the provider service system. So there is a fundamental difference in the definition of value co-creation between on the one hand the Work System Meta-model and on the other hand the Service-Dominant Logic and the Resource-Service-System model. Despite this different conceptualization of value co-creation, the notion of service is almost the same in these three theories.

The Resource-Service-System model adheres to the same service-dominant economic worldview as promoted by the Service-Dominant Logic and, hence, does not differ from that theory. It does stress, more than the Service-Dominant Logic does, the praxeology of service. Economic actors exchange service for their mutual benefit, hence, the exchange of service for service is a mutually beneficial value co-creation phenomenon. Further, it also recognizes, like the Work System Meta-model does, that service is an outcome which is not always achieved, even when intended.

Despite these differences, we believe that the end result of our analysis and modeling exercise (Figure 7), is a rich, multi-perspective concept base for designing a service system model that provides a conceptual foundation for the LSS-USDL language. Each of the reviewed theories has the ability to add concepts that are potentially relevant to a white-box service system conceptualization. The Service-Dominant Logic emphasizes that service is a process of operant resources acting upon operand resources. The Unified Services Theory sees the service production process as different from the value extraction process. The Work System Meta-model adds operational details to service production, involving different kinds of operant and operand resources, and puts forward the notion of service system. Finally, the Resource-Service-System Model adds the service exchange aspect and stresses that, in an economic context, value co-creation should be mutually beneficial. From a white-box perspective, this mutually beneficial value co-creation results from a series of activities, separately or jointly performed by service system entities, where these activities are part of the provider service system and/or customer work system, and can be organized as processes. Processes, activities, and resources used as inputs or produced as outputs, are all relevant concepts for a white-box service system conceptualization.


  1. Steven Alter. Work system theory: Overview of core concepts, extensions, and challenges for the future. Journal of the Association for Information Systems, 14(2), 2013.
  2. Steven Alter. Disentangling service: Using a work system perspective to reconcile different but overlapping portrayals of service and service systems. Working Paper, 2014.
  3. Steven Alter. Viewing services as service systems: basic premises of an operational model for service innovation, engineering, and management. Working Paper, 2014.
  4. Steven Alter. Work system perspective on service, service systems, it services, and service science. Business Analytics and Information Systems, 2014.
  5. Guido Geerts and William McCarthy. An ontological analysis of the economic primitives of the extended rea enterprise information architecture. International Journal of Accounting Information Systems, 3(1):1– 16, 2002.
  6. Shirley Gregor. The nature of theory in information systems. MIS Q., 30(3):611–642, September 2006.
  7. Christian Grönroos. Value co-creation in service logic: a critical analysis. Marketing Theory, pages 279–301, 2011.
  8. Alan Hevner, Salvatore March, Jinsoo Park, and Sudha Ram. Design science in information systems research. MIS Q., 28(1):75–105, March 2004.
  9. IfM and IBM. Succeeding through Service Innovation: A Service Perspective for Education, Research, Business and Government. University of Cambridge Institute for Manufacturing, Cambridge, United Kingdom, 2008.
  10. Robert Lusch and Stephen Vargo. Service-dominant logic: reactions, reflections and refinements. Marketing Theory, 6:281–288, 2006.
  11. Paul Maglio, Stephen Vargo, Nathan Caswell, and Jim Spohrer. The service system is the basic abstraction of service science. Information Systems and e-business Management, 7(4):395–406, 2009.
  12. Manuel Mora, Mahesh Raisinghani, Rory O’Connor, and Ovsei Gelman. Toward an integrated conceptualization of the service and service system concepts: A systems approach. IJISSS, 1(2):36–57, 2009.
  13. Arun Parasuraman, Valarie Zeithaml, and Leonard Berry. A Conceptual Model of Service Quality and Its Implications for Future Research. The Journal of Marketing, 49(4):41–50, 1985.
  14. Geert Poels. A conceptual model of service exchange in service-dominant logic. In Jean-Henry Morin, Jolita Ralyt´e, and Mehdi Snene, editors, Exploring Services Science, volume 53 of Lecture Notes in Business Information Processing, pages 224–238. Springer, 2010.
  15. Geert Poels. The resource-service-system model for service science. In Juan Trujillo, Gillian Dobbie, Hannu Kangassalo, Sven Hartmann, Markus Kirchberg, Matti Rossi, Iris Reinhartz-Berger, Esteban Zimnyi, and Flavius Frasincar, editors, Advances in Conceptual Modeling Applications and Challenges, volume 6413 of Lecture Notes in Computer Science, pages 117–126. Springer, 2010.
  16. Scott Sampson. Customer-supplier duality and bidirectional supply chains in service organizations. International Journal of Service Industry Management, 11:348–364, 2000.
  17. Scott Sampson. A unified services theory paradigm for service science, June 2007.
  18. Scott Sampson and Craig Froehle. Foundations and implications of a proposed unified services theory. Production and Operations Management, 15(2):329–343, 2006.
  19. Jim Spohrer, Paul Maglio, John Bailey, and Daniel Gruhl. Steps toward a science of service systems. Computer, 40(1):71–77, January 2007.
  20. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing. Journal of Marketing, 68(1):1–17, 2004.
  21. Stephen Vargo and Robert Lusch. The four service marketing myths: Remnants of a goods-based, manufacturing model. Journal of Service Research, 6(4):324–335, 2004.
  22. Stephen Vargo and Robert Lusch. From goods to service(s): Divergences and convergences of logics. Industrial Marketing Management, 37(3):254– 259, May 2008.
  23. Stephen Vargo and Robert Lusch. Service-dominant logic: continuing the evolution. Journal of the Academy of Marketing Science, 36(1):1–10, 2008.
  24. Stephen Vargo, Paul Maglio, and Melissa Akaka. On value and value co-creation: A service systems and service logic perspective. European Management Journal, 26(3):145 – 152, 2008.
  1. 1 Major Theories
  2. 2 Service-Dominant Logic
  3. 2.1 A New Service Definition
  4. 2.2 Foundational Premises
  5. 2.3 Service-Dominant Logic Concepts
  6. 3 Unified Services Theory
  7. 3.1 Defining the Service Process
  8. 3.2 Unified Services Theory Concepts
  9. 3.3 Service Process versus Service as Process
  10. 3.4 From Service Process to Service Exchange
  11. 4 Work System Meta-model
  12. 4.1 Work System Meta-model Concepts
  13. 4.2 From Service Process to Service System
  14. 4.3 Reconciling Value Co-creation Definitions
  15. 5 Resource-Service-System Model
  16. 5.1 Resource-Service-System Model Concepts
  17. 5.2 Mutually Beneficial Value Co-creation
  18. 5.3 Service System to Service Exchange between Service System Entities
  19. 6 Summary and Conclusions