Businesses and public service organisations deliver value to their customers through services [1]. These services can be what is traditionally though of as services – transport services, health services, personal training services, etc. – but also includes ‘goods’, which are services in physical form. This is because the value of the service is in the use of the service [1]. Even when a person or a company thinks of themselves as just buying physical goods, they are also mindful of where it is delivered, when it is delivered, what is its warrantee and expected after sales service, and even how they will pay for it. All of these factors form part of the service and should not be discounted as mere “add-ons”.

This bundle of physical goods, activities and promises to perform which constitute a service need a system (a “service system”) behind it to enable it to be delivered. This is provided by the organisation through a combination of activities performed by the organisation itself, and by resources (i.e. services) provided by other organisations as inputs to the service system. Further, within the organisation itself, the service system which provides the service to the customer (usually called “operations”) is assisted by many internal services, which have their own suppliers. This chain of services and service systems is the value chain [2].

A typical service system therefore involves the customer, the goods and services, processes and activities, and resources – including participants, information and technology [3]. To assist in designing the service system, information technologists and business analysts develop architectural descriptions of the system from a business viewpoint. However, most current representations make a number of simplifications: that all parties see a single “corporate” view of the world; that all will follow the fixed choreography defined by the architects or business analysts; and that it is best to make the service parties follow a standardised workflow, rather than use their own experience. This is shown by the popularity of frameworks such as TOGAF [4] and Zachman [5], which are based on these assumptions.

In practice, these simplifications are not valid. There are even less valid when some of the resource providers are external suppliers. Different stakeholders will have different world views, motivations, beliefs and even different opinions on what constitutes the service system [6]. Different parties have significant motivation to depart from the script for their advantage. And even if everyone was aligned on motivation, beliefs and information, to fix the activities in specific workflows may not be the best outcome; particularly where the environment or the service to be produced is highly variable [7]. Because of these simplifications, current business architecture views assume, rather than model, the co-ordination necessary to get multiple stakeholders contributing their services to ensure the delivery of value proposition.

The purpose of this research is to identify the co-ordination requirements for multiple stakeholders, including the primary service provider and the customer, to deliver the service to create value. This research does not assume the consistency of worldviews or motivations of the stakeholders, nor will it assume parties will follow fixed scripts of activities. The research will focus on services with a high degree of automation or with a significant information service component, but will not assume that the automation or information service components are the most important elements of the service delivery.


Stages of investigation: from Understanding, to Prediction, to Control [8]

1. Lusch, R.F., Vargo, S.L. & Wessels, G. 2008, 'Toward a conceptual foundation for service science: Contributions from service-dominant logic', IBM Systems Journal, vol. 47, no. 1, pp. 5-14.
2. Porter, M.E. 1985, Competitive Advantage: Creating and Sustaining Superior Performance, The Free Press, New York.
3. Alter, S. 2008, 'Service system fundamentals: Work system, value chain, and life cycle', IBM Systems Journal, vol. 47, no. 1, pp. 71-86.
4. The Open Group 2009, TOGAF Version 9, in The Open Group (ed.).
5. Zachman, J.A. 1987, 'A framework for information systems architecture', IBM Systems Journal, vol. 26, no. 3.
6. Ulrich, W. 2003, 'Beyond methodology choice: critical systems thinking as critically systemic discourse', Journal of the Operational Research Society, vol. 54, pp. 325–342.
7. Hall, J.M. & Johnson, M.E. 2009, 'When should a process be art not science', Harvard Business Review.
8. Cable, D.M. 2007, Change to Strange: Create a Great Organization by Building a Strange Workforce, Wharton School Publishing, Upper Saddle River, New Jersey.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License