The document discusses the issues with layering management in telecommunications into domains like product, service, and resource. This leads to unnecessary replication of functionality through separate APIs and information models at each layer. An alternative approach is proposed with platforms that focus on different activities like customer facing or infrastructure, but without strict layering. There would be a single API and information model used across all platforms.

1. The Evils of Layering in Telecom
Management
Stephen Fratini, The Art of Managing Things
1 March 2019
© The Art of Managing Things 1

2. Section 1: Overview
© The Art of Managing Things 2

3. Problem to be Addressed
• Management of a telecommunications network is a complex task and like
most complex tasks, a reasonable plan of attack is to divide the problem
into smaller pieces. In the telecommunications industry, there has been
and continues to be a trend to divide management into domains/layers
such a product, service and resource. In some cases, these domains/layers
are further subdivided, e.g., service is sometimes divided into customer-
facing service and resource-facing service, and resource is sometimes
divided into logical and physical resource. On the surface, this approach
appears reasonable. However, in detail, this approach leads to inefficient
solutions and unnecessary replication of functionality.
• This issue is discussed more generally (across multiple industries) in The Art
of Managing Things [1] . In this blog, the issue is examined more closely in
the context of telecommunication. A solution is offered that does not
depend on strict layering.
© The Art of Managing Things 3

4. Section 2: Concepts
Before getting into the specific problem at hand, some terminology is needed (all
borrowed from The Art of Managing Things [1] ). The definitions below foretell of
the solution that is discussed later in the blog.
© The Art of Managing Things 4

5. Things
In what follows a “thing” is anything that can be managed.
Figure 1 depicts an external view of a thing. Each instance of a thing has several
interfaces:
• Capabilities – what the thing offers to other things via a message exchange (e.g.,
request-reply pattern).
• Management – allows for administration of the thing, e.g., configuration,
accounting and usage collection and reporting, assurance management, and
control of access right to the capabilities. The Management interface is based on
message exchanges.
• Input / Output – a flow that is transformed by a thing. The Input / Output
interfaces are not based on message exchange but rather on streams of things
such as data, e.g., a firewall acting on a stream of IP packets. The entry and exit
points from a thing related to a flow are called ports.
• Requires – what the thing needs from other things to function properly. The
Requires interface is based on message exchanges.
© The Art of Managing Things 5

6. Requires
ManagementCapabilities
Input Output
Figure 1. External View of a Thing
© The Art of Managing Things 6

7. Viewpoints of a Thing
Each thing can be viewed from different viewpoints based on what needs to be
managed. Figure 2 shows various viewpoints for a virtual firewall. In general, each
thing can be viewed from the following perspectives:
• The Commercial Viewpoint concerns the transfer of ownership and has
information such as price, warranty and delivery charges.
• The Capability Viewpoint concerns the uses of a thing (functional characteristics)
and how well it can provide its capabilities (non-functional characteristics).
• The Environmental Viewpoint describes the expected or acceptable environment
for a thing. In general, the environmental viewpoint states what a thing requires
of other things in order to provide its capabilities. This is basically a statement of
dependencies.
• The Composition Viewpoint gives some information about how a thing can be
used to create more complex structures.
A key point here is that these are viewpoints of one thing and not multiple things.
In the Product-Service-Resource approach, the same thing can in some cases be
treated as multiple things.
© The Art of Managing Things 7

8. Virtual
Firewall
Requires
ManagementCapabilities
Inputs
Outputs
Capability Viewpoint
Functional characteristics: list of features
and associated descriptions
Non-functional characteristics: e.g.,
maximum number of input packets that
can be processed per second, supported
languages
Management characteristics: description
of management capabilities offered by
the firewall, e.g., the performance metrics
that can be generated
Commercial Viewpoint
Price: $10,000 to buy (also
available per hour and per user)
Guarantees:
30-day free trial
60-day money-back
guarantee
Environmental Viewpoint
Requires: description of what is required for
the firewall to function properly
Composition Viewpoint
Recommended for use
with the following types of
virtualized appliances …
Figure 2. Viewpoints of a Virtual Firewall
© The Art of Managing Things 8

9. Specification of a Thing
• The specification (description) of a thing can be decomposed into
viewpoints (as shown in Figure 3). For a given purpose, information
from one or more viewpoints can be used and exposed (e.g., showing
things to customers for possible purchase).
© The Art of Managing Things 9

10. Thing
Specification
Commercial
Viewpoint
Capability
Viewpoint
Environmental
Viewpoint
Composition
Viewpoint
Figure 3. Specification for a Thing
© The Art of Managing Things 10

11. Platforms and Domains
A “platform” is a supporting environment for a collection of things. An example
would be a management system optical transmission within a telecommunications
network. In terms of implementation, a platform can be a combination of
automated systems, methods and procedures, and people.
A “domain” is a collection of things that are grouped together under a common set
of policies.
A platform facilitates a desired outcome or set of outcomes on one or more things
within a domain. This is essentially an intent-based statement that relates the
concepts of "platform" and "domain." A platform represents a governance
boundary for the management of a set of things. The set of things is defined by one
or more domains.
Platforms are also things and as such have the same external appearance as a
thing. However, one specialization is made for platforms, i.e., the management
interface is further decomposed into management for the capabilities offered by
the platform and management of the platform itself (e.g., storage or compute
capacity management). The external view of a platform is depicted in Figure 4.
© The Art of Managing Things 11

12. Platform
Capabilities
Capabilities
Management
Platform
Management
Inputs
Outputs
Requires
Figure 4. External View of a Platform
© The Art of Managing Things 12

13. Section 3: Current Approach
© The Art of Managing Things 13

14. Product-Service-Resource (PSR) Paradigm
In many if not most cases, the current approach to telecommunications
management is based on the Product-Service-Resource (PSR) paradigm or
some variation thereof. In this approach, things are classified as being
products, service or resources. Depending on the situation a given instance
of a thing can be treated as a product, a service, and a resource. For
example, a virtual router can be considered as a resource which may be
offered as a service to customers. The commercial details of the router are
exposed as a product. For more details on the PSR paradigm, see MEF 50.1
[2] and the TM Forum Information Framework [3] [4] [5] .
The approach leads to a platform strategy that echoes the Product-Service-
Resource paradigm. A simplified platform deployment arrangement is shown
in Figure 5. Communication Service Providers (CSPs) will often need to have
multiple instances of a platform at a given domain because of national
boundaries and associated laws, span of control issues and type of customer
(e.g., one product platform for residential customers and another for
business customers).
© The Art of Managing Things 14

15. APIs and Information Models
• As depicted in Figure 5, layer-specific APIs are used for the same task.
For example, there are distinct APIs for Product, Service, and
Resource inventory.
• There are also distinct information models at each domain. Base
entities are defined for Product, Service, and Resource as well as
associated specifications for each of the three types of entities. The
base entities for Product, Service, and Resource are further
specialized for each subtype. The specializations could be as simple as
adding attributes and as complex as defining subclasses with
associations (beyond those already in the superclass).
© The Art of Managing Things 15

16. Product Platform
Product Inventory API
Product Catalog API
Product Ordering API
Service Platform
Service Inventory API
Service Catalog API
Service Ordering API
Service Configuration
Service Problem API
Resource Platform
Resource Inventory API
Resource Catalog API
Resource Ordering API
Resource Configuration
Resource Problem API
Figure 5. Simplified Platform Arrangement
© The Art of Managing Things 16

17. Issues with Current Approach - APIs
As hinted in the previous section, there are several areas where the current
approach is not efficient. The most obvious issue concerns the use of different APIs
for the same purpose in each domain/layer. APIs for management areas such as
inventory, catalog management, ordering, and problem management can be
defined very generically to handle many types of entities (spanning Product,
Service, and Resource). When the APIs are replicated and unnecessarily specialized,
this leads to
additional standards coordination
document synchronization with regard to the CSP’s specs which may or may not be
based on standards
multiple development efforts for essentially the same API (e.g., Product inventory
API, Service inventory API, and Resource inventory API)
software maintenance issues for the larger number of APIs
cross-platform integration being unnecessary more complicated by using different
APIs (in each domain/layer) for the same purpose.
© The Art of Managing Things 17

18. Information Model – Service and Resource
The issues with separate information models for the Product, Service, and
Resource domains/layers is a bit more involved. For the service and resource
layers, the separation is unnecessary and can be replaced by a cascading
dependency relationships among things. There is no reason to say that
somewhere in a dependency chain the entities transition from “service” to
“resource.”
For example, consider the situation shown in Figure 6. The Content Delivery
Network (CDN) depends on a Virtual Private Network (VPN) and several
content servers. The VPN, in turn, depends on two virtual routers and one
Ethernet Virtual Private LAN (EVP-LAN). The basic question is “why draw a
line somewhere in such a dependency chain and say what’s above the line
are services and what’s below the line are resources?” It’s fine if some things
are intended to be offered externally to customers while other things are
meant to be internal. That doesn’t imply a need to segregate things into
services and resources.
© The Art of Managing Things 18

19. CDN
VPN Content
Server
vRouter vRouter
EVP-
LAN
Content
Server
Figure 6. Thing Dependencies
© The Art of Managing Things 19

20. Information Model - Product
• The rationale for the separation of Product from Service varies among
CSPs, with some CSPs combining the two domains/layers. The general
idea is that Products are sold to customers and as such require
various commercial information, e.g., price and billing options.
However, this doesn’t require another layer and can be handled by
attaching (via association) commercial-related information to a thing
that is to be offered externally.
© The Art of Managing Things 20

21. Other Issues
• What about providing a more abstract view of a thing to a customer –
doesn’t this require a Product layer? No. For example, if a vRouter was to
be offered directly to end customers, it could be encapsulated within
another object (call it a Consumer vRouter) that is the basic vRouter with
an intent-based set of APIs. This does not require another layer. Further,
this type of abstraction may be needed in several places in a dependency
tree and does not imply the need for layering.
• Multiple base information models (one for each the Product, Service and
Resource domains/layers) leads to similar problems as with multiple APIs,
i.e., standards coordination, document synchronization, multiple
development efforts, software maintenance issues, and cross-platform
integration.
• Further, this type of layered approach encourages, if not requires, different
management systems for each layer. This is perhaps good for management
system providers but not so good for the CSPs.
© The Art of Managing Things 21

22. Alternate Approach
© The Art of Managing Things 22

23. Example of Alternate Approach
Figure 7 depicts an alternative approach to the PSR approach. There
are still platforms that focus on different activities. The Customer
Facing Platform is focused on exposing commercial aspects of things to
customers. The Externally Offered Capabilities Platform manages things
that are directly accessed by customers, and the Infrastructure
Platform manages things are required by the Externally Offered
Capabilities Platform. However, there is only one API for each type of
management area (inventory, catalog, ordering, etc.) and there is only
one base information model used in all three platforms.
© The Art of Managing Things 23

24. Customer Facing
Platform
Inventory API
Catalog API
Ordering API
Infrastructure
Platform
Inventory API
Catalog API
Ordering API
Configuration API
Problem Mgmt. API
Externally Offered
Capabilities
Platform
Inventory API
Catalog API
Ordering API
Configuration API
Problem Mgmt. API
Figure 7. Alternate Platform Arrangement
© The Art of Managing Things 24

25. Alternate Approach
• Figure 7 is just an example platform collection and associated arrangement.
Figure 8 depicts some general recommendations for platform
arrangements. There is no layering but there are dependencies. There is
one API for each management area, and one base information model
(which clearly needs to be specialized for various types of things). At the
bottom of the diagram are platforms that focus on the CSP’s infrastructure
and these platforms tend to present things in a more concrete manner. As
one moves up the diagram, the focus changes to the customer and things
are represented more abstractly.
• Platform integration is simpler than the current approach since common
APIs and base information models are used across all the platforms.
Software suppliers (including in-house to the CSP) can focus on one
foundational platform and then specialize the foundational platform based
on the particular things that are to be managed.
© The Art of Managing Things 25

26. • Commercial Viewpoint
• Customer-focused
• High-level of Abstraction
• End-to-End / Aggregated
View
• Infrastructural Viewpoint
• Single Domain
• Internally-focused
• Lower-level of Abstraction
• Localized View
• Functional Viewpoint
• Progression from Internal
to External Focus
• Single or Multi-Domain
• Composition of
Components
• Moderate-level of
Abstraction
Platform
Platform
Platform
Platform
Platform
Platform
Platform
Platform
Platform
Platform
Platform
Figure 8. Platform Dependencies - not Layers
© The Art of Managing Things 26

27. References
1. Fratini, S. The Art of Managing Things, Amazon,
https://www.amazon.com/dp/B07N4H4YWH.
2. MEF 50.1, MEF Services Lifecycle Process Flows, MEF.
3. GB922 Product, R18.5.0, TM Forum.
4. GB922 Logical and Compound Resource, R18.5.0, TM Forum.
5. GB922 Service Overview, R18.5.0, TM Forum.
© The Art of Managing Things 27