< Take me to Contents

A WHITEPAPER ON

software
marketplaces
A new go
to market
IG1262 opportunity for
29 JULY 2021 communications
service providers

OBJECTIVE(S): This whitepaper aims to evaluate the role of software

marketplaces in the growth of new business opportunities by
communications service providers (CSP) in going beyond traditional
connectivity offerings to provide insights that will help demystify a
software marketplace strategy and approach to the realization of that
strategy. The paper builds upon insights from many companies and
TM Forum Catalyst projects. The paper aims to help CSPs design and
build their marketplace strategy and implementation plan where they
have selected to build their own marketplace.
< Back to Contents

contents PAGE

3 1 Introduction and vision

6 2 Type 2 digital marketplace insights from TM Forum’s
Digital Business Marketplace (DBM) Catalyst
10 3
Type 2 digital marketplaces, business model evolution from
TM Forum’s Developer is King! Catalyst
12 4 Virtual network functions (VNF) marketplaces as an early
example of software marketplaces
12 4.1 Main motivations and key drivers
13 4.2 Governance and operational requirements of
VNF Catalogs Federation and VNF Yellow Pages /
ZOOM Dynamic VNF Catalog
14 5 Scope
14 5.1 Target audience and partners
15 5.2 Business models
21 6 Reference architecture
22 6.1 Engagement management
22 6.2 Decoupling and integration
23 6.3 Party management
23 6.4 Core commerce management
24 6.5 Intelligence management
24 6.6 Enabler eervices
24 6.7 Capability variation between type 1 and type 2 marketplaces
26 7 Launching a marketplace
27 8 Conclusion
28 9 Administrative appendix
28 9.1 Document history
28 9.1.1 Version history
28 9.1.2 Release history
28 9.2 Acknowledgments
29 10 Use cases
31 11 Developer is King! Catalyst: Business model evolution
33 12 Federated dynamic NFV catalogs with diagram
34 13 Digital Business Marketplace Catalyst:
Use case and business impacts

© TM Forum 2021. The entire contents of this publication are protected by copyright.
All rights reserved. The views and opinions expressed in this white paper are provided in the
contributors’ personal capacities and may not reflect the views of their companies. While all
care has been taken in preparation of this paper, no responsibility for any loss occasioned to
any person acting or refraining from any action as a result of any material in this publication
can be accepted by the editors, contributors or publisher.
2
< Back to Contents

1. Introduction and vision

Marketplaces have been in use in many forms, such as in town centers, with stalls and goods
laid out for consumers to view and buy, for thousands of years. With probably the most
famous modern-day marketplaces replicating a similar format, anyone who has purchased
online is almost certainly familiar with choosing from an array of options available in the
massive online catalogs of the digital platform players, such as Amazon, eBay, etc.
From a consumer perspective, one could conclude that the needs of today’s consumers of a
marketplace are well-met by the online offerings (as Amazon’s success demonstrates) – and
to a certain extent, some needs of the business world are also met by similar marketplace
capabilities.
Marketplaces for business, enterprise, and government purchasing patterns need to
contemplate a range of buying and negotiation scenarios across bulk, fleet, multi-geography,
language, currency-type, products and services, physical and virtual purchases. These
include technically dependent choices often sourced from organizations resulting in a range
of contexts and engagement processes. Aggregating these inputs and many more inform
the needs for a very different marketplace approach and capability.
From a CSP perspective, engagement in a software marketplace is imperative since many
of the functions and facilities currently used in telecommunication networks, products,
and services are progressively moving from hardware-defined devices to software-defined
services. Furthermore, these services run on agnostic devices managed from the cloud
(whether public or private cloud; hyperscaler or CSP cloud infrastructure). The CSPs, the
suppliers, and the overall community need to contemplate how to handle this paradigm shift,
which requires seamless partnering, orchestration, and monetization. The many industries
that want to benefit from the rapid evolution of technologies can purchase and deploy
solutions quickly.
Therefore, the vision for the software marketplace needs to consider a range of aspects.
In particular, given the range of hyper-scale cloud and software players, global IT players,
and other opensource communities which have come to dominate and crowd the software
market, defining the objectives and context are even more important. In addition, defining
what constitutes existing software marketplaces would assist in determining an extended
vision, keeping in mind that AWS (Amazon Web Services) and others such as Azure, Google,
Oracle, IBM, etc., could also, perhaps, be part of the software marketplace.
We have defined two types of software marketplaces and will refer to them as type 1 and
type 2.

TYPE 1 MARKETPLACES
Type 1 marketplaces, also known as ‘controlled ecosystems’ are designed to facilitate
partnering from the outset. Here, the marketplace owner controls the ecosystem and
captures most of the value created. The partners are generally suppliers of the ecosystem
owner, and the ecosystem owner exposes the suppliers’ offerings for consumers to purchase.

REVENUE GROWTH

Figure 1: Type 1 marketplace

(digital platform business model)

3
< Back to Contents | 1. Introduction and vision

The digital platform business model illustration above shows an organization using a digital
platform designed to attract both partners and customers in an ever-accelerating flywheel
cycle. The flywheel accelerates revenues and lowers costs.

This paper recognizes the existence of type 1 marketplaces and considers the future of
software marketplace needs and the differentiation to type 1 marketplaces of today. The
book, Platform Revolution: How Networked Markets Are Transforming the Economy - And
How to Make Them Work for You (Parker et al., 2016) provides an excellent primer to what
makes a good platform and how great companies create and harness the network effects
that help them.

One limiting factor of type 1 marketplaces identified is the inability to automate the
combinations and orchestration of offerings from and between supplying organizations.
Offerings are considered an essential capability in the future of software marketplaces
to enable said partnering and combinations of offerings between organizations. The
capability is identified in the industry as a type 2 marketplace and would require additional
functionality explored in this paper.

TYPE 2 MARKETPLACES
The type 2 marketplace, also known as an ‘open business’ marketplace, is a ‘platform
enabling platform’ designed to allow organizations to operate independently and choose
which other organizations can cross-sell their products and services, leveraging plug and
play and frictionless trading. The type 2 marketplace capability enables each organization
to combine both their own and other offerings provided to them and choose yet another
organization to partner with, who can repeat the pattern with others to deliver a solution,
creating a new horizontal and vertical network effect. This marketplace is service and
technology agnostic, enabling any organization from any industry to participate. It operates
in real-time, not just from a partner-solution-delivery perspective, but also in life. A curator
manages the platform but does not control it.

FRICTIONLESS TRADING ENABLED BY SID, APIS AND DSE EXTENTION

Figure 2: Type 2 marketplace

(Open business marketplace)

In anticipation of this type 2 definition, Geoffrey Parker, Professor of Engineering at

Dartmouth College, Fellow at the MIT Initiative on the Digital Economy and author of
“Platform Revolution” predicted that the digital platforms approach would gradually be
adopted by traditional businesses: “Firms are likely to deploy ‘platform enabling platform’
technologies that help to create horizontal linkages across their vertical businesses. We can
expect to see more and more businesses adopting such technology as they seek to digitize
their global business operations.”

4
< Back to Contents | 2. Introduction and vision

The TM Forum Catalyst, Digital Business Marketplace, has explored the operational
implications of a type 2 marketplace:

Type 2 marketplaces, also known as ‘open business marketplaces’ are designed to enable any
organization to run their own business and simultaneously choose their reselling partners.
Type 2 allows each organization to onboard its products and services. Just as in business
today, type 2 enables an organization (call it Org-A) to sell its own products and services
to customers and allows Org-A to choose which other organizations to extend its offerings
to in the future. Another organization, Org-B, consumes and packages Org-offerings for
resale. When Org-B sells their offerings, the supplying partner (Org-A) will automatically be
orchestrated to fulfill for the end customer (even though the supplying partner (Org-A) may
not know the end customer). This functionality enables organizations to offer and cross-sell
each other’s products and services, but only when the supplying organization (Org-A) has
expressly agreed to supply their offerings to another party (e.g. Org-B) for said organization
to consume, package and on-sell. This type 2, open business marketplace, goes to the next
level as it enables the receiving organization (Org-B) to package an offering to another
chosen partner (Org-C) so that that chosen partner (Org-C) may combine and package
the offerings (from Org-B and Org-A) with their own offerings. A customer is able to add
all offerings to their shopping cart and all the partnered organizations (Orgs-A, B & C) can
automatically deliver that offering to the customer. Org-A and Org-B progressively billing
each other, and Org-C automatically billing the customer for the complete solution.

Therefore, each organization in a type 2 marketplace is a curator of offerings, including

their own products and services and additionally offerings specifically and intentionally
made available to them from supplying partners. This provides the recipient organizations
with the opportunity to package combination offerings, as explained in the above example.
It is important to note that no organization controls another organization in a type 2
marketplace.

For further insights and comparisons of type 1 and type 2 marketplaces, see Capability
variation between type 1 and type 2 marketplaces.

In defining the strategy for software marketplaces, a recent research report and survey by
TM Forum found that the most important consideration by both communication service
providers (CSPs) and vendors was retaining the customer relationship. Here, over 70% of
both CSPs and vendors felt that the marketplace was either a CSP-directed marketplace
or an independent third party. There was, however, a clear lack of support for leveraging
the hyperscaler marketplace. What will be important to understand is the audience.
Considering physical marketplaces of old, the grandest of them all attracted the most
vendors due to guaranteed high footfall. Likewise, when assessing the right marketplace
strategy, the first consideration is a) who the target customer is; and b) where the highest
volume of those customers can be accessed.

A CSP-operated, digital self-service portal

WHAT IS MARKETPLACE? for buying and bundling services from a
single CSP and its ecosystem partners;
CSP owns the customer

A place where CSPs can procure ODA-

compliant components for building their
software infrastructure
5% 6% A digital self-service portal hosted by a
6% 6.5% neutral, third-party marketplace provider
3.5% through which multiple CSPs and
27% ecosystem partners can offer connectivity,
6.5% comms-related services, apps, devices and
content; no single CSP or partner owns the
40% company

A digital self-service portal hosted by a

CSPs Suppliers hyperscale cloud provider through which
multiple CSPs and ecosystem partners can
offer connectivity, comms-related services,
apps, devices and content; platform
35%
8% provider owns the customer

A hub where operators that are part of a

large telecoms group can provide services
to each other

10.5% 46% Other

Figure: 3 TM Forum survey

response

5
< Back to Contents

2. Type 2 digital marketplace insights

from TM Forum’s Digital Business
Marketplace (DBM) Catalyst

The focus of the DBM Catalyst is to simplify, enable and monetize multi-partner sourced,
highly complex solutions for both industry 4.0 and the smart industry, making it easy for
customers to buy and manage their offerings.

The approach leverages TM Forum SID and Open APIs and is articulated as an ODA DSE
(digital services enabler) extension.

The Catalyst project includes a broad range of companies offering a diverse set of expertise
and capabilities spanning deep vertical industry requirements (e.g. manufacturing, mining,
electricity, building & city management, entertainment, etc.), plus companies with deep
horizontal capabilities across security, IT, communications, network operations, compute,
DLT, AI, digital twins and more.

CHAMPIONS PARTICIPANTS

The Catalyst team identified that most vertical industry scenarios need a range of underlying Figure 4: TM Forum Catalyst
core capabilities, such as secure IoT, 5G, compute at the edge onto which industry-specific members: DBM Phase 3
control systems, AI and Digital Twins are deployed to deliver industry 4.0 and smart-X
capabilities. Additionally, the use of DLT was explored and confirmed to enable transactions
where no trusted relationship between players (yet) exists.

The traditional approach to delivering industry 4.0 and smart industry requirements is
to assemble an expert team from multiple companies and run engineering project(s)
incorporating numerous components from various parties as part of an overarching digital
transformation strategy.

6
< Back to Contents | 2. Type 2 Digital Marketplace insights from TM Forum’s Digital Business
Marketplace (DBM) Catalyst

INDUSTRY 4.0 SOLUTIONS FOR VERTICAL INDUSTRIES NEED A RANGE OF VERTICAL SPECIFIC PRODUCTS,
SERVICES AND SYSTEMS – TIL NOW, A PROJECT WITH MULTIPLE COMPANIES

But, for example, to deliver a smart grid overlay, abstraction, and orchestration for 255,000 Figure 5: Industry 4.0:
substations as projects in the US alone will probably take 40 to 50 years. projects or solutions

Type 1 digital marketplace offerings can be deployed within projects. Still, more often
than not, the techniques to consume cloud-based software offerings are not supported
with an in-life management capability, partly because there is no concept and realization
of frictionless trading. Also, type 1 digital marketplaces are designed with proprietary
standards rather than open standards such as TM Forum’s SID and Open APIs. They,
therefore, cannot easily offer a repeatable B2B2X capability.

There are thousands of organizations involved in bespoke and often insecure industry
4.0 and smart x projects across all industries. Robots deployed by projects are usually
susceptible to cyber-attacks and when they become malware-infected, have been known to Figure 6: Industry 4.0
destroy factories. However, this is just the ‘tip-of-the-iceberg;’ a better approach is required. fragmented projects

WITHOUT DBM – FRAGMENTED VALUE CHAINS, INTEGRATION CHALLENGES

7
< Back to Contents | 2. Type 2 Digital Marketplace insights from TM Forum’s Digital Business
Marketplace (DBM) Catalyst

To resolve the multiple issues associated with the manual project approach, automation is
required. The required automated approach would enable thousands of organizations to
seamlessly partner together within a plug and play, frictionless-trading business ecosystem.
This would allow participants in the ecosystem to extend their product and service offerings,
and combinations of such, so that the offerings can be selected, purchased and self-service-
managed by the customer, as secure scalable solutions.

The DBM capability enables companies who are already suppliers to project-based delivery
to leverage a type 2 marketplace capability. Each company can trade frictionlessly with their
chosen partner organizations to deliver seamless zero-touch solutions to their customers,
with the capabilities to define highly complex technical dependency and business rule-driven
offerings and can be done with the confidence that each organization will be able to bill
automatically and granularly for the consumption of services.

DBM III – A FRICTIONLESS BUSINESS PARTNER ECOSYSTEM

This move from a project approach to a DBM solutions capability approach converts single- Figure 7: Industry 4.0: DBM
layer deep manual project activities between organizations into a fabric of participating frictionless solutions
partners enabling solutions. Each organization uses a type 2 marketplace capability. Each
organization can select which partner will receive their specific offerings so that when a
customer purchases a solution, the order ripples through all the type 2 marketplace-enabled
partners who have committed to support with their specific offers for that particular
solution.

In comparison with the projects scenario, in this solutions approach, a type 1 digital
marketplace offering can be easily consumed and orchestrated by any organization which
uses a type 2 digital marketplace to offer industry 4.0 and smart x solutions. In addition,
the type 2 digital marketplace capabilities enable the organization to quickly onboard and
enable the bundling and combinations of type 1 offerings into B2B2B2x outcomes because
the type 2 platform uses TM Forum ODA DSE open standards such as SID and Open APIs.

The TM Forum ODA DSE standards-based DBM enables an organization’s shopping cart to
include various solutions. Depending on what the product manager of the customer-facing
entity has deemed as an appropriate set of offerings, the relevant options will then allow the
customer to select and activate orders with the right partners automatically.

8
< Back to Contents | 2. Type 2 Digital Marketplace insights from TM Forum’s Digital Business
Marketplace (DBM) Catalyst

PLUG & PLAY SECURE SUPPLY CHAIN: ZT FROM SHOPPING CART TO ACTIVATION & MONETISATION

The type 2 digital marketplace enables each organization’s product manager to define the Figure 8: DBM: enabling each
technical dependency and business rules for offerings that support the capabilities of ‘mass organization to operate with their
customization’ via configuration, leveraging a SID-based catalog (product/service/resource) own type 2 marketplace
which can aggregate and bundle hundreds of partners (pre-defined and exposed in the
shopping cart according to the product manager’s definition). This enables the organization
to partner automatically across all ecosystem partner members – delivering the solution
on-site, zero-touch, right from selection in the shopping cart, through to activation with no
insecure sharing of passwords and no manual actions (apart from deploying devices and
turning on the power).

The type 2 digital marketplace enables each organization to have an automated

orchestration of their end-to-end commercial processes and profit & loss, spanning from a
catalog-driven shopping cart through to customer management, order orchestration, billing
management, as well as collections, including automated ‘moves, adds, changes, and deletes’
so that each organization can automate the decision about what to offer a customer in
the shopping cart based on the customer’s payment history, location or account/channel/
corporation alignment.

The impact of the DBM capabilities leveraging a type 2 digital marketplace converting
projects into versatile, highly repeatable solutions is a game-changer for highly complex
industry 4.0 and smart x requirements. Furthermore, it illustrates how simple ecosystem
partnering can leverage the same TM Forum ODA DSE techniques.

For more information on the benefits and impacts of the type 2 marketplace capabilities
illustrated in TM Forum’s Digital Business Marketplace Catalyst, please see the appendix.

9
< Back to Contents

3. Type 2 digital marketplaces, business

model evolution from TM Forum’s
Developer is King! Catalyst

The focus of the Developer is King! Catalyst project shifts the spotlight to the developers,
an overlooked area in the ecosystem but one with lots of opportunities in the evolving
eco system business models between operators, partners and developers (can be system
integrators, ISVs, internal CSP developers, ..) and software marketplace drive.

CHAMPIONS

PARTICIPANTS

Beyond the network evolution and digital transformation, to complete the story of 5G Figure 9: TM Forum Catalyst
enablement is to look at the developers whom operators depend on to provide compelling Team: Developer is King!
applications to the latter’s customers, including vertical industry platforms and solutions.
By addressing the developers’ needs, the operator would benefit as well since time-to-
market and cost to introduce such new applications would ideally be reduced tremendously.
Operators could also attract developers to co-create compelling applications that are easily
portable especially if the operators are running business operations in multiple geographies.

It bridges providing more capabilities to enhance the vertical industry specific solutions that
can bundle telco services for e.g., QoS upgrade on the fly. This requires telco capabilities (e.g.,
telco APIs, software components, applications, platforms, test bed, ...) to be made available for
developer or software solution provider ecosystems and vertical industry players.

As part of this Catalyst, a remote education solution enabled by 5G and edge, which is
very relevant in the current pandemic situation is considered. Scenarios like live streaming
of expert sessions to remote students, AR / VR for explaining concepts, content caching,
chats, remote collaboration, gamification, e2e QoE / QoS for end users which can be
supported by network exposure capabilities like location, geo-fencing, QoS upgrade,
eMBB slice and many more.

DEVELOPER IS KING! EVOLVING BUSINESS ECO SYSTEMS, MARKET PLACE. USE CASE: REMOTE EDUCATION

Figure 10: Evolving Business

Eco System, Market Place
10
< Back to Contents | 3. Type 2 digital marketplaces, business model evolution from TM Forum’s
Developer is King! Catalyst

In the traditional education industry model, developer or ISV ecosystem provides solutions
to education Institute directly (D2C model). In this context

1 For student, faculty engagements, namely

Institute for enrollment, kearning, complete life cycle

CSP for connectivity

are independent events

2 Developers / ISVs independently developed applications & platforms

Evolving collaboration brings all the stakeholders together to give the business customers
(in this case educational institute) and end users (like teachers, students, ..), bundled
offerings, enhanced experience, insights, digital drive and creates new business models,
monetization mechanism. This in-turn helps developer to bring in a very robust integrated
solution, leveraging capabilities from varied ecosystem players, be part of the new model.

Developer utilizes CSPs, partners and hyperscaler APIs, capabilities, platforms for building
enhanced solutions for Educational Industry (B2P2D model)

Education Institute buys the bundled solution from market place (B2B2X model)

In the evolved model B2B2X, we are looking at a bundled solution for the education industry;
bring in telco capabilities and others to get integrated.

CSP exposes their network and other capabilities through APIs, like network QoS upgrade,
network slices, location, geo-fencing, charging party change, edge services and many more.
Along with hyperscaler APIs, developer ecosystem has a suite of capabilities to build robust
platform. In this model, student, faculty engagements can happen seamlessly with enhanced
experience bundled.

11
< Back to Contents

4. Virtual network functions (VNF)

marketplaces as an early example
of software marketplaces

4.1 MAIN MOTIVATIONS AND KEY DRIVERS

While the aforementioned solution-oriented flavor of built-out software marketplaces are
gaining considerable traction within the telecommunications industry and across vertical
industries today, marketplaces have already been considered in earlier work at TM Forum,
notably in the ZOOM project as part of OSS/BSS Futures Framework before the onset of
Open Digital Architecture (ODA).

The VNF marketplace concept was introduced to TM Forum in 2014 via the ZOOM / OLM
(Automated Onboarding Life Cycle Management of VNFs) project to help CSPs and their
suppliers in the process of procurement transformation by leveraging a CSP’s real case study
(Orange’s case study) through the ‘Federated Catalogs for (Automated) VNF Procurement’
instrument.

The main driver for the time pressure of the telecom industry is ‘softwarization’ of network
and systems e.g. cloud virtualization, VNF and evolved BSS/OSS. In response, TM Forum
initiated the Procurement Survival Kit project which produced the following documents in
2015:

IG1133A NFV Procurement Professionals’ Briefing (Flyer) R15.0.1

IG1133B NFV Procurement Survival Kit Overview R15.0.1

IG1133C Federated Catalogs for (Automated) Procurement – Orange Case Study R15.0.1

This Procurement Survival Kit addresses strategic procurement transformation objectives at

the telecom industry board level, including:

AGILITY: Create agile procurement to support internal product development and

operation process

SUPPORT SOFTWARIZATION AND VIRTUALIZATION: Leverage best practice for cloud

procurement of commodity computing and storage platform and add deltas for support of
virtualized network function procurement

ECOSYSTEM: Moving from a per-procurement model for each supplier to a set of unified
models for all trusted partners

CULTURE CHANGES: Governance that links to development and operations, people and
skills change.

Indeed, virtualization (desegregation) requires a complex ecosystem integration and

catalogs play a significant role in facilitating dynamic relationships between participant
suppliers and partners. Virtualization with its flexibility characteristics along with DevOps
and continuous integration will impact the procurement and sourcing model by moving from
a buyer-seller segmentation model towards more integrated supply networks governed by
dynamic VNF products federated catalogs.

12
< Back to Contents | 4. Virtual network functions (VNF) marketplaces as an early example of
software marketplaces

4.2 GOVERNANCE AND OPERATIONAL REQUIREMENTS OF VNF

CATALOGS FEDERATION AND VNF YELLOW PAGES / ZOOM
DYNAMIC VNF CATALOG
There may be questions raised pertaining to the governance of the CSP’s dynamic NFV
catalog within its federated catalog ecosystem. Is it considered an NFV Broker with a rights,
duties and responsibilities demarcation attached to the brokering model?

The NFV Yellow Pages / ZOOM Dynamic NFV Catalog of 2015 presented the following
questions and from their respective answers we can derive requirements from various
perspectives, captured and described in the table below. These questions are also relevant to
the software marketplace specification later presented in this paper.

TYPE OF PERSPECTIVE KEY QUESTIONS RELATING TO THE PERSPECTIVE

1. • Who implements the technical platform (which standard or

Technical proprietary platform)?
• Who maintains (provision, populate, update) this tool?
• Who promotes it (portal, branding)?

2. • Should this platform be hosted by a CSP, a dedicated SDO

Administrative, or by a dedicated Industry forum?
legal and regulatory
• TM Forum could be a candidate at least to its members but,
openness to non-members will be mandatory.

3. • Terms of Conditions (ToC)?

Financial and
commercial • Contract, SLAs, charging, billing, pricing?
• Other added value services might be offered and under
which commercial conditions?

4. • How to discover, access, authenticate this NFV marketplace?

Usability
• Avoid to building a huge and complex machinery rather to
make a light tool, friendly and easily accessible.

Please note that the discussion of VNF marketplaces is only a subset of the reality of
the type 1 and type 2 marketplaces of today. This is because the offers to enterprise and
SME customers are now way beyond the network-services focus of ZOOM and comprise
solutions spanning IT services of all kinds, combined with the joined-up portfolios of a broad
landscape of delivery partners, CSP and otherwise. Considering this, it is vital to now explore
as part of this paper, target audience and partners, market segments and business models.

13
< Back to Contents

5. Scope

5.1 TARGET AUDIENCE & PARTNERS

Marketplace customers can be broadly categorized into four main segments, as per the
figure below. Considerations on the customer’s organization size, operating structure
complexity, IT skill level of staff and software procurement procedures must be made
to facilitate the successful provision of software and connectivity solutions from the
marketplace.

The single factor that has not been taken in to consideration in the illustration below is the
spending power, which if applied would inverse the pyramid from top to bottom.

LARGE
PRODUCTION

MEDIUM BUSINESS

SMALL & MEDIUM ENTERPRISE (SME)

OR SMALL OFFICE/HOME OFFICE

RETAIL CUSTOMERS (B2C)

Fig 11: Marketplace customer
segments

At the very pinnacle of the pyramid are the large enterprises (LEs) with a 1000 or more
employees; these organizations often provide very high revenue for CSPs. Typically, LEs
are complex organizations with their own broadly skilled full-time IT staff, including a few
industry specialists. LEs have considerable IT expenditure and consider metrics such as
business up-time security and other advanced features. CSPs and mobile virtual network
operators (MVNOs) both reap benefits from marketplaces by becoming customers
themselves at the top of above pyramid. The reason for this is that CSPs and MVNOs gain
access to a wide array of services offered through software marketplaces, a benefit which
is further exemplified when different marketplaces begin to interact with each other and
integrate. Industry 4.0 companies are also placed in this at the top of the pyramid above,
in the LE segment, and potentially offer CSPs the best opportunity to serve beyond
connectivity. Key opportunities exist in manufacturing and automation where ultra-
reliable, low latency networks allow autonomous systems, computer vision-based quality
controls, augmented reality applications and real-time process controlling. CSPs also get an
opportunity to build and operate private networks used for vertical platforms on behalf of
these industry 4.0 companies, which could provide true, accelerated revenue prospects.

Medium-sized businesses typically have 100-500 employees with either their own smaller
IT teams, which typically lack specialist skills; specialist requirements are often outsourced
on an adhoc basis. Although capital expenditure (CapEx) may be less in comparison to that
of LEs, employees of medium-sized businesses are likely to be dispersed across multiple
locations, typically requiring connectivity and mobility solutions. Medium-sized businesses’
main considerations for technology are automation, reporting and applications that improve
workforce productivity.

Organizations with fewer than 100 employees are categorized as small and medium-sized
enterprises (SMEs). Within the same segment are small office or home office (SOHO)
businesses, which employ fewer than 10 people. This segment, as per the pyramid above,
typically has very limited CapEx. SMEs and SOHOs predominantly have few IT staff, who
tend to be unspecialized and learn on the job.
14
< Back to Contents | 5. Scope

The majority of organizations within this segment work from a single location, though
some have outsourced remote workers who perform select functions which pose good
opportunities for connectivity solutions. For these companies, two main factors for
technology considerations are ease of use and price. The former is due to the lack of strong
IT teams whilst the latter is due to limited CapEx, which in turn encourages the preference of
pay-per-use or pay-as-you-go models.

At the bottom of the pyramid are retail or end-consumers who often consume software and
connectivity services on individual devices. These devices are typically serviced through
CSPs or through the device manufacturer’s own application stores and marketplaces.
Technology is, primarily, a supporting factor for retail and end-consumers. This segment
requires access to communication and social interaction tools and education and lifestyle
services, with quality of content, ease of consumption and integrated payment methods
being key drivers of usage.

There are many partners or actors who are brought together in a marketplace ecosystem
to serve the above segments. Some of the most notable players are led by the platform
providers themselves who create the ecosystem where multiple players can publish their
service catalogs, orchestrate multiple physical and logical services and monetize by offering
the solution capability to any of the segments discussed. The CSP could also play this
platform owner role and/or provide network capability to other marketplaces.

Other actors contributing to success of software marketplaces are the service, software
and content providers offering their services through the marketplace: service integrators
who play the customizing and integration role at the customer end; support providers
who act as the first line of defense once services go live and encounter service outages;
payment gateways or payment aggregators who provide the vital means of monetizing all
the services rendered; resellers who typically act as a sales channel to reach out to suitable
customer segments for a profit share; Independent developers who most often offer services
to the bottom of the pyramid; service enablers who provide the analytics for data either of
the services on the marketplace or from external sources, and mapping or data visualizing
experts to better consume complex data points.

The creation of services, offering to customers and monetization of efforts become

progressively more complex with the increase in the number of actors involved. This requires
complex partnership and collaboration methods, varied revenue models and probable
business models to share the revenues generated through the marketplace.

5.2 BUSINESS MODELS

Serving a wider customer-base across multiple vertical industries has been largely made
possible by the adoption of marketplaces as a business channel. Enterprises across all
verticals are taking up the digital transformation journey and software services play a pivotal
role to accelerate this transformation. It is important that digital enabler pillars such as CSPs,
hyperscale cloud providers (HCPs) and software vendors, to name a few, should leverage
the trust built over a period within the partners ecosystem and offer unified services via the
software marketplaces.

Digital enablers need to expand horizons by moving beyond traditional connectivity and
data services offering towards ‘softwarized’ vertical services. This can be done by leveraging
a strong partnership ecosystem and looking towards the software marketplace as a means
to stay relevant in an increasingly competitive market, thereby removing boundaries and
acquiring sustainable revenue growth.

CUSTOMER SELLERS

More products on Higher the number of Figure 12: A successful

marketplace brings sellers, more products marketplace
more customers on and services available
marketplace on marketplace
PRODUCTS
& SERVICES

15
< Back to Contents | 5. Scope

Like any other marketplace, the evolution and maturity of the software marketplace platform
will drive the value realization for the provider, their partners, and customers. The growth
and success of the marketplace platform is driven by the value it brings to all the involved
stakeholders and will be quantified not just by the sales volume but by the level of reach to
the customers and trust of partners.

With the move towards softwarization of every service, a software marketplace platform
has the potential to evolve from a place of buying and selling services to becoming a closely
integrated partner ecosystem with unified offerings. While we intend to explore business
model options for the software marketplace platform, it is equally important to consider
different collaboration options within the marketplace. This is brought in by introducing new
services, plug and play setup for partner ecosystem and the ability to attract startups and
well-established service providers to the platform.

The marketplace actors can choose to leverage any of the collaboration options for their
service offering as per their business needs.

For example, a seller can choose to leverage the data insights from the marketplace platform
but may opt out of the enabling services like the payment gateway, SCM.

On the other hand, another seller may collaborate on the platform by using just enabling
services and not opt in for data insights.

VARIED SERVICE OFFERING OPTIONS ON MARKETPLACE

A B C D
Platform Enabling Services Data Insights Partner Ecosystem

Software supplier offers a
Marketplace Platform where
the sellers can sell their
products either directly or as
a reseller
Marketplace provider offers
enabling services like Payment
gateway distribution network,
supply chain management
advertising and marketing,
infrastructure service etc.
Marketplace provider provides
insights for personalized and
targeted selling which will
act as a boost to sellers on
marketplace.
Marketplace provider
establishes partner ecosystem
with other service providers
to jointly address customer
needs, end to end. Partners
will agree on revenue share
and settlement.

A
VARIOUS COLLABORATION OPTIONS

Partners on the Marketplace platform have A B

multiple collaboration options which can
be utilized as individual lego blocks based A C
on business needs. With the platform (A)
as the consistent entity, we can derive an A B C
exteneded collaboration matrix depending
on the capabilities/services being offered
on the platform. Few illustratiive examples
A C D
given here:
A B C D

The marketplace ecosystem governs the adaption of different innovative business models Figure 13: Marketplace -
that can be possible for a software marketplace. The marketplace business models should illustrative collaboration options
introduce flexibility to ensure the partners can reap the benefits of every sale without
compromising on the operating margins. The different business models are depicted in
the Figure 3.

MARKETPLACE PARTNERSHIP MODELS

Figure 14: Business

B2P: Purchaser B2D2C: Distributer BG2C: Sell with B2D2C: Integrator A2E2B: Ecosystem transaction models
(direct sell) (sell through/resell) (co-ell) (joint sell) enabler

16
< Back to Contents | 5. Scope

BUSINESS MODEL EXPLANATION EXAMPLE

B2P: Purchaser The manufacturer or product provider sells the A seller selling a mobile accessory directly to the
(direct sell) products directly and uses the marketplace customer on the marketplace platform
platform as a medium to sell their products to the
consumers

B2D2C: Distributor The distributor sells services from one business A manufacturer does not sell their accessories
provider to a customer. directly to the consumer. Instead, another seller
(sell-through/ white labels the accessories and onward-sells to the
re-sell) The role of distributor is sometimes called sell- customer on the marketplace platform
through or resell.

Often a supplier will sell through many distributors

and/or a distributor will distribute goods from
many suppliers.

BG2C: Sell-with Two businesses, Org-B and Org-G, join forces to
sell a single combined service to the customer.
(co-sell) Org-B and Org-G provide complementary services,
service-S and service-T. Both Org-B and Org-G
have both direct relationships as well as separate
contracts with the customer.
In the case of Org-G playing prime for integrating
the services and bundles Org-B services as pass
through in their books, then the model becomes
B2G2C.
A seller selling a mobile handset also sells the
accessories provided by another supplier together to
the customer on the marketplace platform.
An ISV and SI providing joint integrated solution to
a CSP client. The CSP has separate contracts with
both. Both the ISV and the SI have direct client
relationships.
On the other hand, the CSP pays the SI and the ISV
charges are pass through the SI’s books. In this case,
the SI has a direct relationship. The ISV may or may
not have a direct relationship with the customer,
depending on how the overall solution is taken up.

B2G2C: Integrator A business sells services to an integrator business. An IoT product offering where sensors are provided
The integrator combines these services with by one seller and software is provided by another
(joint sell) further services and sells them on to the end seller
customer.

A2E2B: Ecosystem The ecosystem enabler “E” contracts with A CSP contracts with the internet security business
Enabler different businesses, “A” and provides services and provides the internet security licenses to other
to other businesses “B”. This contractual role of businesses. In this case, the CSP is the ecosystem
the ecosystem enabler “E” is just a part of its role. enabler.
Ecosystem enabler “E” may also provide a rich
set of operational tools, processes, and APIs to
facilitate the businesses of both A and B. This is
the justification for the grand term: ecosystem.

A2E2B: Ecosystem Enabler – The ecosystem enabler “E” contracts with different businesses,
“A” and provides services to other businesses “B”. This contractual role of the ecosystem
enabler “E” is just a part of its role. Ecosystem enabler “E” may also provide a rich set of
operational tools, processes, and APIs to facilitate the businesses of both A and B. This is
the justification for the grand term: ecosystem. A CSP contracts with the internet security
business and provides the internet security licenses to other businesses. In this case, the CSP
is the ecosystem enabler.

In a type 1 marketplace, and across different business models, the provider has the control
to decide who can sell, what can be sold and what can be joint offerings on the platform.
The provider, hence, controls the value generated from the platform. From the end-customer
perspective, the marketplace provider is their point of contact.

However, in a type 2 marketplace, there is significant flexibility among the partners/sellers

to curate new service offerings on the platform. Multiple sellers have the flexibility to decide
who they want to partner with and combine their offerings together such that they reap
the maximum value for their businesses. Whilst the marketplace provider gets their share of
benefits based on platform usage and revenue models, the sellers/partners benefit from the
variety of business models at their disposal as a result of the open ecosystem provided by
the type 2 marketplace.

17
< Back to Contents | 5. Scope

Looking at the business models from a customer segmentation point of view, while the
business models depict the various ways in which partners can collaborate to build, offer
and sell services, there is no direct linkage between the business models and the type of
customer/ segments which can be served. Different business models can be used to serve
across multiple customer segments. However, based on various factors like the type of
services offered, spending power of partners, customer reach, etc., it can be widely seen that
there is a high prospect of serving the retail customer segment using the direct selling (B2P)
business model. For SOHO/SME the models like re-sell (B2D2C)/co-sell (B2G2C) deliver
varied services and large enterprises can extensively leverage the partnership ecosystem
(B2G2C).

Depending on the customer segments being served and the business model being adopted,
the marketplace needs to define different monetization models to realize benefits for
everyone involved. These business models can be monetized by leveraging the benefits
offered by various monetization models. Figure 4 depicts the different monetization models
that can be used.

MARKETPLACE REVENUE MODELS

TRANSACTION FEE BASED REVENUE/PROFIT

BASED MODEL MODEL SHARE MODEL

Transaction based Recurring fee based Marketplace partner

commission model sharing the revenue
based on unified
Pay per use of Onboarding fee service offering
marketplace provided to customer
subscription Marketplace service
subscription
Service listing fee
Figure 15: Monetization models

MONETIZATION MODEL EXPLANATION EXAMPLE

1. • The CSP does not just provide the platform
Revenue/ profit share to host the products and services for buyers
model and sellers but also provides integrated
services jointly with multiple partners on
the marketplace, thus leveraging a partner
ecosystem.
A CSP offering managed and professional
services to the customer along with the IT
systems (like customer-provided equipment,
CPEs) in partnership with the vendors.

• Customer receives end-to-end service in one

place.

• CSPs can increase their revenue with pre-agreed

contracts

• This model is an enabler for start-ups to play

a role with large CSPs in enterprise solution
offerings

18
< Back to Contents | 5. Scope

MONETIZATION MODEL EXPLANATION EXAMPLE

2. The marketplace provider allows sellers and other
Fee based model enterprises to utilize the marketplace platform
with pre-defined fees.
The fee-based model provides flexibility for the
marketplace to charge different sellers based on
their product types and maturity of seller. The
marketplace provider can decide the fee value
based on multiple factors and if needed can even
reduce it to nil, in the interest of business.
Below are examples of types of fees:
An OTT (over-the-top) player selling their
product subscription over the marketplace
platform and pays a fixed recurring fee for
hosting their products on the marketplace
platform.
A seller CSP selling mobile subscriptions
and uses the payment gateway service and
supply chain management service for SIM card
delivery. For each of the services, the CSP
seller pays a service-based charge.

A) RECURRING FEE – The marketplace provider

receives fixed revenue irrespective of sales by the
seller. The seller pays a fixed recurring fee. This
model is beneficial to sellers with high sales as
they pay a fixed price.

B) ONBOARDING FEE – Once the marketplace

is well-established in the industry and has a high
number of customers, it can consider charging a
one-time onboarding fee to new sellers to make
more revenue. This can again be at the discretion
of the marketplace provider and can vary based
on the nature of business of the seller.

C) MARKETPLACE SERVICE SUBSCRIPTIONS -

This is a very important revenue stream for
marketplace providers where said platform
provider offers multiple services to sellers
and customers on the platform, e.g. payment
gateways, dispatch services, buyer and seller
ratings to establish trust among parties and
software application, enabling sellers to provide
better customer service, etc. Sellers and
buyers can subscribe to these services on the
marketplace, and they can be charged monthly
subscription fees for using these services or
instead, pay via a pay-per-use model.

D) SERVICE LISTING FEES – This model works

best for premium and high value services where
the platform provider can charge the seller when
they list items on the platform. Listing can be valid
for certain periods of time or indefinite periods of
time with varying prices.

3. Two businesses, Org-B and Org-G, join forces to
Transaction based Model sell a single combined service to the customer.
Org-B and Org-G provide complementary
services, service-S and service-T. Both Org-B and
Org-G have both direct relationships as well as
separate contracts with the customer.
An OTT player selling their product
subscription over the marketplace platform.
Commission is paid to the marketplace
provider by the seller for every subscription
sold.

In the case of Org-G playing prime for integrating

the services and bundles Org-B services as pass
through in their books, then the model becomes
B2G2C.

19
< Back to Contents | 5. Scope

The different monetization models can be incorporated for different business models
depending on the offering and the marketplace type. The following mapping depicts which
monetization model is best suited for which business model.

TRANSACTIONAL FEE REVENUE/PROFIT

BASED MODEL BASED MODEL SHARE MODEL
B2P: PURCHASER
(DIRECT-SELL) 3 3
B2D2C: DISTRIBUTOR
(RE-SELL) 3 3
BG2C: SELL WITH
(CO-SELL) 3 3 3
B2G2C: INTEGRATOR
(JOINT SELL) 3 3 3
A2E2B: ECOSYSTEM ENABLER 3 3 3

There are multiple factors to decide on best-fit monetization model in marketplace setup e.g.
Type of services offered by seller, Popularity of seller, Type of marketplace, Order volumes,
market presence, value vs volume services, popularity of the marketplace platform, partner
segments etc. a) A new startup will be keen work with transaction based model and switch
to fixed-fee based model as their revenue and sales grows with time b) a new marketplace
provider may want to offer more revenue/profile share model to attract more sellers/
partners to marketplace c) a partner offering unified services or part of a unified service
offering may be interested in a revenue-share model in order to jointly offer e2e services
with other partners. Both business transaction model and monetization model agreements
between marketplace platform providers and sellers are flexible and can be aligned as the
business evolves.

Consider the question, “what is the best business model and marketplace type for our
market, industry and geographic location?”

The answer to this will heavily depend on the moves of the big players, CSPs and cloud
hyperscalers alike, as well as on how governments, international organizations and regulatory
bodies will work to govern this global business. We expect a deeper exploration of this angle
in future iterations of this document.

20
< Back to Contents

6. Reference architecture

Software marketplace would bring a host of players/participants closer than ever before
and deepen the integration among them. The architecture must support different types of
actors/players/participants and various evolving business models.

The figure below provides a reference architecture required to support such a transition.

Figure 17: Reference architecture

supporting various actors and
business models

21
< Back to Contents | 6. Reference architecture

At the center of this transformation is CSP who will double up as a “marketplace operator”.
It will be responsible for defining strategies, aligned with its vision/goal for customer
success. It will be the governing authority who would play neutral role and provide rule-
based environment for customers, suppliers/partners and solution Integrators to transact
Please note, that
through the platform (aka Marketplace).
“supplier” and
CSP will control the “catalog categories” & the corresponding “specification” of the software “partner” terms are
services/assets that can be sold on the marketplace. Supplier/partners will look to remain used interchangeably
compliant to the “published specifications”. In case of software assets these specifications in this section
need to be far more elaborate in terms of external contracts and internal SLA. Marketplace
operator must provide automated means to check for the compliance against specification
and mechanism to monitor/report the agreed SLAs.

There is significant planning and strategy effort goes in bringing marketplace to life. CSP
must make choices around one or more models from various models (viz Business models,
contractual models, operational models & monetization/financial models). These models
are also evolving and there can be unique combinations of models offered by the CSP as
per their market position and target customer/supplier base. However, it is important for the
platform to be flexible in order to support different options that are currently in use or will
come in future.

Below subsections describe some important set of Marketplace Capabilities that are required
for its successful operations.

6.1 ENGAGEMENT MANAGEMENT

Experience is key to grow the software marketplace - both from customer perspective and
from the supplier/partner & solution integrator perspective. This set of capabilities are linked
to provide digital means to engage with the marketplace for all its participants.

This set of capabilities will provide engaging interface to support entire lifecycle of each of
the participant which means starting from onboarding to transacting to retiring. Different
players will have their unique needs to interact with the marketplace and accordingly their
interface is designed with specific portal application catering to specific type of participant.

For example, developers will be offered with a developer portal where they can get all
the necessary support to use exposed APIs from the suppliers to build solutions. Similarly,
Customers will have their specific digital interface (portal & app) to onboard, browse assets,
generate quotes, place orders, self manage owned assets, check invoices etc. Supplier/
partner will have their own digital interface to support various lifecycle stages and ability to
collaborate with the other participants like customers, marketplace operators and solution
Integrators. Supplier/partners will be able to manage their own supplier catalog, which
means - adding/updating offerings, purview offerings, sent offerings for approval, finally
publish offering & grandfather offerings. Solution integrators will have their own digital
interface to collaborate across suppliers and assemble solution offerings that provide more
value than sub of constituent offerings.

Apart from usual marketplace players, we also need to provide interface for auditors/
regulators/legislative to interact and observe the transactions as required by the local law.

It is a large capability set which includes CMS, various channel integrations like virtual
assistance, chat bot, faceted search etc to enable superior experience for marketplace
participants.

6.2 DECOUPLING AND INTEGRATION

This set of capabilities are linked to the enabling internal as well as external integrations.
Internal integration (or East West integration) is among various components of marketplace
whereas external (North South integration) is all about opening up of the platform APIs
for the consumption of various stakeholders like supplier/partners, solution integrators,
customers, enablers & regulators/auditors/legislators.

Participants can register themselves and subscribe to appropriate API product that gives
them access to standards based APIs to integrate with marketplace. This capability supports,
customer integration (large B2B), suppliers integration, enabler integration and regulators/
auditors so on.

22
< Back to Contents | 6. Reference architecture

This capability will include ability to expose & govern APIs (API management), ability for
partners to discover API products and subscribe to it. Every interaction will be metered
and policy checked. Additionally, marketplace owner can allow supplier/partner APIs to be
offered on it’s platform for Solution integrators to leverage. Marketplace can also enable it’s
Please note, that
supplier/partners to have their software assets hosted on its sandbox so that customers can
“supplier” and
feel the assets before making final decision.
“partner” terms are
used interchangeably
in this section
6.3 PARTY MANAGEMENT
This group is housing capabilities that holds information which is required to serve and
manage the lifecycle of various participants of the marketplace.

Every participant of marketplace will have their own “Account” that would manage their
lifecycle through different stages of relationship. For example, customer account will be
setup during the onboarding/registration of customer. Similarly, supplier/partner account will
be setup during the onboarding/registration of supplier/partner.

In case of an organisation, account may have several contacts identified to play specific roles
(e.g. Technical, Financial, Legal etc). Each of the contacts will get a digital identity and will
be assigned appropriate role. Access to platform features/capabilities will depend upon the
role he is playing for the account.

Access control is key in ensuring a “Chinese wall” between various suppliers/partners so that
their work in progress offerings and their value proposition, pricing rules etc. are not visible
to their peers/competitors.

In-life activities (post onboarding) like billing, invoicing, settlement, payment capabilities will
also be part of this group. Innovative CSPs will take these capabilities and will expose them
as enablers (e.g. bill on behalf etc) to its suppliers/partners - thereby further lowering entry
barriers for the partners to join the growth bandwagon.

6.4 CORE COMMERCE MANAGEMENT

This group of capabilities are enabling transactions among participants. Enabling rule-based
marketplace requires a rich contract management capability to allow various stakeholders to
operate under strict and level playing environment.

This capability need to support various business models and obligations on each player
participating in the platform. There will be contracts signed between Marketplace and
Suppliers/Partners as well as during the transactions there will be contract between
Suppliers and the Customers.

For suppliers/partners, once they are onboarded, the first capability they need is setting
up of the supplier/partner catalog. Catalog management is the most critical and strategic
function for a marketplace. CSP has to own the master catalog categories and define the
common minimum specification to qualify an offering in the category.

For software marketplace, this is even more important as specifications will have various
terms and conditions including API definitions, expected behavior or compliant with
standards, operating SLAs and management interfaces etc. Specification may include
mandatory compliance components as well as optional components.

Suppliers based on their contracts will be allowed to offer their services/products/assets

adhering to specific catalog category, matching up with the specification.

Once published and approved (after proving compliance to specification), customer will
be able to search, request quote and subscribe/buy the services. This will be enabled by
a group of business capabilities like quoting & ordering management and order capture &
validation.

This capability group also includes “In life Care” capabilities that may include raising issues/
disputes/SLA violations etc. Product inventory capability will enable “In life care” by ensuring
accurate account of products/services/assets associated with the customer. Marketplace
need not keep the elaborated services/resources used to realize the services but sufficient
information need to be maintained to support care functions.

Order orchestration and fulfillment capabilities will be limited to handing over orders to
suppliers/partners and expecting regular call backs or notification on the progress of
fulfillment of request. Marketplace operator may choose to define fulfillment SLAs as of
the contract/ catalog, and they will get tracked as part of this capability.

23
< Back to Contents | 7. Reference architecture

6.5 INTELLIGENCE MANAGEMENT

Marketplace interactions will generate tremendous amount of data which will be gold
mine to understand customer behavior and will allow marketplace operator to enable its Please note, that
suppliers to provide specific insights that can lead to higher ratio of conversions. Capabilities “supplier” and
supporting the entire lifecycle of collecting data, processing it with the aim of generating “partner” terms are
insights, providing actionable insights in form of next best action or offer recommendations used interchangeably
and tracking the success to complete the loop - will be part of this block. in this section
Additionally, marketplace can offer a set of tool (self provided or in partnership with other
enabler service) to launch targeted campaigns to its prospects and customers.

6.6 ENABLER SERVICES

This group of capabilities mainly enhances the overall value and experience of a marketplace.
CSP may choose to develop these services on their own or get into partnership with third
party players to enable these services on the marketplace. Depending upon the scale and
target participant, CSP may choose to offer multiple choices for these services. E.g. There
may be a choice of multiple payment gateways available to customers to make payment.
Similarly, there could be choice to use any of the marketing tool kit offering to launch
campaign and maximize reach to the customers.

We have tried to foresee some common minimum enabler services as part of this effort, but
this block is open for creative blue sky thinking and will act as real differentiator for the CSPs
in providing superior platform experience.

We also foresee scenarios where some (software) suppliers/partners would like to have
options in terms of hosting partners, and they may offer various combinations depending
upon the SLAs that are committed by the infrastructure provider. The “service delivery
platform” is again a broad capability which may include technical ability required to deliver
services to customer. It may include CI/CD, sandbox/playground, try to buy etc possibilities.

6.7 CAPABILITY VARIATION BETWEEN TYPE 1 & TYPE 2

MARKETPLACES
Capabilities listed in the reference architecture will continue to be applied for both type 1 &
type 2 marketplaces, however there are subtle differences at the complexity and coverage of
features within the capability. Below we highlighted some important differences.

TYPE 1 MARKETPLACE TYPE 2 MARKETPLACE

“CONTROLLED ECO SYSTEM” “OPEN BUSINESS“
MOSTLY B2B MOSTLY B2B2X

Business Model Ownership Single owner controlled Collaborative / consortium

Control Tighter control over solutions
Value Captures most of the value
created out of marketplace
On-boarding Partner selection • Hand picked partners (by
invitation)
• Mostly complementing
“Owner” offering or
increasing consumption of
“Owner” services
Promote innovation by
specifications
Shared value created across
eco system players
• Open to any offering
that comply with the
specification
• Flexible in choosing any
other partner to offer more
choices to it’s customers

24
< Back to Contents | 6. Reference architecture
TYPE 1 MARKETPLACE
“CONTROLLED ECO SYSTEM”
MOSTLY B2B
Catalog & offers Flexibility • Offerings must leverage
“Owner” provided services
or extend its platform
offering in controlled way
• Limited choices in terms
of choosing alternative
services to “Owner”
provided services
Offerings • Curated and certified by the
“Owner”
• Mostly single owner
offerings
Contracts Complexity Simple – mostly standard
between “Owner” & “Partner”
Ordering Fulfillment Simple – mostly single party
fulfilled orders
Billing & settlements Monetization Simple – pre-agreed Split
between “Owner” & “Partner”
- two party settlement
Developer portal, Service Playground complexity Provides agile, devops
delivery platforms environment to test the
product, compliance validation
Standardization / Design specification / • Proprietary-based
interoperability blueprint
• This can illustrate
“PROJECT”-based
approach hence non
repeatable
It is clear from the above comparison that - Type 1 being more specific and narrow focused
marketplace, need to support fewer variations and has lower complexity of many of the
capabilities compared to Type 2 marketplace.
TYPE 2 MARKETPLACE
“OPEN BUSINESS“
MOSTLY B2B2X
• Rule based governance –
allowing compliant offerings
• Mostly Lego blocks of SW
platforms allowing multiple
configuration options to end
customers (e.g. A supplier
can offer his services on any
of the public cloud provider
with varying degree of SLAs
and price point)
Simplifies and enables
complex multi-contracts,
multi-party contracts (like
partner to partner contracts)
Simplifies and enables
complex – has to include
splitting of orders and multi-
party fulfillment as well as
complex tracking
• Simplifies and enables
complex - Billing rules
• Monetization model being
shared values, can have
complex multi-party
settlement rules
Provides agile, devops,
environment to integrate Lego
blocks to build new platforms,
test, compliance validation
• “Standard-based” based
on a “generic marketplace”
specification.
• Adopting digital
marketplace solutions,
covering CSP and vertical
industry solutions, platforms
• Extensions to support
federated market places
25
< Back to Contents

7. Launching a marketplace

Software marketplace would bring host of players/participants closer than ever before
and deepen the integration among them. The architecture must support different types of
actors/players/participants and various evolving business models.

The figure below provides a reference architecture required to support such a transition.

STRATEGY & READINESS MARKETPLACE SETUP ENABLER ONBOARDING

• Business Model • Catalog Category Setup • Establish Contract
• Contract Term & Conditions • Core Offering Specification • Services Integrations
Setup
• Product/Service/Supplier
Strategy • Compliance Guidelines/Kit
Preparation
• Standard Partnershio
Contract
• Supplier Subscription
Configurations

SUPPLIER ONBOARDING SUPPLIER CATALOG SETUP MARKETPLACE OPEN FOR

BUSINESS
• Supplier Registration • Offer Design as per
Specication • Customer Registration
• Account Creation
• Asset/Service Content Setup • Account Creation
• Contract Negotiation & Sign
off • Pricing & T/C configurations • Customer Contract
Negotiation
• Supplier Integration • Fullfillment Configurations
• Quote & Ordering
Negotiation
• Payment

Once the vision and strategy is finalized, the next step is to move towards setting up of the Figure 18: Possible journey of
platform, which includes setting up of catalog categories and corresponding specification. CSP marketplace launch
A standard contract is set up with options based on the business models. Marketplace
subscription (supplier subscription) are setup that can facilitate supplier onboarding and
contracting. Marketplace enabler services are also onboarded with specific contracts and
service integrations.

Next step is to start supplier onboarding, which include supplier registration and account
creation where basic information is collected about the supplier. This is followed by contract
negotiation and plan (subscription) selection. Post contract sign off the supplier integration
work begins where supplier implement/integrates based on the platform integration
strategy. There is a separate developer portal where all the workflows, API specifications
(based on TMF Open API) and sample code is available to help supplier quickly integrate
with the marketplace.

In parallel to supplier integration, supplier catalog setup and automation is completed,

which includes setting up product/service/assets/content page setup, configuring features &
prices. Fulfillment configurations and configured via easy to use launch process.

The last step in launch is opening the marketplace for the customers for transactions.

26
< Back to Contents

8. Conclusion

Software marketplaces provide a new avenue for communications service providers to

explore new business and revenue models. Having invested in a flexible scalable architecture
exposed through open APIs, the foundation exists to expose capabilities beyond the
boundary of the organization, partnering with others and thereby selling more services to
more partners in the future.

In an open ecosystem model where the boundaries between different verticals continues
to blur and enterprises embark on their own digital transformation journey, the potential
for reselling of connectivity and related services will grow exponentially. CSPs need to
consider their strategy in this regard, ensuring that their own approach creates the right
foundation for growth into the future based on who their target customers are the highest
potential for growth. This paper provides insights both technical and business to help CSPs
to make these strategic choices and build out their roadmap for success. Future work
will further explore both business and technical aspects to achieve the best practice and
recommendations.

27
< Back to Contents

9. Administrative appendix

9.1 DOCUMENT HISTORY

9.1.1 VERSION HISTORY

VERSION NUMBER DATE MODIFIED MODIFIED BY: DESCRIPTION OF CHANGES

1.0.0 29-Jul-2021 Loell Wolfries, TM Forum Initial release - pre-production

activities

9.1.2 RELEASE HISTORY

RELEASE STATUS DATE MODIFIED MODIFIED BY: DESCRIPTION OF CHANGES

Pre-production 29-Jul-2021 Loell Wolfries, TM Forum Initial release pre-production

9.2 ACKNOWLEDGMENTS
This document was prepared by the members of the TM Forum Digital Ecosystems
Management project, namely, the following members of the Software Marketplaces
workstream:

Andrew Thomson, BearingPoint

Andreas Polz, BearingPoint
Viranga Seneviratne, Dialog Axiata
Thierry Reynard, Etiya
Gnanapriya Chidambaranathan, Infosys
Dinesh Shah, Infosys
Shiv Ojha, Infosys
Shri Krishan, Infosys
Nishi Mathur, Infosys
Jinu Koshy, Infosys
Ravi Verma, Infosys
Tayeb Ben Meriem, Orange
Knut Johannessen, Telenor
Joann O’Brien, TM Forum

28
< Back to Contents

10. Use cases

Use-cases and examples from Telco Assets Marketplace Catalyst can be found in the
table below.

DLT / Blockchain-based-Telecom Assets Marketplace Use Cases

(Catalyst)
https://www.tmforum.org/blockchain-based-telecom-infrastructure-marketplace/
https://www.tmforum.org/wp-content/uploads/2020/11/Federated_CSPs_Marketplace_Whitepaper_C20.0.34.pdf

AS A I NEED TO SO THAT I CAN TO DO THIS I NEED TO I KNOW I AM

SUCCESSFUL WHEN

CSP seek new Telecom Reduce dramatically bring 5G Mobile Access I am able to build
(Communication Assets and deployment cost (Zero- Networks closer to Users capacity - infrastructure
Service Provider) Energy Sourcing, Capex model) as well and associated energy
Deployment and as Energy consumption in the following supplies based on needs
Investment models (expected to be 3 times identified through my
for 5G) becomes key Business Scenarios (1) : selected Business
objective. Besides, Scenarios and supported
mobile traffic growth is • 5G Cell Re-enforcement by varied business
continuously and heavily /Densification in Urban models
increasing and 80% is areas
Indoor generated • Initial 5G Deployment/
Coverage in a Country, a
Address the new Business City, a White Zone,
Opportunities emerged
from Verticals (request of • Crowded locations such
diversity and variety of as malls, Airports or
5G Slices Stadium for 5G coverage
of a temporary event
(Football match, Music
concert ) and deliver
live multimedia access to
the attendees via their
Smartphones
• 5G NPN (Non-Public
Networks) to cover
Multi-site Industry 4.0,
Enterprises) to meet
requested IIOT (Industrial
IoT) through 5G eMBB,
uRLLC , mIoT and MTC
services including
eSIMs subscription /
provisioning to their
IIOT devices

29
< Back to Contents | 10. Use cases

DLT / Blockchain-based-Telecom Assets Marketplace Use Cases

(Catalyst)
https://www.tmforum.org/blockchain-based-telecom-infrastructure-marketplace/
https://www.tmforum.org/wp-content/uploads/2020/11/Federated_CSPs_Marketplace_Whitepaper_C20.0.34.pdf

AS A I NEED TO SO THAT I CAN TO DO THIS I NEED TO I KNOW I AM

SUCCESSFUL WHEN

Asset Provider connect to a digital sell / share / lease my on-board assets, create I am able to close
Market place that assets to CSPs providing asset offers, define contracts seamlessly with
• 5G VNFs / SW supports new new age services with 5G contract agreements on CSPs and get the billing
Provider business models the fly in the Marketplace done in an automated
• Frequency Provider (like on- demand fashion
• Wholesale purchase / rent;
Connectivity auction)
Provider
• eSIM Provider
(CSP/ MNO/MVNO,
Vendors, Dedicated
Marketplace)
• CSPs as SW
companies
(Homemade
VNFs, AI Models /
Algorithms)
• CSP’s AI Models
Marketplace (e.g
Orange)

EU Regulator monitor and make sure all Marketplace support and guide energy EU Energy regulations
<ECO 30> (5) guide the Energy transactions are Ecosystem in moving away (ECO 30) are established
Marketplace happening as per from current model of
regulatory guidelines producing and consuming
Energy and associated
processes towards a «
Green model » to meet
the EU Energy regulation
(ECO 30)
3rd party Sponsor Fund Assets financially support establish as a Sponsor in I am able to fund Telco
Ecosystem Stakeholders the Marketplace, flexible Assets projects as per
projects to seize and have my financial to support new business new business models and
sponsoring business models (e.g. monetization reward CSPs’ customer’s
opportunities the with advertisement) usage of the digital
Telecom Assets services built upon the

Marketplace may Telco Assets Marketplace

offer me to and see my brand
reward the usage, exhibited
consumption
of services (e.g.
Connectivity, Data)
by CSPs’ customers
delivered by
networks through
selected assets

References

(1) Unlocking the benefits of 5G for enterprise customers: https://assets.kpmg/content/dam/kpmg/xx/pdf/2019/04/unlocking-the-benefits-of-5g-for-enterprise-customers.pdf

(1) Small Cells 5G Network market: https://www.zionmarketresearch.com/market-analysis/small-cell-5g-network-market
(2) GPGR: https://www.delphix.com/solutions/compliance/gdpr-compliance-solution?gclid=EAIaIQobChMI94z8zJX08QIV8e3mCh0rygtNEAAYAyAAEgIrh_D_BwE&utm_
source=adwords&utm_medium=paid_search&utm_campaign=dpc
(3) EU AI Act: https://www.lawfareblog.com/artificial-intelligence-act-what-european-approach-ai
(4) AI Sovereignty (EU’s GAIA-X project): https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html
(5) EU Regulator Green Energy <ECO 30>: https://ec.europa.eu/commission/presscorner/detail/en/ip_20_1599

30
< Back to Contents

11. Developer is King! Catalyst:

Business Model Evolution

‘Developer is King!’ catalyst project focused on new business models or new revenue streams
possibile with the telco capabilities and tools exposed in the 5G era. It bridges providing
more capabilities to enhance the vertical industry specific solutions that can bundle telco
services for e.g., QoS upgrade on the fly. This requires telco capabilities (e.g., Telco APIs,
Software Components, Platforms, Test Bed, ...) to be made available for developer or
software solution provider eco systems and vertical industry players.

Developers envisions a future where they can co-create applications with Telcos, along with
directly using Telco capabilities. Some of the needs from Telcos are

Multi national Deployments

Need for Billing/Charging, Anonymized Data, Location Based Services have increased

Seamless connectivity, 5G, QoS capabilities for enhancing experience for live streaming
sessions with 4K, 8K video and Immersive experience with XR

Edge capability for Content Caching, Analytics

Sandboxes and Test Environments

BUSINESS ECOSYSTEM

Telcco
Operator
Developers

Cusotmers
of
Telco
Development
Customers

Partners

Business Ecosystem
evolving models

Here is a view on the business eco system evolution that brings the suppliers (developers /
ISV communities), CSPs, vertical enterprises (in this scenario ‘Educational Institution’ and it’s
stakeholders) and eco system partners leveraging the marketplace for their needs. Bundled
solutions are built with the capabilities exposed leading to advanced vertical industry
platforms delivered thro’ the market place.

31
< Back to Contents | 11. Developer is King! Catalyst: Business Model Evolution

DEVELOPER IS KING! EVOLVING BUSINESS ECO SYSTEMS, MARKET PLACE. USE CASE: REMOTE EDUCATION

This bundled solution provides enhanced customer experience (end users of the vertical - Evolving business ecosystem
education industry, students, faculty, ..). and Market Place

EVOLVING COLLABORATION FOR BUNDLED OFFERINGS, ENHANCED EXPERIENCE

Evolving Collaboration in
MarketPlace for bundled
offerrings to provide enhanced
experience (e.g., Education
platform enriched with CSP
capabilities)

32
< Back to Contents

12. Federated Dynamic NFV Catalogs

with diagram

The diagram below depicts the global architecture of the “Federated NFV Dynamic
Catalogs” model as an architecture view of the “CSP’s NFV Dynamic Catalog” User Story. It
illustrates the way a CSP builds and populates its “Dynamic NFV Catalog” by partnering with
relevant stakeholders in a flexible and dynamic manner e.g. connecting all involved partners’
NFV Catalogs including NFV Marketplace Catlog via Catalog API under flexible Governance
& Policies controlled by the CSP.

This architecture is composed of two categories of stakeholders and associated Dynamic

NFV Catalogs

1 Dynamic NFV Consumer (CSP) and its Catalog (in the middle)

CSP’s Sourcing department Dynamic NFV Catalog

2 Dynamic NFV Providers and their Catalogs

CSP’s Sourcing department Dynamic NFV Catalog

Dynamic NFV Marketplace’s Catalog
Dynamic NFV Suppliers’ Catalog
NFV Yellow Pages/ Dynamic NFV TMForum ZOOM’s Catalog
Dynamic NFV Auditor’s Catalog
Dynamic NFV New Entrants (Software-oriented Vendors) Catalogs
Homemade Dynamic NFV CSP Software Design Department’s Catalog

Federated dynamic NFV

Catalogs (high level
architecture): Orange’s Case
Study (Source: IG1133C /
Figure 5)

33
< Back to Contents

13. Digital Business Marketplace Catalyst:

Use Case and Business Impacts

The DBM team developed a generic use case which articulates any industry vertical
organization defining their own offerings, and combining them with the necessary horizontal
capabilities from a range of partners. The purpose is to enable a customer to select the
smart x solution in the product-driven rule-based shopping cart so that the appropriate
combinations of components (including those from the various partners) are selected. The
order and fulfilment through to activation processes are completely frictionless driven by
the selction from the range of plug and play partners, taking advantage of highly repeatable
DBM patterns, so that the solution is delivered to site and then activated zero touch from the
cloud without any sharing of passwords. The DBM platform handles the secure processing
of tokens and provides billing between all the partners. It is important to note that each
of the partners is providing their offerings as a service, so a partner consortium SLA and
contracting approach is also provided by the repeatable patterns of DBM.

INDUSTRY 4.0 SMART X, WHERE X IS A FACTORY, AIRPORT, MINE, POWER

Industry 4.0: Use case

The new Smart capabilities required by Enterprise organizations increasingly rely on

new technologies: AI, ML and Digital Twin capabilities which in turn rely on the latest
technologies spanning 5G, IoT, ICT, NFVs, SDN, Apps and software leveraging compute at
the edge, often referred to as industry 4.0 and Smart X capabilities.

The traditional approach to deliver these new industry 4.0 and Smart X capabilities is to
assemble an expert team and run a project. But, for example, to deliver a Smart Grid overlay,
abstraction and orchestration for 255,000 substations as projects in the US alone will
probably take 40 years! So a better approach has to be found!

By comparison, the approach taken by the Digital Business Marketplace (DBM) leveraging
TM Forum’s SID and Open APIs plus DSE extension converts these projects into selectable,
highly automated repeatable “solutions-as-a-service”, with selection in a catalogue driven
shopping cart enabling mass customization with customer management, order orchestration
including automated “moves, adds, changes, and deletes”, billing management and
collections, all automated across all ecosystem partner members – delivering zero touch
right from selection in the shopping cart, through to activation, no sharing of passwords and
no manual actions (apart from deploying devices and turning on the power).

In addition to the time taken and the costs of undertaking projects, there are multiple
other issues in the traditional project approach to Industry 4.0 & Smart X. Most of these
are resolved with the end-to-end automated frictionless “plug & play” trading approach of
“Solution as a service” from DBM:

34
< Back to Contents | 13. Digital Business Marketplace Catalyst: Use Case and Business Impacts
DELIVERING INDUSTRY 4.0 & SMART X AS….
PROJECTS
Each project takes months to plan
with multiple technical and business
negotiations to be ready for contract
Multiple suppliers, all using different
taxonomy, stretched across multiple
projects, with each integration being
individually fashioned and not repeatable
Assembling the project needs multiple skills
to be involved
Not repeatable, takes time & very expensive
Everything is manual and custom
Deployment is bespoke with teams on site
to engineer and continuously cross check
Upgrades & maintenance increasingly even
more bespoke over time with specialists on
site
Hiring and retaining specialists becomes
harder over time
Manual interactions needs sharing of
passwords
E2E security is difficult with challenges to
manage surfaces against cyber attacks
Manual billing and complex reconciliation
between lead contractor and suppliers
Uncertainty for the various organizations
involved in the overall and individual
financial health of the project
Auditing complexity
PROJECTS
Solutions take a couple of months to
onboard but can then be selected, deployed
for multiple sites zero touch
All organizations use same technical and
commercial “language”, each operating as
their own solution marketplace with ease to
define offers and plug & play with trading
partners frictionlessly
With each organization onboarding
their own configurable offerings,
this enables rapid prototyping for
“Anything-as-a-Service”
Repeatable patterns, with rapid onboarding
Everything is automated and highly
configurable, enabling mass customization
Installation team onsite, turn on the power
and it configures from the cloud
In-Life Management, upgrades and security
patching from the cloud Zero-Touch
In life management of solutions as a service
from the cloud with AI & DTs which are
provided as a service with the specialists
managing multiple deployments
E2E Automation with no sharing of
passwords
Secure Supply Chain for complete device
provenance of devices and systems and
Cyber security baked in
Automated Billing for customers and
between all partners with automated
settlements
End-to-end financial controls for each
organization to control what a customer or
partner can buy in the shopping cart on the
basis of whether the customer has paid, are
a bad payer or have not paid recent bills
DLT auditing and Assurance
35
< Back to Contents | 13. Digital Business Marketplace Catalyst: Use Case and Business Impacts

The implications of DBM repeatable patterns and industry agnostic approach is able to
deliver Industry 4.0 and Smart “Anything as a Solution” as a managed service frictionlessly
from an organization and its partners, saving thousands / millions hours, Zero-touch, cyber
secure, scalable and manage-able in life zero touch.

DBM - BUSINESS IMAPCT SUMMARY

The Digital Business Marketplace has developed frictionless partnering blueprint patterns for secure delivery, in life
management & monetisation of Industry 4.0 & Smart X solutions

BEFORE WITH DBM AFTER

Industry 4.0 Current Situation DBM Capabilities DBM Outcomes

• Most things are custom
• Most things are manual
• Takes time & expensive
• Bespoke deployment
• Bespoke upgrades
• E2E security is difficult
• Hiring specialists is hard
• Staff (un)reliability
• Multiple suppliers
• Auditing complexity
• Repeatable patterns • Anything as a solution and
• Rapid onboarding managed service
• Highly configurable • Saving thousands/millions
• Every organization is its own hours
marketplace • Zero-touch
• Zero-touch deploy and in-life
manage • Cyber secure
• E2E automation • Scalable
• Secure supply chain • Plug & Play for any
• Billing and settlement organization joining
• “Anything-as-a-service”
• SSO, DLT assurance

Industry 4.0: Projects versus

DBM Solution Benefits

36