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

©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.

Microsoft Communications and Media Industries 15 Jan 2013

Page 1


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 2


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 3


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 4


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 5


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
Figure 1 – The Multi-Cloud Nature of Service Delivery
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.

Page 6


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.

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

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.


Page 7


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 8



Page 9


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 10


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 11


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.

Figure 3 – Four operations issues of multi-cloud

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.


Page 12


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.

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

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.


Page 13


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,
Figure 5 – TM Forum SES Interfaces
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.


Page 14


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 Figure 6 – Types of Service Interfaces
can expose usage / charging events that can

10
TM Forum TR139, “Service Delivery Framework Overview”, Page 16.
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 15


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 Figure 7 – TM Forum SES LMM Management Phases (Draft)
• 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.


Page 16


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 Figure 8 – Programmable Web API Growth
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.


Page 17


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 18


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 19


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 Figure 10 – Example content streaming to mobile device
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
Figure 11 – Windows Azure virtualized resource layers.
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


Page 20


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
Figure 12 – Three
Resource Layers 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 Figure 13 – Role of an OSS
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.


Page 21


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 22


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,

Figure 15 – Visualizing service management

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
Figure 16 – Exposing B2B
provided by an MSS that provides management functions on management services
behalf of a cloud application. Here again, Microsoft System Center
2012 is suitable for this role.


Page 23


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-

Figure 17 – Visualizing B2B service management

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
“The provisioning interfaces
Cloud Service Provider is able to maintain information
described become very important
on the status of the Communications Service Provider’s
in a true Service Syndication
services that content streaming is ultimately dependent
scenario. Using a standard and
upon. The Communications Service Provider is able to
reusable SMI for provisioning
maintain status of the SaaS component that is
eliminates the need for a custom
streaming to their customer over a wireless network.
integration effort to launch a new
All stakeholders are now able to subscribe to and
service syndication partner.”
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.


Page 24


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

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

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.


Page 25


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.

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

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.


Page 26


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 27


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 28


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 29


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 30


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

Figure 21 – Multi-Cloud Service Management

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.


Page 31


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 32


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 33


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

Figure 22 – Functional and Management APIs

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.


Page 34


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

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

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.


Page 35


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.

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

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


Page 36


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 37


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.
Figure 25 – SMI as a Value Added Service
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 38


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

Figure 26 – Flexible SMI deployment options

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


Page 39

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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Multi-Cloud Service Delivery and End-to-End Management

Similar a Multi-Cloud Service Delivery and End-to-End Management (20)

Último

Último (20)

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