Service Concepts 101

Topic:  Unified Business Service Model

Date:    November 2012

Author: Lawrence Wilkes

Abstract:  This research note provides a concept model that explores the basic concepts of Service and Service-Orientation taking into account a broad perspective including Business Service, IT Services, Software Services, Cloud Services and even Human Services

Service Concepts

The use of the term ‘Service’ is somewhat overloaded. Everyone will have heard or used the terms Business Services, IT Services, Software Services, and now Cloud Services, and yet often there is much confusion and misunderstanding in their use.

As my colleague David Sprott suggested in a CBDI Journal Report, “Everything is a Service” [1]. In that report David suggested that the idea that “everything is a service” could be developed to clarify the taxonomy for Cloud Services and Services in the form of a Unified Service Model that would deliver convergence of business and IT perspectives.

In this research note, I provide a concept model that explores the basic concepts of Service and Service-Orientation taking into account this broad perspective including Business Service, IT Services, Software Services, Cloud Services and even Human Services.

What is a Service?

Readers will be familiar with the basic concept of a Service.  That is, where someone or something provides a Service to another.

The notion that someone or something offers a Service to another introduces the concept of the Service Provider and Service Consumer as illustrated in Figure 1.


Figure 1 Service Consumers and Providers

A Service Provider is as its name suggests is someone or something that provides a Service.

And the Service Consumer is someone or something that consumes or uses the Service.

Real World Example: A logistics company provides a Goods Delivery Service. This is used by a manufacturer to ship goods to its clients.

The logistics company is the Service Provider.  The manufacturer is the Service Consumer.


The reason a Service Provider is able to provide the Service is because they possess the Capability required to do so.

A Capability is the power or ability to perform some function.

We may think of a person, an organization or something (a machine, or some technology) as having the Capability to perform some function.

In turn the Service Provider may offer their Capability to others, in the form of a Service.

Meanwhile, a Service Consumer is someone or something that requires the Capability.

Hence we may understand a Service as a Capability offered by a Service Provider to a Service Consumer

Real World Example: A logistics company has the Capability to deliver goods.  Therefore it is able to offer a Goods Delivery Service to others.


Figure 2 Service and Capability

Types of Service

In the real world example used so far, a logistics company provides a Goods Delivery Service to a manufacturer.

This may be referred to as a Business Service, as it reflects the nature of the activity - where one business is providing its services to another. It is also normally offered on a commercial basis, and may be considered as a Business Service because business is being transacted through its use.

We can think of Business Service as a particular type of Service.

Other types of Service commonly used in an IT context are,

  • IT Service, where the IT department (or 3rd party) provide a service to the business
  • Software Service, where a unit of software provides a service to another software unit
  • Cloud Service, where a Software Service is provided over a network and conforms to cloud computing principles

We can even consider a Human Service where one person provides services to another and relies upon human resources to provide the required Capability.

Regardless of the type of Service, the concepts discussed so far still hold true.

Whether it is a Business Service, an IT Service or a Software Service, Cloud Service, or a Human Service, they still all provide a Capability, and are all provided by a Service Provider and used by a Service Consumer.


Figure 3 - Types of Service showing different forms of Service Provider and Consumer

Service Type Relationships

These different types of Service are often related.

For example as Figure 4 shows, a Business Service, especially one as complicated as logistics, is likely to be an aggregation of many finer-grained capabilities. It may also be an aggregation of other Services.

Each of the finer-grained capabilities may itself be provided as a Service.  In the case of a Business Service, those capabilities are often realized by a combination of people, process and technology.

Hence, the Business Service is typically supported by a combination of IT Service, Software Service, Cloud Service and Human Service.

Real Word Example: The Goods Delivery Business Service offered by the logistics company requires a Capability to Schedule Shipments. This is provided as a Schedule Shipments Software Service that can be used by the logistics company or its customers.

The Schedule Shipments Software Service is itself part of the Scheduling Management System, a Capability which is provided to the business by the IT department as an IT Service.

What makes a Service a Business Service?

A Service offered by an enterprise to its customers or other participants in its ecosystem (suppliers, partners) can be considered a Business Service.  Note that customer could be considered to include internal as well as external customers, for example where one line of business is offering services to another.

There is no specific property of a Service that makes it a Business Service, only context. That a Service is recognized as a Product as shown in Figure 4 may be one way to provide that context. Where a Service is recognized as a Product and is offered to Service Consumers on a commercial basis or to support commercial activity, then that may be taken as a clear indication that it is a Business Service.

In some cases, a Software Service may itself be offered on a commercial basis as a Business Service. For some software vendors, making their software available as a Service and charging others to use it is their business. This is often true in the case of a Cloud Service.

Similarly, a Human Service may also be offered as a Business Service. This may often be referred to as a Professional Service.

Where an IT Service is provided on a commercial basis, typically by 3rd parties to end-user organizations, then this too can be offered as Business Service.

Often these relationships are formed on a many-to-many basis.  That is, a Business Service may be supported by many Software Services for example, whilst each Software Service supports many Business Services.


Figure 4 Service Type Relationships

However, we should consider whether it is useful to constrain the definition of Business Service to commercial activity alone. Though a Business Service may be offered by an enterprise to others there is not necessarily always a direct commercial activity involved.

Is Customer Support a standalone Business Service for example? Or is it only providing one of many Capabilities that are aggregated into a more obvious Business Service.

Equally, are the Services provided to other participants in the ecosystem besides customers – the partners and suppliers – also Business Services? Even though they may not be a direct commercial activity involved?

And what about Services provided by government agencies to citizens for example? Are they Business Services? Is filing a tax return a ‘commercial’ activity? Or filling in a census form online?

Hence it may be preferable not to focus just on commercial activity but on business outcomes. As long as a Service provides a meaningful business capability with a clearly defined business outcome then it is valid Business Service.

Service Type Definitions

At this point we can present some definitions of the various Service Types. As well as definitions, Table 2 also explores the potential relationships between the various Service Types




Business Service

IT Service

Software Service

Cloud Service

Human Service


A capability offered by a Service Provider to a Service Consumer


Business Service

A service provided by an enterprise to its ecosystem of customers, suppliers or partners that provides one or more capabilities that facilitate a discrete business outcome according to a contract






IT Service

  • A Service provided by the IT department to the business
  • A Service provided to one or more Customers by an IT Service Provider (ITIL)
  • Offered as
  • Supports




Software Service

  • A Service provided by one software unit to another via a Service API (Application Programming Interface)
  • The automated elements of a business service (Information System Service - TOGAF)
  • Offered as
  • Supports
  • Automates
  • Offered as
  • Supports
  • Automates
  • Offered as
  • Supports

Cloud Service

A Service provided over a network where the provision of the Service conforms to Cloud Computing principles

  • Offered as
  • Supports
  • Offered as
  • Supports
  • Automates



Human Service

  • A Services that relies upon human resources to provide the required capability
  • A person-to-person or Professional Service.
  • Offered as
  • Supports
  • Offered as
  • Supports

Only indirectly

Only indirectly*


Table 1 – Service Type Definitions

* See Amazon Mechanical Turk [2]

Service and Capability Delivery

The Capability provided by a Service is accessed via an Interface.

A Service Consumer interacts with the Capability they require via the Interface.

A Capability is delivered, or implemented, by an aggregation of one or more Resources.

The Resources necessary to provide a Business Service for example is typically a combination of Human, Physical and Technology Resources. These are all different types of Resource.

We can separate these into a ‘what’ view of a Service and a ‘how’ view.

The ‘what’ view focuses on what the Service does and what Capability it provides.

Whilst the ‘how’ view focuses on how the Service and the Capability is implemented.

The Service Consumer need only be concerned with the ‘what’ view. The Service Consumer should not need to know how the Capability is implemented or what Resource is used. They only need to know what Capability is provided and what they need to do in order to interact with the Capability via the Interface.

Whereas the Service Provider must be concerned with both the ‘what’ and the how’, as they have to provide the Resource the delivers the Capability.

See Service Specification Reference Framework for further discussion on this

That the Service Consumer need only be concerned with the ‘what’ view is key to the concept of Cloud Services. As the Service Consumer does not need to know how the Capability is implemented or what Resource is used, then neither do they need to know where those Resources are located or how they are organized.  All they need to know is the address of the Interface by which they interact with the Capability.

Real World Example:  To provide the Goods Delivery Business Service, the logistics company will need a variety of different resources to deliver the capabilities required.

To transport the goods for example, it will require Human and Physical Resources such as drivers and trucks, along with Technology Resources such as mapping, routing, and tracking systems to optimize delivery.


Figure 5 – Service and Capability Delivery


Let’s look a little closer at the concepts of an Interface. As stated, a Capability provided by a Service is accessed via an Interface. However, there are many types of Interface.

A Software Service provides a Service API (Application Programmable Interface) that allows programmatic (automated) access by other software units.

A Business Service may have no Interface of its own as such, but is accessed via the Interfaces of the Human and Software Services that support it.

The Capabilities of a Business Service provided by a Human Service could be accessed via a Human Interface. I.e. a person is the Interface – whether physically local or remote. For example, a call centre operator.

Where the Capabilities of a Business Service are provided by a Software Service, then this could be accessed either by

  • Human operators via a User Interface provided by an Information System that uses the Software Service. Note, this could be as simple as some ‘widget’ running in a browser.
  • Or via a Service API  to allow the Software Service element of the Business Service to used by programmatically by the Service Consumer.

Similarly, an IT Service may have no Interface of its own as such, but is accessed via the Interfaces of the Human and Software Services that support it.

A Cloud Service would also be accessed via a Service API provided by the Software Service.  Though some Capabilities of a Cloud Service may also be accessible via a User Interface.


Figure 6 – Interfaces

Real World Example: A logistics company provides a Goods Delivery Service. Customers can request deliveries to be made via a Delivery Scheduling Service.  Because of the wide variety of customer types the logistics company supports, from large corporations to individuals, it provides access to the Delivery Scheduling Service via a number of different Interfaces.

There is a Call Centre – a Human Interface – that customers can call. There is a web site – a User Interface – that customers can use. The web site is part of the same Information System that the Call Centre operators use to capture delivery details.

Whilst its large corporate customers can use a Web Service – a Service API – to integrate Delivery Scheduling into their own ERP systems. The logistics company now plan to use this same Service API to provide a mobile app than can be used by all their customers. The Service API is also used by the logistics company’s own Information System that is accessed via the web site.

In a well architected system, all of these Interfaces should resolve back to the same underlying resources that manage delivery scheduling.

Service Implementation

As stated earlier, the Capability provided by a Service is delivered or implemented by a Resource. Let’s now take a closer look at the Service Implementation.

Automation Unit

A Software Service is implemented by an Automation Unit.  We use the term Automation Unit to avoid any misunderstanding that may arise from the use of terms such as Software Component as this may introduce unwanted connotations that may be normally associated with that term.

It is this Automation Unit that is delivered by a Technology Resource.

The Automation Unit is an aggregation of one or more Automated Procedures, or Automated Elements. Again, we do not want to imply the form of the Automated Procedure by using a term that may imply it – for example Script or Program. They are many ways in which the rules of an Automated Procedure may be codified.

The Automated Procedure may automate a Workflow, or access an Information Source.


Figure 7 – Service Implementation

Human Services

A Human Service is implemented by some Manual Activity. This may follow some Workflow.

It may also access an Information Source. However, where access to the Information Source is via some Automated Procedure, then the Manual Activity must use the Software Service (via its User Interface).

Where it is a manual activity, such as accessing a printed catalog or printed records, then it is acceptable to show that the Manual Activity is accessing an Information Source directly.

Service Contracts

In order to use a Service, a Service Consumer must usually accept a Service Contract offered by the Service Provider. In straightforward scenarios the Service Contract may be in the form of terms and conditions that usually must be accepted.

A Service is the subject of a Service Contract. This defines the obligations that the Service Consumer and Service Provider must comply with.


Figure 8 – Service Contracts

The set of Service Contracts will normally consist of three main types.

  • A Service Level Agreement that defines the Quality of Service (QoS) that can be expected of the Service. This should state obligations on both Service Provider and Service Consumer in terms of the performance, availability and security provided by the Service. While for a Business Service it may extend to warranty and support terms.
  • A Service Specification that identifies the Capabilities provided by the Service, and defines the behavior of the Service as seen through the use of its Interface. This will be used by the Service Consumer to discover Services that provide the required Capabilities, and then to understand how they are used.
  • A Commercial Agreement that defines the commercial terms for using the Service, such as cost of use, period/term of use, and any penalty clauses.

These Service Contract types apply to any type of Service. That is, they equally apply to a Business Service, a Software Service, a Cloud Service, an IT Service or a Human Service.

In some cases, the Service Contract (or clauses of) may be specific to a Service Provider and Consumer pair.  In other cases, the Service Contract (or clauses of) may apply equally to all Service Consumers. For example the general Terms and Conditions for using a Cloud Service.


In the context of this paper, understanding the different Service Types as Business, Software, IT, Human and Cloud is probably sufficient.

However, if we were to ‘drill down’ into any of those types in understand them in greater detail we are likely to come across another level of Service Types.

For example, in the context of SOA (Service Oriented Architecture), the concept of a Software Service is likely to be classified into further Service Types such as Information Service, Core Business Service, Data Service, Process Service, Utility Service and so on. These Service Types classifications or variations on them are frequently found in many reference models for SOA, such as our own CBDI-SAE Reference Framework for SOA [3]. The classification is typically based upon the nature of the Capability they provide. 

In the context of IT Services, then besides IT Service, ITIL also defines several Service Types including Core Service, Customer-Facing Service, Infrastructure Service, Enabling Service, Enhancing Service, and Supporting Service [4].

Is an ITIL Core Service the same as a Business Service? Its definition certainly appears to overlap with the definitions in Table 1 – “A service that delivers the basic outcomes desired by one or more customers”. However, the context is different. This is a Core ITIL Service, not a Core Business Service.

Is a CBDI-SAE Core Business Service the same as a Business Service, or the same as an ITIL Core Service?

CBDI-SAE states that “a Core Business Service provides a ‘360 degree’ view of a business resource.” That doesn’t sound like the definition of a Business Service or an ITIL Core Service, and it isn’t meant to. In the context of CBDI-SAE it means something quite different.

However, it should be true that all of those different Service Types in ITIL, CBDI-SAE and elsewhere still conform to the basic concepts of Service as outlined in this paper.

It is the inappropriate use of similarly named concepts in the wrong context that is often the source of confusion and misunderstanding.

Business Service Types

The discussion earlier on the definition of Business Service illustrates that there is also a need to define a set of Business Service Types. It is beyond the scope of this paper to do so, but that discussion demonstrates that there may be useful delineation of Business Services Types along the lines of commercial and non-commercial activity for example.

Or to follow the ITIL example and classify Core Business and Supporting Business Service types.


Using Service concepts and Service Types correctly in context is vitally important.

Hence developing a universal taxonomy of service concepts as suggested by David Sprott would be most useful, along with a taxonomy of Service Types.

Hopefully readers will find this paper a useful starting point for that activity.


[1] Everything is a Service. CBDI Journal June 2012.

[2] Amazon Mechanical Turk

[3] CBDI-SAE Reference Framework for SOA.

[4] ITIL 2011 Glossary

Download the PDF Version below for an extended version of this research note with the above patterns documented using the standard "problem/solution" pattern template. (free registration required)


You must confirm your screen name on your profile in order to comment.

Please sign in if you wish to comment.