multi-cloud service delivery and end-to-end management

Multi-Cloud

Service Delivery &

End-to-End

Management

Reference Architecture

Worldwide Communications and

Media Industry

Version 1.1

15 Jan 2013

Multi-Cloud Service Delivery & End-to-End Management

Microsoft Communications and Media Industries 15 Jan 2013

Page 1

©2013 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and

views expressed in this document, including URL and other Internet Web site references, may change

without notice. You bear the risk of using it. Some examples are for illustration only and are fictitious.

No real association is intended or inferred.

This document describes how service providers and partners can implement the TM Forum SES

Management Solution design patterns on Microsoft cloud platforms going forward. Given this is an

industry standard work-in-progress; nothing is implied as to the degree to which these design patterns

actually are or will be implemented by Microsoft products and services.

This document does not provide you with any legal rights to any intellectual property in any Microsoft

product. You may copy and use this document for your internal, reference purposes.



Page 2

Table of Contents

Table of Figures ............................................................................................................................................. 3

Foreword ....................................................................................................................................................... 4

Executive Summary ....................................................................................................................................... 6

Introduction ................................................................................................................................................ 10

Software Enabled Services Management (SES) .......................................................................................... 14

Defining a Manageable Service ....................................................................................................... 14

Defining a Simple Management Interface ...................................................................................... 14

Service Lifecycle Management ....................................................................................................... 16

API Inventory Management ............................................................................................................ 16

Challenge of End-to-End Service Management .......................................................................................... 18

Cloud Computing Resource Management .................................................................................................. 20

Challenges of Virtualization ............................................................................................................ 21

Challenges of Multi-Cloud ............................................................................................................... 22

Cross-Industry and M2M Applicability ............................................................................................ 26

Cost of Excellence in Quality of Service ...................................................................................................... 28

Value of a Service Broker ............................................................................................................................ 30

The Telco SDP .................................................................................................................................. 31

The ICT Service Delivery Broker ...................................................................................................... 32

API Management ............................................................................................................................ 33

Implementing Multi-Cloud Service Management with Microsoft .............................................................. 38

APIs for Measuring Azure Performance by Application .................................................................. 40

Monitoring Pack for Windows Azure Applications ......................................................................... 40

Getting the Latest Monitoring Pack and Documentation ............................................................... 42

The Multi-Cloud Developer Experience Catalyst ........................................................................................ 44

Release History ........................................................................................................................................... 46

References .................................................................................................................................................. 47



Page 3

Table of Figures

Figure 1 – The Multi-Cloud Nature of Service Delivery ................................................................................ 6

Figure 2 – Managing Services in a Virtualized Multi-Cloud Environment..................................................... 7

Figure 3 – Four operations issues of multi-cloud ........................................................................................ 12

Figure 4 – Great User Experience, Great Operations Experience, Great Developer Experience ............... 13

Figure 5 – TM Forum SES Interfaces ........................................................................................................... 14

Figure 6 – Types of Service Interfaces ........................................................................................................ 15

Figure 7 – TM Forum SES LMM Management Phases (Draft)..................................................................... 16

Figure 8 – Programmable Web API Growth ................................................................................................ 17

Figure 9 – Complexity of managing syndicated services ............................................................................ 19

Figure 10 – Example content streaming to mobile device ......................................................................... 20

Figure 11 – Windows Azure virtualized resource layers. ............................................................................ 20

Figure 12 – Three Resource Layers ............................................................................................................. 21

Figure 13 – Role of an OSS .......................................................................................................................... 21

Figure 14 – Visualizing the service delivery path ........................................................................................ 22

Figure 15 – Visualizing service management .............................................................................................. 23

Figure 16 – Exposing B2B management services ........................................................................................ 23

Figure 17 – Visualizing B2B service management ....................................................................................... 24

Figure 18 – Another view of the SES Management Solution vision used in an ITU-T submission. ............. 25

Figure 19 – M2M Cross Industry Example of Multi-Cloud Service Delivery ............................................... 26

Figure 20 – Components of Service Quality ................................................................................................ 29

Figure 21 – Multi-Cloud Service Management ........................................................................................... 31

Figure 22 – Functional and Management APIs ........................................................................................... 34

Figure 23 – The Service Delivery Broker (SDB) as an API management system ......................................... 35

Figure 24 – The SDB in a Services Orientated developer governance role ................................................. 36

Figure 25 – SMI as a Value Added Service .................................................................................................. 38

Figure 26 – Flexible SMI deployment options............................................................................................. 39

Figure 27 – TM Forum Multi-Cloud Developer Experience Catalyst ........................................................... 44



Page 4

Foreword

Microsoft was a founding member of the TM Forum Service Delivery Framework (SDF) initiative

launched in 2007 with the aim to identify and specify the standards required to enable network

infrastructure providers, hosted service platform providers, application providers, service brokers or

service syndicators to efficiently work together to create and deliver coarse grained services from

multiple fine grain components and yet still be able to manage down to the fine grain service level.

Later, as work progressed, the TM Forum renamed the project to Software Enabled Services (SES)

Management.

Microsoft has contributed extensively to the effort since the beginning. One core contribution was a

concept taken from a Microsoft solution known as the Connected Services Framework or CSF. CSF

advocated the concept of a “Well-Enabled Service”; a service that exposed a separate interface designed

to perform management functions such as to report health and welfare. Today in the TM Forum, the

Well-Enabled Service manifests itself as a Software Enabled Service; a service that exposes both a

Functional Interface (FI) and one or more Simple Management Interfaces (SMI).

The Microsoft Reference Architecture for Multi-Cloud Service Delivery is complementary to the TM

Forum SES. Although the Microsoft reference architecture can be implemented without actually

implementing SES, the context for that architecture is best understood by understanding the TM Forum

Frameworx and Software Enabled Services Management relevance to end-to-end management in Multi-

Cloud Service Delivery. Accordingly, there are multiple references in this document to the TM Forum

Frameworx and Software Enabled Services Management. Only readers from TM Forum member

companies can download the referenced source documents from the TM Forum web site. Since the vast

majority of the intended audiences of this work are members of the TM Forum this should not be a

major issue.

With the rapid growth of cloud computing, the consumerization of IT, the trend towards services and

content created increasingly at the edge, the exponential growth of Web Services APIs, and increasingly

mobile endpoints the original goals of the SDF initiative have never been more relevant. Microsoft

customers, developers and partners will find that leveraging the concepts contained in the Microsoft

Reference Architecture for Multi-Cloud Service Delivery and End-to-End Management can accelerate

their Service Oriented Architecture implementations leveraging cloud, network, and enterprise

resources while delivering significantly better user experiences, better end-to-end operations

management capabilities, and greatly improved developer efficiencies.

Eric G. Troup

CTO, World-Wide Communications and Media Industries

Microsoft



Page 5

Industry Comments

“From a pure operations perspective, the goal is to ensure we are delivering an outstanding End-to-

End Customer Experience. As we move to virtualize resources in the core and mobilize on the edge,

this is becoming a dynamic, complex equation with many moving parts. This is true within a single

environment, let alone across an Eco-System of Cloud Environments that must not only understand

how to interact seamlessly to deliver service, but also what is required to understand the End-to-

End Service Path through the arrays of networks, compute infrastructure, and applications in order

to ensure an outstanding Customer Service Experience and act quickly if this is experience is sub-

par. This paper provides an excellent overview of the landscape and captures many of the salient

points for us to reflect upon in this journey to a new delivery and operational landscape.”

Mark Francis, VP AT&T

“Embracing service-orientation principles and TM Forum SES SMI, the Multi-Cloud Service Delivery

Reference Architecture is an excellent showcase that presents PT/SAPO Service Delivery Broker relevance in support of hybrid, multi-vendor and multi-platform cloud environments, where it is

crucial to guarantee services reliability, interoperability and end-to-end manageability”.

António Cruz, Programador PT Communicações, S.A.

"Although the industry does not yet fully appreciate the challenges and costs of operating in a

multi-cloud environment, minimizing integration and operating costs will be a critical success factor.

The emergence of an industry standard reference architecture to simplify multi-cloud service

management is a priority for the TM Forum and we congratulate Microsoft for their initiative in

producing this paper as a strong contribution to meeting industry needs."

Keith Willetts, Chairman TM Forum



Page 6

Executive Summary

Business and consumer services delivered in today’s digital economy are increasingly dependent upon

resources distributed across a diverse ecosystem of stakeholders. Content Owners, Communications

Service Providers (CSPs), Multiple System Operators (MSOs), Cloud Providers, Business and Consumer

Users and of course Developers are all interdependent. As evident in Figure 1, the processes of creating

content / services, service delivery and of managing the overall experience end-to-end in this multi-

service provider / multi-cloud environment has become challenging.

Service Providers today are dealing with four major trends:

A. Multiple devices from a variety of manufacturers.

B. Complex developer ecosystems

C. Expediential Growth of Service APIs

D. Reality of Multi-Cloud Service Delivery

To address these issues the TM Forum developed the

Software Enabled Services (SES)1 Management Solution. It

defines the concept of an SES Service that exposes both a

Functional Interface as well as an explicit interface for the

management of a service or a service composition.

The SES Management Solution is not particularly concerned with what the service does via the

Functional Interface but does expand upon the manageability aspects especially in these two areas:

1. The Simple Management Interface2 (SMI) defines a design pattern for an API that reveals how

to manage any given service from a Provisioning, Assurance and Usage/Charging perspective.

2. The Service Lifecycle Management (SLM) defines ITILv3 2011 aligned best practices and

requirements for establishing a role based software/services factory and a Lifecycle

Management Meta Data model.

There are two principal differences with cloud computing that make more difficult the problem of

managing resources associated with cloud services. One difference is the virtualization at the elastic

compute and elastic network layers as well as the sheer scale of that virtualization. The other difference

is that multiple clouds and multiple enterprise domains are increasingly involved in the delivery of cloud

services further complicating resource management.

1 The term “SDF” and “SES” will be used interchangeably in this paper. Early TM Forum documents used the term

“SDF” or Service Delivery Framework and later TM Forum documents use the newer “SES” term. When a drawing

is pulled from a TM Forum document the term SDF or SES may appear depending upon the date of those docs. No

attempt is made to refactor the terminology to the newer term.

2 Simple Management Interface was the term adopted with the launch of the TM Forum Digital Services Initiative

in December 2012. The term had progressed from “Simple Management Interface” to “SES Management

Interface”. “Simple Management Interface” will be term used going forward.

Figure 1 – The Multi-Cloud Nature of Service Delivery



Page 7

To address this problem, the Microsoft Multi-Cloud Service Delivery and End-to-End Management

Reference Architecture defines how what the TM Forum SES Management Solution calls Management

Support Systems (MSS) can coordinate the SMI aspects of an application or service with the associated

state, health and welfare of underlying cloud and network resources.

As illustrated in Figure 2 below, Management Support Systems can maintain the relationship between

an application instance and the specific virtualized resources supporting that instance. This enables

relevant telemetry from that service and associated underlying compute and network resource layers to

be relayed to an OSS and used to update a Service Model dashboard.

Furthermore, the SMI can be exposed as B2B Simple Management Interfaces to enable the management

of service mashups that span multiple service providers. Leveraging this capability enables complex

service ordering and provisioning as well as customer dashboards to accurately display the status of a

service including underlying component services not under the direct control of the local service

provider or customer.

An Information and Communications Technology (ICT) Service Delivery Broker can be extremely useful

to help manage service creation and delivery in this environment. The envisioned ICT SDB is somewhat

different from traditional telecom SDPs that will continue to play an important role. An ICT SDB is well-

suited to address the broader needs of all cloud stakeholders and is not specifically focused on telecom

service provider requirements per se.

Figure 2 – Managing Services in a Virtualized Multi-Cloud Environment



Page 8

The ICT Service Delivery Broker can provide a set of reusable core capabilities (services) to govern and

speed development processes as well as to support runtime operations. Some of the reusable services

such an SDB can provide include:

• common transports,

• bindings and protocol mediation,

• support for all needed message patterns,

• common tasks such as security & access control,

• event processing engine,

• routings,

• performance / traffic monitoring,

• mechanisms for real time visibility into performance and usage including Dashboards.

This use of an ICT SDB also enables the reference architecture to deliver three key value propositions:

1. A Great User Experience – Users are able to access the business application or see the content

in the manner they expect.

2. A Great Developer Experience – Developers are able to more quickly create applications in a

consistent manner that can be easily incorporated into SOA Service Compositions that are

readily manageable from a QoS and SLA viewpoint.

3. A Great Operations Experience – Operators are able to provide a great user experience because

they have the information necessary to measure what is going on, quickly assess root causes

and impacts, and react to problems in a proactive manner.

Microsoft cloud platforms provide the necessary features and APIs to enable developers to create

services and applications that expose Simple Management Interfaces as outlined by the TM Forum SES

Management Solution.

• On-Premise Cloud - Microsoft Windows Server with Hyper-V together with System Center

enable the creation and deployment of manageable mission critical business and consumer

applications.

• Off-Premise Cloud – Microsoft Windows Azure also provides the necessary APIs that can be

used to create and expose Simple Management Interfaces for any service hosted on Windows

Azure. In addition, there is a Monitoring Pack for Windows Azure Applications and a Monitoring

Pack for SQL Azure for System Center to help manage cloud and hybrid cloud hosted business

applications and consumer services end-to-end.

Links to information on how to actually use these capabilities are listed in the in section “Implementing

TM Forum SES Management with Microsoft”.

The TM Forum SES Management Solution documents are listed under “References”.



Page 9



Page 10

Introduction

The nature of service delivery is changing. For many years, communications service providers (CSP) and

cable operators (MSO) have approached service delivery with the assumption that the network was

fundamentally central to the delivery of services and that CSPs and MSOs would continue to largely

control service creation and delivery end-to-end. The complex nature of large multi-layered networks

composed of elements distributed over a wide geography required communications service providers to

develop highly specialized capabilities to deliver voice and then data services over those networks.

The operations and maintenance requirements of network resources and telecom services have, until

recently, remained very different than those of IT data center resources and their applications. The

network side of service delivery management gradually became organized around concepts like Service

Delivery Platforms3 designed to optimize service creation and real-time delivery processes. The service

provider’s IT infrastructures (BSS/OSS4) needed to run the business gradually became organized around

the TM Forum Frameworx5 reference enterprise architecture. The underlying IT software and compute

resource management processes became organized in accordance with the Information Technology

Infrastructure Library or ITIL6.

The concept of Service Oriented Architectures (SOA) has existed for many years. The TM Forum

Frameworx for instance, defines key business functions, logically groups them into proposed

applications, offers common data models, and suggests contracts between components. Keith Willetts,

Chairman of the TM Forum, states in his new book, Unzipping the Digital World; “Frameworx is built on

a services oriented design and uses standard, reusable, generic blocks that can be assembled in unique

ways to gain the advantages of standardization while still allowing customization and enabling

differentiation and competition at the service level”.7

However, implementing solutions based upon frameworks takes discipline. Often the cost of

implementing a framework based solution requires extensive cooperation between organizations

beyond the current boundaries of individual projects and their budgets. As a result, many IT projects,

including implementations of Business Support Systems and Operations Support Systems (BSS/OSS),

often took expedient shortcuts to get projects delivered on time and at budget. Ultimately, the CSPs

ended up with complex, inflexible, and often redundant BSS/OSS organized around silos of products or

groupings of technologies. These implementations loosely conformed to the TM Forum Frameworx and

curtained SOA concepts but they did not actually deliver the agility and cost effectiveness needed to

keep pace with an accelerating rate of change. A consequence of this is that the traditional telecom

3 Service Delivery Platforms (SDP): A platform that supports development, deployment, and runtime of services

within a particular domain. Typically provides governance and tooling in support service lifecycle management,

service deployment accelerators, marketplaces, and/or runtime management capabilities. 4 BSS/OSS: Business Support Systems / Operations Support Systems. 5 TM Forum Frameworx, see http://www.tmforum.org/TMForumFrameworx/1911/Home.html 6 Information Technology Infrastructure Library, see http://www.itil-officialsite.com/ 7 Unzipping the Digital World, Keith Willetts, page 267.



Page 11

operators as we know them may be “losing their voice”8 as the digital world rapidly expands into much

broader ecosystems of digital service providers and stakeholders.

Over the years, standards evolved that enabled telecom voice and data services to work seamlessly over

multiple service providers’ infrastructures. Originally, a mobile user was able to receive service only

when physically connected to their service provider’s network. Today, mobile users are scarcely aware

of the network they are actually connected to. Both the business issues of charging and billing as well as

the technical issues associated with roaming wireless voice and data services were successfully

addressed. The need for very fast negotiation and coordination between service providers resulted in

the evolution of special command and control networks, such as SS7/CC7 (Signaling System 7/Common

Channel Signaling 7) for voice and IMS (IP Multimedia Subsystem) for IP Voice and Data. Differences in

global standards were resolved. The CSPs developed very effective capabilities for Provisioning,

Assurance, and Charging/Billing of network infrastructures and associated services end-to-end. To

support both wholesale and retail operations involving multiple service providers, they also developed

the service provider to service provider B2B interfaces necessary to support provisioning, service

assurance, and charging/billing processes spanning two or more service providers.

While the introduction of web services began to break down some of the barriers between the IT and

network worlds, it is cloud computing that is completely disrupting the former status quo. The cloud

pulls together a number of disrupters accelerating the convergence of IT and Telecom. Some of these

key disrupters include:

1. Maturity of web services standards

2. The adoption of IP and SIP in telecom and cable networks

3. Growth of mobile devices routinely connected to 3G/4G/LTE or WiFi networks

4. Increasingly ubiquitous and higher speed broadband

5. Proliferation of cloud platforms for IaaS, PaaS, and SaaS

While SOA and virtualization has contributed to the transformation of monolithic “applications” into

“services” hosted on virtualized compute and network infrastructures, cloud computing creates the

reality that the majority of services available for composition and consumption are not all contained

within the boundaries of any one company or enterprise. First, applications began to be built following

standards, and then those applications began to be exposed as “coarse-grained” services. Later services

began to be further broken down into “fine grained” service components. With costs coming down and

more new entrants appearing, the industry is moving closer to the commodization of services.

As indicated in Figure 3 below, service providers today are dealing with four major trends:

A. Multiple devices from a variety of manufacturers: Service providers are faced with the reality

of having to support an array of mobile devices from different manufacturers, using several

different Operating Systems, having several different form factors, catering to the needs of

8 Unzipping the Digital World, Keith Willetts, Page 31.



Page 12

businesses and consumers. There are feature phones, smart phones, PCs/Slates/iPads, game

consoles, and TVs. Some are connected via dedicated facilities such as IPTV or DOCSIS. Others

are connected via WiFi or cellular broadband services such as 3G/4G or LTE. The

“Consumerization of IT” is often mentioned as a contributing factor.

B. Complex developer ecosystems: Applications are core to the generation of revenue for entire

value chains. Each mobile device platform comes with unique application development support

requirements. The backend platforms for hosted services also have unique application

development and runtime support requirements. Enterprise IT Professional developers have

certain requirements related to conformance with best practices and standards for technology

use, identity management, security, and privacy. Conversely, the growing community of 3rd

party developers empowered by the widespread availability of cloud computing platforms and

having different needs including requiring support for more lightweight standards (e.g., OAuth)

also must be catered to.

C. Expediential Growth of Service APIs: Cloud computing has contributed to expediential growth

in the number of published APIs and Service End Points. Efficient application development

requires effective mechanisms to create, catalog and publish, maintain, and consume these

APIs. The dependencies that are created within applications that rely on the incremental bits of

functionality must be understood.

D. Reality of Multi-Cloud Service Delivery: Virtually every service has other services upon which it

depends or creates dependencies has soon as it is consumed. It is very rare today to find 100%

of the resources living in a “walled garden”. This collection of services typically resides in

multiple different service domains and a service owner may not, in fact, be able to directly

control prerequisite services. Service delivery today requires multiple clouds and multiple

service domains to work together in harmony throughout the entire lifecycle of that service.

Figure 3 – Four operations issues of multi-cloud



Page 13

The Microsoft Reference Architecture for Multi-Cloud Service Delivery and End-to-End Management is

designed to help Service Providers address these challenges. Leveraging industry standards, the

reference architecture blends capabilities from Microsoft to help deliver three key value propositions:

1. A Great User Experience: The perceived real value associated with the user experience is

critical to gaining and maintaining users willing to pay for a service. Whatever the service or

content the user is consuming, that experience must meet certain expectations of the customer.

This is true for both business users and the consumers. The reference architecture provides

tools to measure performance against established standards and methodology to iterate

towards better user experiences.

2. A Great Developer Experience: The developer community must be provided the tools and

guidance needed to build the types of applications needed to deliver great experiences. In

many cases, the experience cannot just be a “best effort”. Each service must be buildable in an

efficient manner that facilitates combining into more complex service compositions. Major

integration efforts must become progressively less necessary at this level. Therefore,

developers need governance, documentation, tooling, and wizards to guide them in the

development of services that are much easier to manage individually and combine into service

compositions / mashups that are also manageable and end-to-end.

A Great Operations Experience: All of the stakeholders in the service delivery process need to

be able to manage their services even though they rely on components hosted by different

services providers in different clouds. The ability to readily manage services that span multiple

clouds and resource domains is critical to achieving revenue objectives. Service providers and

their partners need transparency and visibility across value chains in order to have the

confidence to leverage efficient multi-cloud ecosystems to deliver core value added services to

businesses and consumers.

Figure 4 – Great User Experience, Great Operations Experience, Great Developer Experience



Page 14

Software Enabled Services Management (SES)

The Software Enabled Services Management Solution is defined in detail in a series of documents from

the TM Forum. The list is available in the References section.

SES Management solution has two key elements:

The Simple Management Interface (SMI) is an API that reveals how to manage any given service. It

defines for developers a key design pattern for including management capabilities in a service as they

design and build it. It enables service providers to manage each service or composition of services in an

efficient manner.

The Service Lifecycle Management (SLM) defines best practices and requirements for establishing a role

based software/services factory and a Lifecycle Management Meta Data model. Aligned to ITILv3 2011

Service Lifecycle Management Governance, this architectural component aids in the management of

APIs through their lifecycle impacting both service creation and runtime processes.

Defining a Manageable Service

It is important to first understand what is meant in this reference architecture by a “Service” and

a “Software Enabled Service” or SES. Without getting into a long discussion about the definition

of a service, let us define the following terms:

Service - a value provided by performing one or more functions on behalf of the service

requester typically via an API.

Software Enabled Service9 - a service that explicitly provides both a Functional Interface part to

the API and one or more Simple Management Interface parts to the API. The implementation is

flexible. The SES API could be two separate

APIs; (e.g., one WSDL for the FI plus one or

more for SMI), or one API (e.g., one WSDL

for both the FI and SMI) with specific parts

for each purpose.

Defining a Simple

Management Interface

A Simple Management Interface is an API,

or a part of an API, that provides management

capabilities for a service. TM Forum TR139 defined

the SMI as “…the set of capabilities exposed by an SDF Service through which it can be

9 TMF 061 “Service Delivery Framework Reference Architecture” Figure 3 - Pattern of an SDF Service v1.2; page 14.

Figure 5 – TM Forum SES Interfaces



Page 15

Figure 6 – Types of Service Interfaces

managed.”10 TMF617 states “The SES Management Solution proposes a hook to allow

consistent access to the software components for OA&M tasks. This consistent access is

achieved by incorporating the … SES SMI in addition to the Functional Interface as part of

software component creation. ”11 The exact operations supported by an SMI are determined by

the functionality needed for the service itself. Some could leverage TM Forum TIP/MTOSI/IP

Sphere specifications however, these heavier options may not be appropriate for all service

types.

An SMI may be implemented as a part of the service itself or it may be implemented by an OSS

component that will provide a management capability on its behalf. The TM Forum SDF/SES

documentation uses the terms Management Support System (MSS) to refer to any BSS or OSS

that performs the SMI function on behalf of a service. Later in this paper we will discuss Service

Delivery Brokers (SDB). It is also possible for an SDB to emulate a Service’s Management

Interface; to expose a virtualized SMI making it available through a mediation component such

as a message broker, ESB or gateway. Through mediation, the SMI will then appear to its

consumers as if it was originally designed as part of the service enabler. This can be necessary

because it is not always possible to change the underlying service enablers or simply because an

SMI capability needs to be composed by assembling a composition of different services.

A building block service that is intended to be combined with other services to create a service

mashup or SOA “service composition”12 is depicted below. The service API exposes a Functional

Interface and one or more Simple Management Interfaces address the following concerns:

• A FI is used to construct service compositions.

• A Provisioning SMI enables

configuration and state

management. It is used to

define end-to-end

provisioning processes.

• An Assurance SMI exposes

the interface from which

to collect specified fault

and performance

events/data from which

QoS and SLA performance

can be derived.

• A Billing or Charging SMI

can expose usage / charging events that can

10 TM Forum TR139, “Service Delivery Framework Overview”, . 11 TMF 617, “Software Enabled Services Management Interface Information Agreement”, Page 14. 12 See (http://www.soaglossary.com/service_composition.php for discussion of this SOA term.



Page 16

be used for wholesale or retail billing purposes and settlement.

Service Lifecycle Management

In addition to the concept of a consistent design pattern for an SMI, the SES Management

Solution acknowledges the need for a consistent approach to service lifecycle management.

This includes representative definitions for the phases a service passes through from concept to

retirement as well as a Lifecycle Management Metadata (LMM) model. The LMM can hold all

the data about a service throughout its lifecycle.

The SES Service Lifecycle Management definition consists of three parts:

• Management Dependencies of the Service – Resources that are prerequisites for the

service to function.

• Management Phase of the Service – ITILv3 2011 aligned lifecycle phases.

• Additional information about the SMI of a SES – Placeholder for additional information

but otherwise undefined.

The most well-defined of these

three parts is the Management

Phases of the Service. Adjacent is an

extract from TMF61813 that shows

the following proposed phases (TM

Forum, 2010):

• Concept

• Design

• Deploy

• Operate

• Retire

API Inventory Management

Cloud computing enables many different

entities, from large businesses to individual

developers, to host and publish and ever

increasing number of APIs. The

proliferation of APIs creates requirements

for API inventory management control.

13 TMF618, “Software Enabled Services Lifecycle Management Metadata Information Agreement” Figure 5-4, Page

19.

Figure 7 – TM Forum SES LMM Management Phases (Draft)



Page 17

It has been recognized for several years that simply building Web Services APIs and making them

available are not sufficient from either a technical or business perspective. In a services

orientation world, the service needs to be

the focus, not the message. A systematic

approach is required to guide the creation of APIs according to a set of common guidelines. A

management system is required to perform common functions that can be consistently applied

across all APIs. These include:

• Service Versioning

• Service Policy

• Service Abstraction

• Service Routing and Transport

• Service Management

As will become apparent, the massive amount of data generated through the use of APIs

becomes a critical component to a much larger Business Analytics process. As the invocation of

web services becomes more and more critical to the business, telemetry about the API traffic,

management systems, and the underlying virtualized cloud infrastructures become major

sources of operational data that must be monitored in near real-time or real-time to meet the

needs of the business groups, developer communities, and operations management.

Figure 8 – Programmable Web API Growth



Page 18

Challenge of End-to-End Service Management

Service delivery today often requires two or more service providers working together efficiently. The

reality today is that no service provider owns all the services that make up total value being delivered to

a customer. There are several reasons for this. One important driver is associated with core

competencies and the economics of delivering services at scale. Different types of service providers

have unique capabilities they can deliver at such scale that it is not economically feasible to duplicate

and to maintain a similar capability locally on an ongoing basis. Customers, however, often want

solutions that require including at least one competency outside of the core competency of the primary

service provider. Meeting customer requirements can be achieved most economically by combining the

best services exposed by several different providers into new value added service chain.

As traditional revenues sources erode, Communication Service Providers are actively seeking to replace

traditional services with newer next generation network services combined with new cloud hosted

services. This converged delivery over networks of content enabled by custom applications is a common

theme. To drive this business, CSPs are recruiting developers to build applications that will leverage

telecom network capabilities via a Service Exposure Layer. These 3rd party applications can include a

service logic component, possibly hosted on a cloud infrastructure, accessed via a client application

marketed via the appropriate Application Store or via an HTML5 web browser user interface.

In many cases these applications invoke services hosted on other environments. The services may, in

turn, implement one or more calls to other services supported by underlying wholesale business

relationships between several service providers.

It is extremely important to understand that the challenges of end-to-end service management exist

regardless of whether the business relationships follow a formal Service Syndication model or an Over-

the-Top (OTT) model. Let’s examine a use case where a customer, such as an enterprise IT department,

has a problem with Office 365 Lync VoIP quality. If they contact their local partner by calling into the

partner CSP’s CRM system, that CRM agent ideally should have the capability to see the health and

welfare of the service end-to-end. This means visibility into Microsoft resource management systems as

well as the CSPs resource management systems. If the customer calls into Microsoft support, then the

Microsoft support person should have visibility into the health and welfare of Microsoft Lync, its

underlying cloud infrastructure, as well as the local service provider’s network resource management

systems relevant to this service.

In the hypothetical Service Syndication example at Figure 9, Microsoft is providing Office 365 as

Software as a Service (SaaS) to a CSP that is bundling it with other services and reselling a package to

business customers. Although Microsoft runs a massive global data network and CDN, it does not own

the carrier’s core network or the access networks: the Backhaul, WiFi, 3G/4G /LTE and enterprise LAN

/WAN infrastructures that actually connect the cloud and network services to end user devices such as

Windows 8 PCs and Windows Phones. Communications Service Providers supply these capabilities. A



Page 19

local service provider might provide an IP or IP MPLS network service to provide an optimized VOIP

experience for an enterprise customer’s employees using Microsoft Lync.

Figure 9 – Complexity of managing syndicated services

There are two types of connection paths in play:

1. Service Delivery Path - that used by the Functional Interfaces of the services to deliver the

combined service value to the customer; in this case Lync plus MPLS that combine to create a

hypothetical Premium Office 365 bundle. A user making a Lync VOIP call exercises these

interfaces.

2. Service Management Path(s) – All of the logical management paths depicted above that

perform Operations and Maintenance functions such as Provisioning, Service Assurance and

Charging / Billing of the relevant services to this bundle.

The delivery path for the service, via their Functional Interfaces, is fairly obvious. The TM Forum SES

Management Solution does not consider them in the scope of its work. The real challenge and the focus

of the TM Forum SES Management is an efficient implementation of all the management functions

depicted by the colored lines between the CRM portal and the Administrative, Provisioning, Service

Assurance, and Charging functions for each component that makes up a complete service. Given the

proliferation of new service APIs enabled by the growth in cloud computing, particularly PaaS and SaaS,

the implementation of the management functions cannot require a major system integration effort with

each new service deployment. That simply will not scale and would become unmanageable.



Page 20

Cloud Computing Resource Management

There are two principal differences with cloud computing that make more difficult the problem of

managing resources associated with cloud services. One difference is the virtualization at the elastic

compute and elastic network layers. The other difference is that multiple clouds and multiple enterprise

domains are increasingly involved in the delivery of cloud services further complicating RM.

In the example below, a content provider sends content to another cloud service where the asset is

transformed and streamed by Azure Media

Services14 to mobile devices over a different

network. There are at least three different

participants in this service delivery scenario.

Each of the services operates within the

confines of separate enterprise domains.

End-to-End visibility can be difficult given

that the management capabilities for each

component, to the extent they exist at all,

are hidden behind multiple firewalls.

The situation is actually more complicated

than indicated in the above drawing. As

depicted in the Figure 11 below, each

individual service is actually dependent upon at least three layers of resources. From just a service

assurance point of view, the health and welfare of each service is an aggregation of the health and

welfare of a stack of technology. The resources at each layer are likely virtualized and may change over

time. A developer building a service can implement an SMI for their service / application. However, they

will need assistance from a Management Support System (MSS) and associated Infrastructure Support

Systems (ISS) if they want to implement an SMI

that also takes into account the underlying

Virtualized Compute and Virtualized Network

resources upon which each instance of their

service depends.

Cloud service and application management entails

supporting the management of virtual and

physical computing, storage, and network

resources. Effective Cloud resource management

is a core technical issue of cloud computing. Difficulties encountered when dealing with this issue is a

limiting factor to mainstream adoption of cloud computing.

14 For information on Azure Media Service please see

http://www.windowsazure.com/en-us/home/features/media-services

Figure 10 – Example content streaming to mobile device

Figure 11 – Windows Azure virtualized resource layers.



Page 21

Challenges of Virtualization

Cloud applications rely upon virtualized compute and virtualized network resources that can

both dynamically change their configurations in response to external policies and load

conditions. It is understood that there are both physical resources and logical resources

involved.

It is useful to look at cloud resource management from the point of view of the lifecycle

management of a cloud service. Each service must be acted upon by traditional business

processes associated with Provisioning/Configuration, Service Assurance, and

Charging/Billing/Settlement as it passes through it lifecycle.

In the simpler case of an application that resides on a single cloud infrastructure, it becomes

dependent upon two distinct layers of virtualized resources. The dotted lines depict the active

coordinated relationship that must be maintained between resources at

each layer. There must be a mechanism provided by a Management

Support System and Infrastructure Support Systems to maintain

awareness as to which logical and physical resources are actually relevant

to a specific instance of a specific application at any given point in time.

Although the elastic cloud infrastructure provided by IaaS and PaaS can

configure additional resources to handle changing application demands,

there are additional requirements for dynamically reconfiguring

underlying network configurations and routings in response to changing

resource allocations at the cloud compute resource layer. This can mean

dynamically rearranging the data center network to achieve

the fewest possible number of hops between any two

particularly active application nodes at any given point in time.

This issue arises within the internal network fabric of large

cloud datacenters, between two clouds especially the

interconnecting networks in hybrid cloud scenarios, and

externally across transport networks and CDNs.

Another issue that arises is the division of responsibility

between an internal cloud virtualization management layer

(IaaS and PaaS) and an external OSS. Although the cloud

virtualization layer can typically manage its own physical and

logical resource allocations for supported applications, an

external OSS may be required to dynamically reallocate

resources in a coordinated fashion across all three layers or to track and have knowledge of

those changing relationships.

Figure 12 – Three

Resource Layers

Figure 13 – Role of an OSS



Page 22

The capability of an MSS/ISS do both manage resource allocations and track their instantaneous

state enables an Operations Support System, such as Microsoft System Center 2012, to provide

the information necessary to display a dashboard of the health and welfare of a given service

and all of the underlying relevant resources at any given point in time. From a resource

management Quality of Service (QoS) point of view, Service Assurance systems need to be

receiving relevant telemetry in real-time from the service, cloud compute, and network

resources actually involved in delivering a particular instance of a service.

Challenges of Multi-Cloud

Up until now this discussion has been about the management of resources within the service,

cloud, and network resource layers vertically within one logical cloud resource stack. However,

actual cloud service delivery scenarios typically involve coordination across multiple clouds each

with its own MSS silo, and at least some services residing in completely different enterprise

service domains.

Figure 14 – Visualizing the service delivery path

In the Figure 14 above, a cloud service provider is delivering streaming content to user using a

mobile device attached to a wireless network. In order for the service to work, all of the

prerequisite services of both the Cloud Service Provider and the Communications Service

Provider must function properly. In many cases they do but it is often just a “best effort”.

However, if the consumer is not getting a good experience, who do they call? When either the

Communications Service Provider or the Cloud Service Provider becomes aware of a problem,

what tools do they have at their disposal to quickly resolve the problem in an effective manner?

With the addition of a Management Support System that can keep track of the health and

welfare of a service as well as the specific underlying virtualized compute and virtualized

network resources associated with it, each service provider becomes able to collect fault,

performance, and charging events. As part of implementing the business processes described in



Page 23

the TM Forum Business Process Framework, each service provider can implement event analysis

and business analytics to display a dashboard showing the current state of each service, the

underlying services upon which it is dependent or even the services that it impacts. However,

each service provider is still restricted to a view of only the services they control and monitor.

They cannot see the status of the service end-to-end from the user’s or consumer’s point of

view.

To support multi-cloud end-to-end service management, management capabilities must also be

exposed as Service Provider to Service Provider / B2B interfaces. These service/resource

management interfaces need to be able to expose the capability

to manage the relevant underlying resources in a coordinated

manner transparent to whatever external systems are interacting

with the service/resource management interfaces.

In the adjacent figure, one or more MSS (typically a BSS/OSS in a

telecom environment) are depicted providing the needed

management interfaces. Some SMI could be exposed directly

from the service. For example, an SMI might expose an

administrative interface to perform configurations very unique to

that service such as to assign users to a collaboration service like

Microsoft Office Lync service or assign users to a Dynamics CRM

Online implementation. Alternatively, certain SMI could be

provided by an MSS that provides management functions on

behalf of a cloud application. Here again, Microsoft System Center

2012 is suitable for this role.

Figure 15 – Visualizing service management

Figure 16 – Exposing B2B

management services



Page 24

“The provisioning interfaces

described become very important

in a true Service Syndication

scenario. Using a standard and

reusable SMI for provisioning

eliminates the need for a custom

integration effort to launch a new

service syndication partner.”

Figure 17 below illustrates what becomes possible when the SMI interfaces are exposed to other

service providers to enable end-to-end service management across a multi-cloud, multi-

enterprise domain scenario. Leveraging this new information, it becomes possible for the

service composition process to proceed now along four parallel paths:

1. Functional Interface to realize the core value achieved from the service composition itself.

2. Provisioning to define the end-to-end provisioning processes and sequence.

3. Service Assurance to define and populate a service model with Fault and Performance event

data used to measure QoS and monitor SLA conformance.

4. Usage events for Policy evaluation, Settlement, and Billing purposes.

Each of the above dashboards can now incorporate the information available from the relevant

SMIs. The SMI are not just one-way interfaces. The

Cloud Service Provider is able to maintain information

on the status of the Communications Service Provider’s

services that content streaming is ultimately dependent

upon. The Communications Service Provider is able to

maintain status of the SaaS component that is

streaming to their customer over a wireless network.

All stakeholders are now able to subscribe to and

collect event information from the services that are

relevant to the end user’s experience. In fact, Management as a Service becomes a new

potential type of premium service.

The provisioning interfaces described become very important in a true Service Syndication

scenario. Using a standard and reusable SMI for provisioning eliminates the need for a custom

integration effort to launch a new service syndication partner.

Figure 17 – Visualizing B2B service management



Page 25

For the Service Assurance SMI, the ultimate test of whether the correct metrics are being

collected and evaluated or not is simply whether the dashboards accurately display the status of

the composite service. If the dashboards are green and the customer has a complaint then the

metrics being collected are missing something important and need to be adjusted to more

accurately reflect reality from a customer’s viewpoint. The Simple Management Interface (SMI)

design template makes it feasible to iterate on this until dashboards sufficiently reflect customer

reality.

Figure 18 above provides another view of the multi-cloud service management reference

architecture. Note how the Functional Interfaces are logically connect to create a service

composition and the Simple Management Interfaces communicate with Management Support

Systems / Operations Support Systems to provide the visibility necessary to enable the service

provider to have a great operations experience even with a complex multi-cloud application.

Figure 18 – Another view of the SES Management Solution vision used in an ITU-T submission.



Page 26

Cross-Industry and M2M Applicability

The telecommunications industry has developed expertise in managing distributed service

creation and delivery over virtualized telecom network resources. Extensive work has been

done by various telecom industry standards organizations to define a common framework to

facilitate management of network elements and service overlays.

This reference architecture describes a way to now apply this evolved expertise to the broader

set of management issues associated with multi-cloud service and resource management.

However, the cloud ecosystem is not telecommunications network centric. The reference

architecture can be used to leverage the expertise of the telecommunications service providers

in the broader use case of multi-cloud resource management in a Web 2.0 world across multiple

industry verticals.

The TM Forum SES Management Solution and this Multi-Cloud Service Delivery and End-to-End

Management Reference Architecture is only concerned with the design pattern of having

Functional Interfaces and Simple Management Interfaces associated with each service. While

the pattern leverages best practices learned by the telecommunications industry managing

widely distributed mission critical networks, it is not concerned with the ultimate business

purpose of those services. Because of this abstraction, the reference architecture is equally

useful when used to implement SOA best practices in any industry vertical such as Healthcare,

Retail, Manufacturing, Financial, Logistics, Public Sector and Defense.

The Machine to Machine (M2M) use case helps illustrate the applicability of the Multi-Cloud

Service Delivery and End-to-End Management Reference Architecture to multiple industry

scenarios. A Windows Phone can easily become a device in a M2M scenario context. A Line of

Business Application (LOB) running on the device interacts with sensors such as GPS, RFID or

NFC etc. and communicates specific events to an industry specific cloud hosted LOB application

as represented in the top “Applications” band of Figure 19.

Figure 19 – M2M Cross Industry Example of Multi-Cloud Service Delivery



Page 27

Any of these scenarios would become significantly more practical if it were possible to manage

that application across the M2M / Multi-Cloud environment and achieve a meaningful capability

for end-to-end management. Note however that regardless of the industry vertical involved,

the communications “cloud” with its exposed services is one of the critical components and

prerequisite for successful service operation.



Page 28

Cost of Excellence in Quality of Service

Every customer initiated contact is a costly event. To minimize their occurrence, service providers

learned to harden their infrastructures and services to minimize failures sufficiently to meet customer

expectations. This is a primary reason why certain components are built to 99.995% reliability standards

or better. This was driven by economic necessity and is a reality of a network or cloud service delivery

business. Thus the lesson learned by the CSPs needs to be applied by cloud service providers as well

before mission critical line of business applications move in serious fashion to cloud computing.

When there is a customer contact, the customer service agent ideally should have all of the appropriate

information immediately accessible and actionable. This might include Service Order History, Trouble /

Performance / SLA History, and Billing information. The goal is for the agent to be able to handle during

the initial contact any questions concerning billing, service configuration, faults, or performance. This

includes being able to see via service dashboards and event lists what has transpired and to drill down to

obtain greater details on any significant item. The agent should also be able to initiate an order for new

or changed service configurations as a possible outcome to the customer initiated contact.

A self-service portal needs to provide sufficient information and capabilities to preclude the generation

of a customer initiated call into a work center. Particularly when it comes to meeting the needs of the

service developer building, deploying, or maintaining a service leveraging cloud computing resources, a

self-service portal should successfully guide the developer through all business and technical

interactions with the cloud. This includes the process of setting up an account, consuming service APIs,

building an application that will work reliably, deploying the application to the cloud, configuring cloud

resources efficiently, and being able to visualize usage and performance via dashboards.

There are two primary measures that determine the success of service delivery businesses in the

communications and media industries:

1. Customer Satisfaction – Will they be satisfied with product/service and if there is a problem, will

they be satisfied with Customer Service? If an agent demonstrates credible knowledge about a

service and of any service problems and conveys a sense of decisive and effective action,

customer satisfaction will remain high and customer churn will be suppressed. Agents must

have the proper information and tools in front of them to be effective. Alternatively, a self-

service portal must be able to convey the same information enabling the user to find the

answers they seek.

2. Operational Expense – How many steps are necessary to address typical issues? If

approximately 80% of problems can be handled effectively at the first point of contact, whether

a self-service portal or an agent, then the OpEx incurred handling problems is minimized and the

profitability of the service is protected. However, if the agent does not have useful tools in front

of them and can only create a trouble ticket and pass that off to another work center for action,

then Operational Expense could skyrocket making the service in question unprofitable. This is



Page 29

especially true for transient problems that are difficult to replicate. If the error is not capture in

real-time by recording the event along with actionable fault and performance data permitting

root cause analysis, the expenses of handling trouble reports and acting on them after the fact

may exceed revenues.

Figure 20 – Components of Service Quality



Page 30

Value of a Service Broker

This section is not intended to be a comprehensive overview of Service Brokers or Service Delivery

Platforms. The intent of this section is restricted to explaining certain key aspects of a Service Delivery

Platform particularly relevant from a Multi-Cloud Service Delivery Framework or Software Enabled

Services Management point of view. When the focus is on exposing a services layer and managing an

integration surface that spans multiple platforms or clouds, the term Cloud Service Broker or Service

Delivery Broker is used to differentiate from the somewhat overused term of SDP.

The concept of a Service Delivery Platform is relatively simple provided the services are all contained

within one well-defined boundary; a Windows Phone Application Store or an SDP for one set of

functions in a mobile operator’s network. However, once service providers begin to meld together

services from multiple domains, problems abound. Setting aside service interoperability for a moment,

the other major issue has to do with lifecycle management and the details of operations and

maintenance (Fulfillment, Assurance, and Billing) of the services and their components. If all the

services are contained within one service provider’s domain, then presumably, all of the services are

already managed by an established set of BSS/OSS15. As a result, the SDP itself has a relatively minimal

role to play in end-to-end service management. However, new issues begin to crop up with a service

bundle consisting of discrete services from multiple domains. These issues become more interesting

when the services from different domains will be actually integrated together in a loosely coupled

service mash-up.

For years the telecommunications industry has attempted to manage complexity with rigorous enforced

sets of rules for on-boarding services onto a Service Delivery Platform. The so-called “walled garden”

approach required services to be built to very specific standards and to become certified especially on

how they interact with other services and the network before being allowed to operate. This particular

type of certifying was sometimes referred to as “on boarding” a service onto the SDP.

The concept of a Service Delivery Framework (SDF) was defined that could enable a community of

service providers each managing their own domain of services, to collaborate and deliver manageable

services controlled by local SDPs and associated BSS/OSS for management functions. The core focus of

this work was on the ability to manage the resulting services end-to-end.

The question then arises “what is different” about the Service Delivery Platform envisioned by the SES

Management Solution from conventional telecom SDPs? The following discussion explains that

difference.

15 Business Support Systems / Operations Support Systems. The enterprise applications that a Communications

Service Provider or Cable Operator typically employs to manage all business processes from initial order through

Billing.



Page 31

The Telco SDP

There have been a number of attempts by CSPs and their telecom network centric suppliers to

leverage telecom network SDPs to manage a broader array of services exposed via APIs. These

telecom led efforts have had limited success. The reasons continued to be debated. However,

one can speculate that the telecom centric SDPs tend to be too highly specialized around the

needs of telecom/mobile network services. These telecom-centric SDPs implement and enforce

specialized standard often very complex interfaces as well as methods and procedures that do

not appear relevant to the broader Web 2.0 services marketplace and cloud computing in

general.

In Figure 21 below, services are depicted as existing in three distinct reference categories.

Granted, this is an over simplification but it provides a way to explain some key concepts. Each

column represents a major silo of application development. Although the technical details,

platforms and tools tend to be different for each silo, each silo loosely adheres to the following

architectural concepts:

• Fine grained service creation and management using tools often unique to that silo.

• Coarse grained service abstractions typically via SOAP and Web Services interfaces.

At the far right is the telecom network environment. This is where telecom SS7 / IP Multimedia

Subsystem (IMS) lives and Service Delivery Platforms excel at creating and implementing

services that require real-time event processing as well as policy, charging, and rules functions in

the course of setting up connections and delivering services.

Figure 21 – Multi-Cloud Service Management



Page 32

In the middle column is the enterprise IT technology stack. In this domain, IT professionals

design and implement mission critical Line of Business (LOB) applications appropriate for their

industry. Each industry, such as Public Sector, Financial Services, Healthcare, Manufacturing,

Retail, Communications and Media have their own interpretations of an Enterprise IT Reference

Architecture that in turn typically leverages best practices ( such as from ITIL and TOGAF) for

management and governance. For example, the communication industry’s reference

architecture is the TM Forum Frameworx. Many older legacy mainframe, client/server,

enterprise service bus environments live in this space as well as newer service oriented

implementations.

Finally on the left side is the Web 2.0 cloud service developer. Admittedly, an IT Professional

implementing enterprise service oriented architecture solutions could also be represented by

this section of the drawing. However, the intent is to emphasize newer Web 2.0 renditions of

services and service compositions. The bulk of 3rd party developers being recruited into various

developer ecosystems live in this space. The trend here is towards lighter weight interfaces such

as REST using JSON.

If the enterprise in question is a telecom or cable company, then the BSS/OSS of that

organization lives in that center column. If that center column enterprise some other industry

such as a financial enterprise, then the industry reference architecture for a financial institution

would replace the “BSS/OSS” reference architecture depicted in the center silo.

The ICT16 Service Delivery Broker

Given that the concept of a Service Delivery Platform evolved first in the telecom industry, it is

not surprising that many telecoms attempted to extend those SDPs to also govern the creation,

deployment and operation of web services. This was greatly accelerated with the original vision

of IMS and its notion of an application layer hosting services governed by underlying IMS control

functions for policy, charging and rules. There have been several attempts at expanding

telecom/network services centric SDP environments to assume overall lifecycle management

and runtime control over a broader array of services including those being abstracted by the

Enterprise IT and Web/Cloud developers.

What evolved instead during the last ten years was the concept of Converged Service Delivery

for the Information Communications Technology industry as a whole. In addition to the

traditional Communications Service Provider (CSP) and Cable Operators (MSO), new types of

service providers offering internet web hosting, cloud services, and the social network platforms

expanded the requirements for service lifecycle management and runtime from a telecom

network centric topic to much broader ICT topic. The growth of the internet and later cloud

computing caused the telecom industry to no longer be the dominate force in service creation

16 ICT – “Information and Communications Technology”



Page 33

and delivery. Furthermore, the evolution of services orientation approach to architecture

contributed additional needs to accelerate and manage more effectively at the Integration

Framework layer.

The requirements of an SDP still exist. However, solutions now need to appeal to the broader

needs of the ICT industry as a whole. This ICT Service Delivery Broker can provide a set of

reusable core capabilities (services) to both speed development processes and to support

runtime operations. Some of the reusable services such an SDB can provide include:

• transports,

• bindings and protocol mediation,

• support for all needed message patterns,

• common tasks such as security & access control,

• event processing engine,

• routings,

• performance / traffic monitoring,

• mechanisms for real time visibility into performance and usage including Dashboards.

API Management

APIs are becoming the critical common currency of service creation and delivery. Developers

have been creating interfaces to applications and services for years. However in the absence of

the structure that a service delivery broker can provide, these APIs provide only a limited

capability for application integration, assume or favor a specific programing language, contain

programing techniques that are not best practice from an industry level (example non W3C

compliant code generation) and often require significant system integration efforts to

implement.

When an organization truly adopts a service orientation there is a very significant material

impact on how APIs are built and how they are used. APIs developed without a true services

orientation have a tendency to be coarse grained providing a limited exposure to the underlying

fine grained features. Often much of the actual work flow in applications happens outside of

these coarse grained interfaces. Therefore, there tends to be a fewer number of APIs that are

only used for a limited subset of use cases. For instance, a function might be exposed externally

via a JAVA API but internal users of that service use different, more feature rich interfaces.

When a true services orientation is adopted, the same APIs become used by both internal and

external users. Policy and rules evaluation processes become reusable supporting services

invoked in conjunction with the use of a service creating policy-based use governance enabling

secure reusability. As the number of internal only APIs is reduced, the number of published

reusable service APIs can expand greatly. This leads to a new requirement of being able to

manage efficiently a growing catalog of services throughout their lifecycle.



Page 34

In Figure 22 below we have identified two sets of APIs:

• Functional Interfaces

• Management interfaces

Adding Simple Management Interfaces in addition of the existing functional interfaces

contributes additional numbers of APIs that need to be managed just within one service

provider.

If there are only two services involved in either an intra-service provider or inter-service

provider integration, it is easy to imagine how the functional interfaces can be integrated

together to create a combined service offering and how each of the Simple Management

Interfaces could be combined to define end-to-end management.

Difficulties arise when the number of services becomes very large. Custom point-to-point

integration can get the job done as long as there are not frequent changes. However, when the

APIs number in the thousands, when there are frequent updates and version control becomes

an issue, or when the number of service provider domains expands into many to many

relationships, a much more systematic approach is needed for API Service Lifecycle

Management, Integration, and Runtime operations. The prospect of M2M should drive home

the point that a much more efficient and reliable means of service lifecycle and operations

management is required.

Figure 22 – Functional and Management APIs



Page 35

A broker is one mechanism that addresses these operational problems. A service delivery

broker or cloud service broker does this by providing some of the core functions defined in the

TM Forum Integration Framework as reusable services. Furthermore, by facilitating the process

of creating and integrating management functions exposed by each Simple Management

Interface, a broker can reduce the need for custom integration that would otherwise be

required to effectively manage these new service compositions.

An SDB can provide the following API management functions:

• Service API Catalog Functions

• ITILv3 2011 Aligned Service Lifecycle Management and Metadata Model Management

• Tools to Implement standard Simple Management Interfaces

• Wizards to support a true services orientation

• Contract first development methodology and Governance

• Runtime Management Operations

Depending upon the service in question, the broker could be involved in helping to manage the

lifecycle management of services APIs, the runtime management of the Service APIs, or both.

Depending upon the context of the service, and the design decisions of the service provider or

enterprise implementing enterprise service oriented architecture, the broker could

accommodate the allocation of specific functions to different resources. For instance, in the

case of a set of cloud services that are largely hosted web services, the broker could provide

certain necessary policy, charging, and rules based functions directly. Alternatively, some

functions could instead be handled by a dedicated billing BSS/OSS application. Alternatively, in

the case of certain services leveraging telecom service exposure layer, it may well be optimal to

leverage the IMS Policy, Charging, and Rules Function (PCRF) in the network.

Figure 23 – The Service Delivery Broker (SDB) as an API management system



Page 36

This approach enables the reference architecture to provide three key value propositions

mentioned in the introduction:

1. A Great User Experience

2. A Great Developer Experience

3. A Great Operations Experience

In Figure 24, there are two cloud stacks depicted on the Telecom Operator side. One depicts the

Telecom Cloud infrastructures that virtually all CSPs and MSOs are implementing. The other

stack is the telecom network itself. The telecom network (voice/data, core transport, backhaul,

access) is just another cloud running over a virtualized stack of resources exposing services for

consumption by developers in service compositions.

Several important points need to be clarified at this point:

1. Service APIs can be created independent of a Service Broker: Most service APIs being

exposed today are in fact created independently of the governance provided by a

Service Delivery Broker. They may be created out of fine grained services by a lower

level Service Delivery Platform and exposed as coarse grained services as discussed in

Figure 21. However, the wide inconsistency today in the application of standards as

these services are exposed results in a significant amount of custom integration work

when combining these service APIs into more complex offerings.

2. Many Service Delivery Brokers: Figure 24 is not meant to imply there should be one

“all-controlling” über Service Delivery Broker. In reality, there will be many SDBs in

operation. An SDB enables one view into a universe of Service APIs. It is likely that most

service providers will want to have a Cloud / Service Delivery Broker to support their

Figure 24 – The SDB in a Services Orientated developer governance role



Page 37

localized developer ecosystem and to support their version of a service marketplace.

Enterprises are beginning to discover they too can use this type of Service Delivery

Broker to guide a true service orientation across their enterprise architecture.

3. SDB as a Service: Some stakeholders may be interested in leveraging a “Service Delivery

Broker as a Service” offering. A service provider could gain the benefits of managing

their own view into a set of service APIs without incurring the cost and expense of

implementing their own Broker. An enterprise can use a cloud hosted SDB as a core

part of their services orientation governance.

4. SDB as a mediator between other Service Domains: A particular service may become

exposed from two or more service brokers. The broker a developer or enterprise

chooses to use will depend upon the value that particular broker brings to the

development, runtime management, and service monetization process versus a

different broker offering the similar services. A well-executed SDB can deliver up to a

50% reduction in service creation and integration costs for an enterprise or service

provider / operator. SDB as a Service with global reach could help create consistent

service creation and runtime environments very efficiently. This is having two impacts:

• There is a trend towards lightweight APIs that work consistently across

multiple cloud and service domains. For instance REST Web Services using

JSON.

• How well any given SDB is executed and helps operators achieve significant

operational efficiencies and drive service monetization will likely determine

which SDB implementations will become most prevalent in the future.



Page 38

Figure 25 – SMI as a Value Added Service

Implementing Multi-Cloud Service Management with Microsoft

In this section we will consider how one can build manageable services on either a Microsoft On-

Premises Cloud or Public Cloud employing the techniques outline by the TM Forum Software Enabled

Services Management Solution.

The core Microsoft components relevant to this discussion are:

On-Premises Private/Public Cloud:

• System Center 2012

• Windows Server 2008 R2 or Windows Server 2012.

• SQL Server

Off-Premises Public Cloud:

• Windows Azure

• SQL Azure

In order to offer an SLA (Service Level Agreement) on a service that depends upon the performance of

several underlying component services, each of those component services must be manageable. It is

not sufficient to be able to

measure the health and welfare

of just the service itself. True

management of an individual

cloud service means managing

the entire technology stack

including the relevant parts of the

virtualized compute layer and

virtualized network layer. The

Microsoft cloud platform can

offer the developer a “chassis” on

which to deploy a service that can

be managed as envisioned by the

TM Forum SES Management

Solution.

Certain aspects of service

management are unique to the service itself. The SMI associated with these application specific

management functions may need to be implemented by the developer as a function within the service

itself. For example, a service may require specific users to be authorized to use that service or to

perform functions within the confines of a predefined role. However, other management functions may

need the assistance of an Operations Support System (OSS), such as System Center 2012, that is aware



Page 39

of the relationship between a given service instance and the virtualized resources supporting it. In

Figure 26, a developer seeking to build a service that will be published in a service catalog can plan on

leveraging the capability of Microsoft Cloud platforms to expose interfaces necessary to deploy and

manage that service and to report on the health and welfare of the underlying resources supporting that

service. Leveraging the concept of Concurrent Contracts,17 the developer may need to allow for the

possibility of having more than one contract available for the same service.

17 For a discussion of Concurrent Contracts see: http://www.soapatterns.org/concurrent_contracts.php

Figure 26 – Flexible SMI deployment options



Page 40

APIs for Measuring Azure Performance by Application

Microsoft Windows Azure provides specific mechanisms for gathering and exposing

performance metrics:

• Cloud Services - http://www.windowsazure.com/en-us/manage/services/cloud-

services/how-to-monitor-a-cloud-service/

• Media Services - http://www.windowsazure.com/en-us/manage/services/media-

services/how-to-monitor-a-media-services-account/

• SQL Azure - http://msdn.microsoft.com/en-us/library/windowsazure/ff394114.aspx

• Storage - http://www.windowsazure.com/en-us/manage/services/storage/how-to-

monitor-a-storage-account/

• Service Bus - http://www.windowsazure.com/en-us/manage/services/service-

bus/monitor-service-bus-messaging-entities/

• Web Sites - http://www.windowsazure.com/en-us/manage/services/web-sites/how-to-

monitor-websites/

For performance metrics on the Azure platform developers can leverage published API's as

pointed out in this blog:

• https://blogs.technet.com/b/speschka/archive/2011/08/23/windows-azure-1-4-

diagnostics-all-up-overview.aspx

“Setting up Performance Counters In Your Azure Web and Worker Roles” in this blog:

• http://blogs.msdn.com/b/walterm/archive/2011/02/01/setting-up-performance-

counters-in-your-web-and-worker-roles.aspx

Additional information on the use of these APIs:

• http://msdn.microsoft.com/en-us/library/windowsazure/ee460799.aspx

• http://msdn.microsoft.com/en-us/library/hh180875.aspx

• http://msdn.microsoft.com/en-

us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx

Here is a link that lists the performance counters exposed in Azure.

• http://blogs.msdn.com/b/avkashchauhan/archive/2011/04/01/list-of-performance-

counters-for-windows-azure-web-roles.aspx

Monitoring Pack for Windows Azure Applications

The Monitoring Pack for Windows Azure Applications enables you to monitor the availability and

performance of applications that are running on Windows Azure. The monitoring pack runs on a

specified agent and then uses various Windows Azure APIs to remotely discover and collect

instrumentation information about a specified Windows Azure application. The Monitoring Pack

for Windows Azure Applications provides no functionality on import. For each Windows Azure

application that you want to monitor, you must configure discovery by using the Windows Azure



Page 41

Application monitoring template. For more information, see “Configuring the Monitoring Pack

for Windows Azure Applications” at http://technet.microsoft.com/en-us/library/gg276377.aspx.

After configuration, the Monitoring Pack for Windows Azure Applications offers the following

functionality:

• Discovers Windows Azure applications.

• Provides status of each role instance.

• Collects and monitors performance information.

• Collects and monitors Windows events.

• Collects and monitors the .NET Framework trace messages from each role instance.

• Grooms performance, event, and the .NET Framework trace data from Windows Azure

storage account.

• Changes the number of role instances.



Page 42

Getting the Latest Monitoring Pack and Documentation

The Monitoring Pack for Windows Azure Applications can be found in the System Center

Operations Manager Catalog:

• http://systemcenter.pinpoint.microsoft.com/applications/search?q=azure

There is a related project available on Codebox: http://codebox/azuremon

The Azuremon Project facilitates monitoring Azure applications via System Center Operations

Manager. This is primarily focused on SCOM connector development that will consume Azure

logs and forward to Microsoft System Center Operations Manager efficiently. Create or add

SCOM management pack elements to support this.

Two main components

• SCOM Management pack - an MP that defines Azure service hierarchy and sample

monitors

• SCOM Connector Service - talks to Azure Service Management API and XStore to write

discovery and log information to SCOM

Microsoft is updating this product to System Center 2012. Information on the new features is

located on TechNet.

System Center 2012 Main Page:

See the System Center 2012 documentation for each component.

App Controller

Configuration Manager

Data Protection Manager

Endpoint Protection

Operations Manager

Orchestrator

Service Manager

Unified Installer

Virtual Machine Manager

http://technet.microsoft.com/systemcenter/hh880681

Operations Manager 2012:

• http://technet.microsoft.com/systemcenter/om/hh285243

Cloud and Datacenter Management:

• http://www.microsoft.com/server-cloud/system-center/datacenter-management.aspx

This management pack for System Center Operations Manager (SCOM) provides a more usable

and consistent interface into the Azure diagnostics and performance metrics. The pack is

installed on a System Center Operations Manager 2007 R2 Cumulative Update 3 environment

that can remotely access the Azure applications. Features include:



Page 43

• Discovers Windows Azure applications.

• Provides status of each role instance.

• Collects and monitors performance information.

• Collects and monitors Windows events.

• Collects and monitors the .NET Framework trace messages from each role instance.

• Grooms performance, event, and the .NET Framework trace data from Windows Azure

storage account.

• Changes the number of role instances via a task.

This management pack can used to perform all of the low level data collection activities and to

then consolidate into a single feed that could be provided to the mechanism supplying feeds to

the Service Model system. Details are available here:

• http://www.microsoft.com/en/download/details.aspx?id=11324



Page 44

The Multi-Cloud Developer Experience Catalyst

The Multi-Cloud Developer Experience Catalyst for Management World Americas 2011 sought to validate, test, and drive the work of the TM Forum Software Enabled Services (SES) Management Solution initiative. The SES initiative is working on how traditional Communications Service Providers (CSPs) can effectively create new revenue opportunities by expanding their service ecosystem and by offering end-to-end service management as a value added offering. Specifically, the Multi-Cloud Developer Experience Catalyst tested the progress made to define standards and best practices that would facilitate delivering superior developer experiences in conjunction with supporting end-to-end service / resource management in multi-vendor, multi-cloud environments.

Figure 27 – TM Forum Multi-Cloud Developer Experience Catalyst

The relationship between the Cloud, the TM Forum Frameworx, IT service management best practices (e.g. ITILv3 2011), and SOA best practices is explicitly examined by the Multi-Cloud Developer Experience Catalyst. This Catalyst built upon the ongoing work of the TM Forum SES Management Solution, and the previous Service Delivery Broker Catalyst phases 1 and 2. It considered input from the TM Forum ECLC (Enterprise Cloud Leadership Council), SPLC (Service Providers Leadership Council) and the Frameworx SES/MTOSI (Software Enabled Services / Multiple Technology Operations Systems Interface) TIGER Team.

Recommendations derived from this work have been submitted via liaisons to the ITU-T, OMG, and the NIST (National Institute of Standards and Technology).



Page 45

CSPs have a growing need to be able to efficiently create, forecast, and plan capacity requirements while deploying, monetizing, and managing services enabled by resources residing in multiple clouds. Historically, the design of systems to manage service delivery resources has been bounded by the fact that those resources were exposed from within the service provider’s controlled infrastructures. This design assumption is no longer valid.

The TM Forum Strategic Plan notes that “many service components (such as content, applications, etc.,) lie outside the service provider’s own company.” SaaS, PaaS, and IaaS are all parts of the cloud ecosystem that service providers need to incorporate into their service delivery management planning.

The very nature of creating, operating, and managing (as in Fulfillment, Assurance, and Charging/Billing) cross-domain, multi-cloud service assemblies with both Functional Interfaces and Management Interfaces requires far greater adherence to existing standards than the industry has been prone to follow in the past. The proliferation of service APIs makes urgent the need for a publicly available catalog of APIs to enable developer ecosystems and Over-the-Top (OTT) business models around exposed service provider resources. The cloud services community also needs to make it easier to employ governance mechanisms that guide people acting, for example, in the various lifecycle roles described in ITILv3 2011 along a path of Inter-domain / Enterprise SOA best practices such that the applicable standards are actually used in an effective manner.

A white paper was published at the conclusion of this Catalyst titled: “Best Practices and Standards Recommendations derived from the Multi-Cloud Developer Experience Catalyst”, http://collab.tmforum.org/sf/docman/do/downloadDocument/projects.service_delivery_framework/docman.root.phase_vi.contributions_discussion_materia/doc20976



Page 46

Release History

Release Number Date Modified Modified by Description of Changes

1.0 2 July 2012 Eric Troup Initial Release of Version 1.0

1.1 15 Jan 2013 Eric Troup Updated to reflect changes associated with

the release of the TM Forum Digital Services

Initiative. Updates to Azure API references

and System Center Management Pack

references.



Page 47

References

Microsoft System Center. (2011, July). Guide for System Center Monitoring Pack for Windows Azure

Applications. Retrieved from http://www.microsoft.com/en-

us/download/details.aspx?id=11324

Portugal Telecom SAPO. (2012). Service Delivery Broker. Retrieved from

http://sdb.sapo.pt/en/index.html

Thomas Mendel, P. a. (2006). Converged Service Delivery: The Missing Link In Achieving Business

Flexibility. Cambridge, MA: Forester Research Inc.

TM Forum. (2008, June). TR141 - SDF - Industry Groups Positioning Document. Retrieved from Software

Enabled Services Management:

http://www.tmforum.org/TechnicalReports/TR141ServiceDelivery/35371/article.html

TM Forum. (2009, April). TMF061 - Service Delivery Framework Reference Architecture. Retrieved from

TM Forum Software Enables Services Management:

http://www.tmforum.org/TechnicalSpecifications/TMF061ServiceDelivery/39341/article.html

TM Forum. (2009, Jul). TR139 - Service Delivery Framework Overview. Retrieved from TM Forum

Software Enabled Services Management:

http://www.tmforum.org/TechnicalReports/TR139ServiceDelivery/34303/article.html

TM Forum. (2010). TMF618 - Software Enabled Services Lifecycle Management Metadata Interface

Information Agreement. Retrieved from TM Forum Software Enabled Services Management:

http://www.tmforum.org/InformationAgreements/TMF618SoftwareEnabled/46847/article.html

TM Forum. (2012, February). TMF617 - Software Enabled Services Management Interface Information

Agreement. Retrieved from Software Enabled Services Management:

http://www.tmforum.org/DocumentCenter/11777/home.html#TRCDocuments/artf2533

TM Forum. (2012, February). TR168 - Software Enabled Services (SES) Management Solution and

Frameworx Relationships. Retrieved from Software Enabled Services Management:

http://www.tmforum.org/TechnicalReports/TR168SoftwareEnabled/46857/article.html

TM Forum. (2012, Dec). TR194, Multi-Cloud Service Management Accelerator Pack - Introduction,

Release 1.0. Retrieved from Multi-Cloud Management Pack:

http://www.tmforum.org/TechnicalReports/TR194MultiCloudService/50768/article.html

TM Forum. (2012, Dec). TR195, Multi-Cloud Service Management Pack - Business Guide, Release 1.0.

Retrieved from TM Forum Multi-Cloud Management Pack:




Page 48

TM Forum. (n.d.). TR196, Multi-Cloud Service Management Pack - Technical Guide, Release 1.0.

Retrieved from TM Forum Multi-Cloud Management Pack:


Troup, E., & Huang, J. (2011, Dec). Best Practices and Standards Recommendations derived from the

Multi-Cloud Developer Experience Catalyst. Retrieved from

http://collab.tmforum.org/sf/docman/do/downloadDocument/projects.service_delivery_frame

work/docman.root.phase_vi.contributions_discussion_materia/doc20976

Willetts, K. (2012). Unzipping the Digital World. Morristown, NJ: TM Forum.

multi-cloud service delivery and end-to-end management

Technology

event processing

great operations

simple management

service syndication

great developer

simple management

latest monitoring

software enabled