Scaling & Differentiating Your MSP Business Using a Cloud Ecosystem Manager

Home Insights Research and Whitepapers Scaling & Differentiating Your MSP Business Using a Cloud Ecosystem Manager

Executive Summary

Authors: Sash Purohit, CTO – Products, and Justin Carlson, Vice President Lead – Product

Managed service providers (MSPs) in the IT services industry generally include a cloud service practice. Many MSPs therefore attempt to develop core competencies in the most popular flavors of public and private cloud services, which is a daunting task due to the advanced technical skills required and the ever-increasing diversity of cloud services. The ongoing industry shortage of qualified human resources only compounds this problem. Software-based automation is generally seen as the optimal way to achieve success, scale up, and differentiate the MSP offering. However, which cloud services to automate and how to go about doing so in an economical, consistent, and secure manner is not easy to determine. Most mid-market MSPs fall into the trap of driving automation based on customer specific use cases—a reactive approach that invariably results in siloed capabilities, inability to scale, and lack of service differentiation. A cloud ecosystem management platform (CEMP) can offer scale and differentiation in the MSP cloud business. CEMPs can support all flavors of cloud services (IaaS, PaaS, SaaS, and AnyAAS) across single, multi, or hybrid cloud environments, providing governance, security, orchestration, workflow, and integration and thereby extending enterprise architectures to include cloud services. In addition, CEMPs can also be used to create cloud marketplaces for industry verticals such as telecom, healthcare, and insurance. Creating a cloud marketplace for a specific industry vertical is another business opportunity for MSPs, especially those with extensive systems integration experience.

The IT industry is going through unprecedented change—the transformation from IT projects to digital product management was brought on by digital transformation and accelerated by the COVID-19 pandemic. Today, even a low-tech company manufacturing commodities must include a software application as part of its product offerings. The days of treating IT as a cost center to build technical solutions though IT projects and conventional outsourcing strategies are over [5]! Business and IT teams are transforming into digital product teams that manage end-to-end lifecycles. MSPs need to equip themselves with software capabilities and accelerators to face this new reality, and a CEMP can help.

This paper leverages the work of The Open Group’s Cloud Ecosystem Reference Model (Standard) [3] to describe the important technical and functional capabilities of a CEMP. This is followed by a description of how to apply reference model principles to create a CEMP. We then describe the functional architecture of a CEMP for internal use by an enterprise. Examples of leading cloud ecosystem marketplaces from the IT and telecom industries are described next, including some of the additional capabilities required for a marketplace offering. Finally, we provide a recipe for MSPs to scale and differentiate their businesses with the help of a cloud ecosystem manager.

Introduction

Gartner defines a managed service provider as a business that delivers IT services, such as network, application, infrastructure, and security, via ongoing and regular support and active administration on customers’ premises, in their own data center (hosting), or in a third-party data center. The advent of cloud and digital transformation has created immense demand for cloud-based solutions. The market for cloud managed services is expected to reach $145 billion by 2030, growing at a CAGR of 13.4% [1]. MSPs recognize the business growth potential that cloud offers but are stymied by the technological and human resource challenges that cloud presents. There are two major undercurrents affecting MSPs—the explosive growth and diversity of cloud service offerings from the major public and private cloud providers and the enterprise move to digital product from conventional IT services. As enterprise IT architecture moves towards a product-based [2] and multi-cloud approach, MSPs face the daunting task of mastering a diverse collection of hundreds of different cloud service offerings by the hyperscale cloud providers (also known as hyperscalers); this is in addition to new IT capabilities [3] introduced by the cloud ecosystem and the changes necessitated by the move from project-based to product-based operating models.

Not recognizing and adapting to this changed landscape can prove fatal for an MSP. The smarter MSPs sign partnership agreements with the hyperscalers but often struggle to remain in the partnership as they find it difficult to meet revenue goals amidst the ongoing shortage of qualified human resources. Some end up with siloed capabilities that are fragile and cannot scale up to more than one customer. The smartest MSPs recognize that the cloud ecosystem and product centricity pose a new set of challenges that they need to address in
a different way.

Diverse Cloud Offerings from Hyperscalers and Private Cloud Vendors

Many companies, such as Amazon web Services (AWS), Microsoft (Azure Cloud Services), Google Cloud, Oracle Cloud, Alibaba, and Equinix, offer public cloud services, with each provider offering 100s of different services. In fact, the top vendors, including AWS and Azure, have at least 25 different categories of cloud offerings and over 200 different services. Private cloud vendors, such as VMware, RedHat, and others, maintain a dominant share of the overall cloud services market; each also offers 100s of different products and services.

1,000+ cloud services across 80+ categories

In such a diverse and technically rich cloud service landscape, MSPs can only hope to master a small subset of cloud service provider offerings. However, even that can be a daunting task as most inevitably choose the top two or three hyperscalers, such as AWS, Azure, and GCP—still adding up to several hundred different services. On top of that, achieving mastery over even a single vendor’s cloud services requires time, money, and skilled technical staff who can pass the certification exams offered by these vendors. Even if some MSPs succeed in achieving mastery over the popular cloud service provider offerings, the success is temporary and difficult to scale due to manpower movements and scarcity of talent. Some MSPs adopt the “learn-it as you need it approach.” While such an approach may work in very small engagements, it is non-starter if an MSP is targeting mid-market and large enterprises.

Digital Product Centric Operating Model

In The Shift to Digital Product, [4] the authors argue that IT-enabled products and services are becoming the norm in every market. A major consequence of this change is that IT can no longer think of the business as opaque customers, and at the same time, business teams can no longer treat IT as project brokers, order takers, and machine operators. They go on to propose that IT management should become digital portfolio management as it changes the way enterprises need to think about lifecycle management, dependencies, accountability, IT investment practices, IT financial management, and IT ROI. The Open Group updated the IT4IT Standard releasing Version 3.0 that provides a reference architecture used to manage the business of IT and the associated end-to-end lifecycle of digital products.

The transition from an IT service to digital product model is best illustrated in this side-by-side comparison by The Open Group. The main change is that a digital product model removes all services provided by human labor and replaces them with technology or software code. This has major implications for MSPs: simply adding human resources to provide customer solutions is no longer a viable business strategy for digital product. Winning business through software automation and innovation is the only viable business strategy.

COVID-19 also accelerated the shift to digital, as documented by numerous articles and publications. Digital transformation has remained the dominant theme for the last decade despite its low success rate. Yet, due to the inevitability of digital products and services, faith in digital transformation is still very strong.Most mid-market to enterprise level customers of MSP are already undergoing a digital transformation, having moved from a project to product model. Project to Product [5] describes the impact of digital disruption on traditional models of enterprise IT. In its foreword, Gene Kim states that in the age of software, the methods that served us well for over a century—such as IT project management, managing technology as a cost center, traditional outsourcing strategies, and relying on software architecture as the primary means to increase developer productivity—are coming to an end. We completely agree!

Digital Transformation

Considering these tectonic shifts in the enterprise IT landscape, it is unsurprising that MSPs are impacted in multiple ways. As illustrated above, over time typical IT projects will ramp down, giving way to digital products. MSPs that adapt to this change and offer software accelerators can expect to see greater engagement, responsibility, financial accountability, and transparency as they become an integral part of digital product lifecycle management. For example, enterprises will be looking to create digital platforms for the consumption and brokerage of cloud services as new digital products. MSPs with the right toolset can help enterprises to create and manage such platforms on a multi-year engagement via a SaaS subscription or an on-premises license. While this is a tremendous opportunity for MSPs, they must be prepared with a solution that enterprises can easily customize to their requirements.

Vendor Specific Management Tools Provide Limited Benefits

As mentioned previously, MSPs often sign partnership agreements with leading hyperscalers; this then leads them to build software solutions using partner vendor cloud services. Once a customer’s infrastructure footprint grows beyond a couple dozen or more clusters, the problem of managing these resources becomes extremely important; this includes provisioning, orchestration, governance, cost, security, auditing, reporting, compliance, and more. The natural approach to solving the management problem is to use the partner vendor’s management toolset. As a result, the MSP is locked into the vendor’s software and cloud services, and it becomes extremely difficult to abstract away and apply the same solution to another customer using a different hyperscaler. For customers using the same hyperscaler, it is possible to re-use some management capabilities, but this reactive approach to cloud management often requires a significant amount of refactoring to function across multiple customers. Even so, this approach leads to multiple solutions—one or more per hyperscaler—that must be individually maintained and evolved as the hyperscaler adds more services.

Customers are not only adopting multi-cloud approaches, but they also have a significant private cloud footprint. As a result, the same problem across multiple hyperscalers now repeats itself with private clouds. It is therefore safe to conclude that this reactive approach is not scalable, and leads to vendor lock-in along with fragile and non-scalable solutions. The question that naturally arises is how to create a solution that works across multiple cloud vendor stacks when no two vendors are equal. Would abstraction lead to loss of functionality, resulting in software that delivers the lowest common denominator for capabilities?

In the quest to address this challenge, it is important to first understand the entire cloud context. This is where a cloud ecosystem approach that defines the various participants and their roles within the ecosystem offers hope of a proactive, cloud agnostic, and universal approach. In 2014, The Open Group created the cloud ecosystem reference model [6]. What follows is a quick overview of this reference model along with how it can be used to address the challenge.

Cloud Ecosystem Reference Model

Enterprises have long recognized the need for business agility. When combined with existing enterprise architectures, cloud services and solutions not only promise to provide greater business agility while reducing cost, but they also address any gaps in an enterprise’s capabilities. To deliver this agility and cost saving, it was necessary to build an enterprise architecture for the cloud ecosystem. In 2014, The Open Group created the cloud ecosystem reference model [3]. As illustrated by the reference model diagram, the requisite software capabilities can be grouped into the following categories:

Management Services, including:

Business Support Services:

Accounting & Billing Services
Availability & Continuity Services
Compliance & Policies Services
Consumer Services
Contract & Agreement Services
Metering Services
Order Services
Service Demand Services
Subscription Services

Operational Support Services

Capacity & Performance Services
Incident & Problem Handler Services
Inter-Cloud Connection Services
IT Asset & License Services
Rapid Provisioning
Service Life Cycle
Service Orchestration
SLA Compliance Services
Template Services

Supply Services, including:

Product Catalog Services
Resource Catalog Services

Cloud Security Services, Performance Services, and Interoperability & Portability Services are also included. In the interest of brevity, we will focus only on management services and supply services in this white paper. Detailed definitions can be found in the referenced source [3].

Cloud Security Services, Performance Services-info-g-4

Applying the Cloud Ecosystem Reference Model

The ecosystem reference model can serve as the architecture for software that automates many of the business support, operational support, security, performance, interoperability, and service supply services. A new breed of software, cloud ecosystem management software, provides these services and integrates various components of the cloud ecosystem in a vendor-agnostic manner, which can help address the challenges while offering scale and differentiation to MSPs.

Integration is a fundamental problem in any digital ecosystem. In cloud ecosystems, it takes on a whole new meaning with hundreds of different cloud services from hyperscalers to thousands of services, if you include SaaS vendors. It is a problem that not only needs to be addressed by any ecosystem platform, but it also needs to be solved in a way that makes integration low-code, scripted, abstracted, configurable, reliable, scalable, and secure. A complementary approach is to offer platform on-boarding APIs that can be used by cloud vendors to integrate with the ecosystem platform. However, cloud vendors may need business incentives to undertake the integration work, so it is initially preferable to build these integrations into the ecosystem platform out-of-box.

Low-Code, Scripted, and Configurable API-Based Integrations

Adopting a low-code, scripted, and configurable approach to API-based integrations makes the ecosystem platform easier to integrate with hundreds or thousands of cloud services. Low-code means that many aspects of integration, such as connection setup, connection thread pools, communication protocols, authentication models, and interface code generation from Swagger/Open APIs or using provider API SDKs, are already baked into or configured in the platform. That leaves development resources available to focus on coding cloud domain and provider specific functionality.

Scripting is a good technique that provides flexibility without having to rebuild the platform code. For API requests that don’t require any data to be persisted on the ecosystem platform—such as real-time performance data displayed on a dashboard—scripting can be used. On the other hand, cloud domain and provider specific functionality involving stateful updates to ecosystem objects requires software abstraction to separate domain and vendor specific objects and functions from domain and vendor agnostic objects and functions.

Cloud Agnostic Software

At a high level, we must divide ecosystem platform software into two parts—cloud agnostic software and cloud vendor-specific software—where cloud agnostic software deals with management objects that are abstracted from any cloud vendor, and cloud vendor specific software solves a problem using cloud vendor specific services. For example, Order Service (a business support service) can support ordering any cloud vendor’s services using a product catalog via rapid provisioning and service orchestration (both being operational support services), while the cloud vendor specific software would leverage Amazon’s EKS APIs or Azure AKS APIs to create a K8s cluster. Such an approach does not suffer from the lowest common denominator problem mentioned above. Certain solutions on the market take the lowest common denominator approach by creating a common blueprint that can work across multiple clouds, but such approaches cannot keep up with the pace of innovation of hyperscalers and the differences in capabilities offered.

By applying the principles of low code, scripting, configuration, and abstraction to all cloud interfaces and building each of the different business support, operational support, supply side, security and performance services, a cloud ecosystem management platform (CEMP) can be created. A CEMP addresses the major IT trends towards multi-cloud adoption and product centricity identified earlier. Supply side services essentially codify product centricity by providing a catalog of offers. The CEMP captures the agile nature of the cloud where different components of the ecosystem come from different sources and providers, but they must all co-exist in a smoothly functioning system. It is important to note that with the paradigm shift towards cloud computing, even physical hardware (bare-metal servers) is included in the ecosystem and must be supported by a CEMP.

Scaling Requirements

Large organizations using hyperscaler services often have thousands of accounts and use hundreds of different cloud services across IaaS, PaaS, SaaS, or AnyAAS. The ecosystem platform should seamlessly scale to handle the load; it is therefore imperative that the platform offers ways in which each interface can be tested at scale. However, testing at scale is a challenge since cloud vendors often charge for API usage and/or limit the number of requests per hour. An approach to address this challenge is to provide the ability to emulate cloud services for load and performance testing.

Extensible Platform

Like most ecosystems, the cloud ecosystem is not static. This means that CEMP capabilities and integrations will need to evolve over time. While many changes can be handled through configuration, low-code updates, or scripting, new capabilities may require development at the platform level. It is therefore imperative that the CEMP offers an SDK (Software Development Kit) to be used by developers to add or customize platform capabilities.

Future of Integrations

Because integrations are the lifeblood of a cloud ecosystem, it is imperative to understand how integration technology may evolve in the future. In his book, Flow Architectures [6], James Urquhart argues that the future of software integration is in event driven streams (known as Flows) that will ultimately lead to the creation of the Work Wide Flow (WWF), similarly to the way the World Wide Web evolved from HTTP. Flow interfaces and protocols will handle all aspects of setting up a connection, managing the flow of data, and identifying the type of payload, encryption, authentication, etc. However, consumer processing of the data received would still be payload dependent and require payload specific code to handle. Streams-based integration technology, which is very much in the early stages of maturity and adoption, offers a glimpse into how integration might look like in the future. AWS EventBridge and Lambda functions are some early examples of streams-based integrations. However, even with streams-based integrations, the payload that is received by the integrating party must still be processed. So, the approach identified earlier that leverages software abstraction would still be necessary.

Cloud Ecosystem Management Platform (CEMP)

A CEMP implements the capabilities defined within the ecosystem reference model, while considering the requirements for low-code, scripted, configurable, and abstracted integrations. The platform would need to support multiple tenants and be highly scalable, secure, highly available, and able to be deployed on-premise or in the cloud. These product capabilities are essential to enterprises for successful multi-hybrid-cloud adoption and repeatable digital product delivery at scale.

The Open Group’s cloud ecosystem reference model can be mapped into three high-level areas of CEMP functionality: cloud provisioning, cloud operations, and cloud governance.

Cloud Provisioning

CEMP should act as an agnostic cloud service broker—providing self-service order management services, workflow management, rapid provisioning and orchestration, and service lifecycle management across IaaS, PaaS, SaaS, etc. (AnyAAS).

Within a CEMP storefront or marketplace, cloud agnostic order services facilitate self-service rapid provisioning and orchestration. CEMPs leverage cloud native resource deployment blueprints (i.e., AWS CloudFormation, Azure ARM, GCP Deployment Manager, Oracle Resource Manager, VMware vRA Blueprints, etc.) to rapidly provision resources in the cloud. Dedicated CEMP cloud provisioning services inspect templates from each cloud provider and abstract them into the centralized product catalog. Providing vendor dedicated cloud provisioning services leveraging native templating delivers best-in-class capability, ensuring CEMP users can always take advantage of the latest cloud innovations (without suffering from the lowest common denominator of cloud service abstraction – as discussed above).

Once onboarded, these cloud services are productized as offers by the CEMP complementing them with vendor agnostic roles-based self-service, order configuration, cost/pricing, and business process automation. By productizing these services as configurable digital products, we can easily deploy and redeploy them across a varied spectrum of end user, customer, and industry use cases.

Cloud Operations

CEMP should provide management tools for IT operations and financial-operations (as companies move away from projects to products and include infrastructure costs as part of the digital product portfolio), such as a single-pane-of-glass for performance and availability monitoring, cloud events and alerts, and rolled up costs by service, etc.

Without CEMP, cloud service lifecycle management is fraught with intense manual white-glove services requiring human resourcing to swivel chair across various operations and ITSM systems to fulfill service requests and monitor resources.

To fulfill service requests, CEMP embedded workflow services support service orchestration and lifecycle management across IT-Infrastructure-Financial-Operations. With CEMP Workflow, cloud service lifecycle activities from initial creation and ongoing management through decommissioning are automated with defined business processes. In this way, leading CEMPs are often viewed as the “Orchestrator-of-Orchestrators,” facilitating the business process across supporting systems and tooling thereby greatly minimizing manual intervention.

Within CEMP, centralized performance and availability monitoring is essential. Leading CEMPs provide a flexible single-pane-of-glass (SPOG) that, again, takes advantage of vendor-specific and vendor-agnostic software approaches. Like the modern approaches for service catalogs and rapid provisioning we have discussed, CEMPs create vendor-specific discovery services that consume monitoring and observability information via API, synthesize it through a governance model, and display the information in an abstracted SPOG UI/UX that can vary across user personas.

Cloud Governance

CEMP should centrally manage identities, permissions, roles, accounts, and policies for access to cloud resources/entitlements facilitating compliance/audit reporting and usage metering (cost and billing).

CEMPs provide a centralized governance model in which cloud resources are bound directly to the individual identities that are responsible for them. This governance framework and organizational model provides a 360° view of cloud resources, their utilization, cost, and compliance.

A governance model’s core foundation is the understanding of the organization’s identities, projects, budgets, departments, and other hierarchical business units. Leading CEMPs auto-discover this model from existing sources of identity or organizational hierarchy (e.g., 0365/AD, CMDB, ITSM, etc.) and dynamically manage it as it evolves. By centralizing the acquisition of new cloud resources in the self-service storefront or marketplace discussed above, all new resources are organized and accounted for appropriately.

Based on the profile of the user(s) in the system, CEMPs enforce compliance and security standards via locale, project assignment, permissions, and other organizational characteristics. For example, CEMPs can enforce a GDPR compliant architecture for a developer ordering infrastructure assigned to a Customer Relationship Management (CRM) project working with clients in the EU by deploying an infrastructure resident in an EU region datacenter.

To support accounting and billing services, CEMPs aggregate costs and monitor/meter usage to adhere to budgetary restrictions. With costs properly accounted for, internal chargeback/show back, or customer billing, can be automatically reported directly to the responsible financial/billing systems. Advanced CEMPs allow for the implementation of detailed price books that aggregate—in addition to raw cost of services from a cloud provider—labor costs, software costs, and other contributing costs for delivering digital cloud products. For MSPs, these price books may include additional markup on products and services establishing an MSP monetization platform.

CEMP High-level Architecture

The diagram below provides a high-level conceptual architecture of a CEMP platform. The diagram depicts high-level architectural components and describes critical supporting functionality including UX Portals and Microservices. For this paper, we will focus on the importance of UX Portals and Microservices.

UX Portals

The platforms consist of a UX layer to provide different views and the capability to support various user personas within the enterprise cloud ecosystem. These “portals” commonly include (at a minimum) a storefront or marketplace experience for end users, governance or compliance portals for operations personas, and an administrative portal system/app managing users and developers.

In line with the low-code / no-code expectations of a CEMP, user experiences (UX) need to be highly configurable (no-code), customizable (low-code), easy to manage, and easy to deploy. Advanced CEMPs (resembling leading PaaS like Salesforce or ServiceNow) provide no-code, WYSIWYG tools to “configure” a user interface. To accomplish this, the CEMP will have a designer or studio palette to drag-and-drop user interface (UI) building blocks on to a page and configure them with metadata fields. This UX builder will provide enterprises and MSPs the ability to white label the application with their brand specifications and resources (logos, styles, colors, fonts, etc.). To accomplish this, advanced options should be provided in the form of low-code customizations. As configuring users make no-code and low-code changes to these interfaces, the experiences are instantly available with a simple refresh of a browser window without any lengthy code deployments, staging, or promotions.

Microservices

We have discussed the importance of separating CEMP software into two parts: cloud agnostic software and cloud vendor-specific software; providing a modern microservices architecture is imperative to achieving this. Leading CEMPs abstract cloud agnostic capabilities into a set of platform microservices and build integration microservices to support vendor-specific services. The diagram above shows many of the management and supply services outlined in the Open Group’s cloud ecosystem reference model as vendor agnostic microservices. In contrast, you can see vendor specific integration microservices (summarized into cloud, development, and operations) to support and leverage key provisioning, operations, and governance capabilities from cloud providers and supporting ecosystem tooling (i.e., configuration and monitoring tools, etc.)

Again, given the importance and wide variety of the integrations needs of cloud ecosystem management, vendor-specific microservices and their integrations need to be architected to support low-code rapid onboarding extensible and consumable via a well-documented SDK.

Through Cloud Provisioning, Operations, and Governance, CEMPs can transform the way enterprises and MSPs deliver and manage cloud and digital products. CEMPs aim to provide a centralized suite of services that realize many of the requirements outlined in the Open Group’s Cloud Ecosystem Reference Model. Enterprises and MSPs implementing CEMPs are reducing costs and dependence on human resources, productizing cloud service delivery, and innovating faster than their competitors. In the next section, we take a closer look at the benefits of CEMPs and their impact on IT and cloud ecosystem marketplaces.

Cloud Ecosystem Marketplaces

Since the creation of the NIST Cloud Computing Reference Architecture [7] in 2011 and the Cloud Ecosystem Reference Model [3] in 2014, we have seen a steady growth in the adoption of cloud (or rather datacenter clouds) across the entire business spectrum—from small to medium to very large enterprises adopting cloud computing architectures, wherein many IT services are purchased as subscriptions from “cloud ecosystem marketplaces” or simply “cloud marketplaces.” Inherent in the cloud ecosystem reference model is the concept of a catalog of offers. In the enterprise context, a catalog provides an internal storefront to developers and application teams. However, when such a catalog is opened to the public it can serve as a marketplace for cloud services. In fact, AWS and many of the services offered by AWS were originally used by Amazon internally before they decided to make them available to the public. A cloud marketplace created using a CEMP represents another opportunity for MSPs/SIs.

Besides cloud marketplaces owned and operated by hyperscalers, there can be other types of cloud marketplaces, including:

The CSP Marketplace

Communication service providers have been running and operating B2B2X marketplaces with a heavy focus on IoT and edge computing, including compute, storage, and networking.

The ISV Marketplace

Independent Software/Hardware vendors such as Nokia Networks, Oracle, Ericsson have created marketplaces for software-based networking services, IoT services, and edge computing services, like CSP marketplaces.

The MSP/SI Marketplace

Companies, such as Accenture, Infosys, Wipro, and Cognizant, with decades of systems integration experience can become telecom marketplace owners/operators as they are often seen as neutral third parties by CSPs and ISVs.

As enterprise cloud architectures and cloud marketplaces took off, CSPs took notice. To avoid becoming providers of dumb communication pipes, CSPs and their network equipment vendors adopted cloud native computing principles, software defined networks, and agile software delivery models for network services. This, coupled with the advent of IoT and 5G, gave rise to the creation of edge computing or edge cloud where compute, storage, and software defined networks support a myriad of latency sensitive workloads such as AR/VR, self-driving cars, and many other applications in healthcare. Edge computing also has wide applicability in SD-WAN as more and more enterprises support remote work, especially post-COVID. The market for edge computing services has experienced significant growth in the last few years, and coupled with datacenter clouds services, it is driving many new innovations in the industry. In fact, Gartner predicts that more than 50% of enterprise-managed data will be created and processed outside the data center or cloud by 2025 [9].

Like the cloud marketplaces created by hyperscalers, CSPs and Network Equipment vendors have also been attempting to create telecom cloud marketplaces where both edge and datacenter cloud services are offered. Communication service providers have been running and operating B2B2X marketplaces with a heavy focus on IoT and edge computing. Examples include: AT&T IoT Marketplace, Axiata Group, Claro Enterprise Solutions, NGENA, T-Mobile IoT Marketplace, Vodafone Business Marketplace, Telefonica, Telus, and Verizon. Network equipment vendor marketplaces include Nokia’s Data Marketplace, while ISVs like Oracle have the Oracle Cloud Marketplace and Oracle Data Marketplace. However, such marketplaces have achieved limited success when compared to hyperscalers. The issue has been that CSPs want to continue to own the customer relationship by owning and operating such marketplaces, however, it is not a natural cultural and business fit for CSPs to be operating marketplaces. Similarly, network equipment vendors and ISVs also suffer from the same types of issues—it is not a natural fit for their business.

Telecom open marketplaces are now a unique opportunity for MSPs/SIs [8] representing the majority consensus amongst ISVs and CSPs. Extensive systems integration experience and deep vertical expertise in telecom positions MSPs/SIs as ideal candidates to build telecom marketplaces. The idea is that an MSP/SI can create an open marketplace for cloud services, including edge cloud services (from CSPs) in the catalog. Since the CEMP catalog is service agnostic, it can grow into a more diverse collection of services, over and above cloud, such as connectivity services, IoT Services, and more. However, for anyone outside the top five systems integrators, the challenge will be name recognition; if they can overcome that by focusing solely on telecom along with the time to market advantages offered by a CEMP, they could succeed. However, CEMPs will need to add support for ecosystem partner compensation, revenue management, and settlement while the MSP/SI will also have to focus on executing partnership contracts.

Recipe for Achieving Scale & Differentiation

MSPs in the cloud business support a wide range of different customer use cases. The AWS MSP partnership brochure [10] published by the APN (AWS Partnership Network) organizes these uses cases into the following categories:

Application development, management, hosting, and modernization

Digital transformation

Systems integration

Managed security

Not all MSPs support all use cases, but we believe that MSPs can leverage a CEMP to accelerate most of these cloud use cases. Other than application development itself, a CEMP can help accelerate some aspects of all other use cases. For example, systems integration, which is a broad category, can benefit from the advanced integration automation capabilities of a CEMP. However, first and foremost MSPs must move from project thinking to product thinking with a focus on offering their customers software-based capabilities that can accelerate the customer’s product lifecycle. The diagram below illustrates these ideas.

References

Cloud Managed Service Market, Contrive Datum Insights Pvt. Ltd., January 19, 2023, Link: https://www.globenewswire.com/news-release/2023/01/19/2592073/0/en/cloud-managed-services-market-is-expected-to-reach-around-usd-145-6-billion-by-2030-grow-at-a-cagr-of-13-40-during-forecast-period-2023-to-2030-data-by-contrive-datum-insights-pvt-.html
A Digital Product-Centric Reference Operating Model, The Open Group White Paper, October 12, 2022
“The Open Group Cloud Ecosystem Reference Model,” Open Group Standard, Document Number C141, January 2104
The Shift to Digital Product, A Full Lifecycle Perspective, The Open Group White Paper, Mark Bofman, ServiceNow and Dan Warfield, CC&C Europe, December 2020
Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, Mik Kersten, November 20, 2018
Flow Architectures: The Future of Streaming and Event-Driven Integration. 1^st Edition, James Urquhart, O’Reilly Press
NIST Cloud Computing Reference Architecture, Special Publication 500-292, Recommendations of the National Institute of Standards & Technology, September 2011
Exploring Marketplaces for Software & Services, Tim McElligott & Dawn Bushaus, TM Forum, June 2021
Gartner Research via TheFastMode.com, “Companies Leave the Cloud in Favor of the Edge in 2023” by Michael Clegg, January 19, 2023 Link: Companies Leave the Cloud in Favor of the Edge in 2023 (thefastmode.com)
AWS MSP Partner Competency Brochure 2021: https://d1.awsstatic.com/partner-network/AWSMSP_PartnerCompetencyBrochure.pdf