Industrialization of IT with Value Chain Partnerships in Cloud

At the time when cloud computing was new, it emerged in a space that was quite distant from enterprise software. It started with strong emphasis on the notion of Infrastructure-as-a-Service. Over years, the concept of as-a-Service expanded to cover other upper layers all the way to Software-as-a-Service. Even when that happened, cloud service providers (CSPs) acted also as the software vendors of the software they provided as a service. They needed to include open source software services later to attract more adopters. With the increased interest of enterprise clients in cloud, CSPs had to partner with key Independent Software Providers (ISVs) to address the needs of their clients. Whether that represented existing client base of ISVs or newly introduced by CSPs to new clients, underlying demand existed and became evident enough to trigger such partnerships in support of enterprise client needs. Examples of those are early ones from VMWare on IBM Cloud, AWS, and Azure. Later examples are SAP on IBM Cloud, AWS, and Azure. More recent examples include clearer distinction between the role of CSP and ISV even when a company plays the two role. For instance IBM Cloud Pak for Data on Azure and IBM Software as-a-Service on AWS in which AWS and Azure cover the CSP part while IBM is the ISV giving more options to enterprise clients.

It is obvious from the examples provided above that they are all about hyperscalers which leaves a humongous gap in the market to be covered by other CSPs. Local and regional CSPs have been a round for a long time, but now they started to gain more space and power due to regulatory or geo-locational preferential advantages. ISVs can easily work with a handful of hyperscalers to make ISV software products available on their cloud, but would ISVs have enough capacity to deal with a large number of local/regional CSPs in a similar way?

Industrialization of IT has been a topic of interest in enterprise cloud adoption for the past decade. "Industrialization in Cloud Computing with Enterprise Systems" is an informative paper published in 2015 to describe Order-to-Cash automation for SaaS products. The paper looks at cloud services as products in an Enterprise Resource Planning (ERP) sense. This is a common approach that is associated with the concept of "Industrialization of IT". Dealing with cloud services as products is commonplace when a Cloud Operation Model is discussed. McKinsey's article "Building a cloud-ready operating model for agility and resiliency" in 2021 listed "Design infrastructure services as products" among the top four components of a cloud operating model. Both publications mentioned above provide very useful insights on the topic.

Productized cloud services allows for streamlining their production assembly line among different suppliers. In our case, ISVs "manufacture" software and CSPs do the packaging, as well as post-production activities such as order management and fulfilment. It is about standardizing how ISV software gets served on the cloud of any CSP that complies with certain specifications. It works the same way as components contribute to the final complete product which allows ISVs to make their software available on multiple clouds with minimal maintenance effort. It also opens CSP up to more software from a wider variety of ISVs to meet the requirements of their clients. Integrated processes and compatible specifications are necessary for such a model to work. This part can be better discussed as a cloud operating model topic.

There are four areas of consideration when it comes to productizing software in the form of cloud services. Those are related to organization, sales, operations, and technology.

1. Organizational considerations

Sponsorship of the partnership

Presence of strong sponsorship of the idea of partnership between ISVs and CSPs is essential for the whole partnership to work. There are a variety of topics to be discussed and agreed between the two parties. Sometimes it becomes a challenge to get the right level of traction from stakeholders without having an interested, engaged, and influential sponsor. This equally applies to both parties. Identification of sponsors imply presenting them with goals (and may be specific targets) of the partnership to get them interested. More on goals is discussed later under "Sales considerations".

Product management structure

On the ISV side, you would expect to find product management discipline in place for their software product. When that software product becomes a cloud service, it actually becomes another product that has specifications beyond those of the original underlying software product. Therefore, the cloud service product needs product management on its own. Common team structures to serve this purpose are squads for individual products and guilds for cross-product or common elements. Such teams can be formed out of members from the ISV side and the CSP side to have a complete coverage of knowledge and skills. Both sides are expected to provide feedback to their colleagues beyond the partnership to improve original ISV software product and CSP capabilities to host it.

Support model

The support model for the cloud service product needs to cover elements related to underlying software product, hosting cloud, and customizations made to make the service work. Having a responsibility assignment matrix to determine the areas covered by each party is needed to organize team work. Support can be part of product management structure, but it needs to exist even if partners decide to go without a product management structure. End-user experience is another important aspect of the support model as it reflects how things work when that end-user raises a ticket. More about this is discussed later under "Operational considerations".

2. Sales considerations

Promising sales prospect

This could be the most compelling motivation for a partnership between an ISV and CSP. There should be a potential benefit for both sides. At the very least, a CSP would give more retail outreach to software products of the ISV while the ISV would enrich the service catalog of the CSP with more software capabilities. Both of them can be the entry point to new or existing clients based on that partnership. The combined value of the cloud service product needs to be studied in light of market opportunity and potential target client list which can be the basis for setting the goals of the partnership. It is worth mentioning that sales prospect should be updated as the cloud service product evolves based on feedback from the field and other technological or business enhancements to it. Better tuned products are expected to drive more sales.

Pricing model

This part is usually fairly easy to deal with on the CSP side as they are already in cloud business by definition. ISVs should be able to support a pricing model that it cloud-ready. That is something that can be easily measure and charged in a cloud environment. Subscription licenses are common in this space due to its ease of implementation, but there are other usage-based schemes that are also viable and popular.

Business development, marketing, and sales

It is recommended to have a signed agreement to formalize key aspects of the partnership. This includes responsibilities of each party in business development, marketing , and sales. The choice can be made on a range of patterns of collaboration from separate execution with integration at the data level between the parties to fully-integrated operations in which each party plays a role. Depending on the strength of the ISV's brand and level of interest in participation, software product white-labelling could be an option, too. The choice of the shape of the partnership may require building skill capacity on either or both sides regarding other party's capabilities or operations to be able to take over their responsibilities in the partnership.

3. Operational considerations

User experience

User-centric design is a fundamental best practice to be considered while designing a cloud service product. One of the main personas would be end-users representing the client. The more we make their experience self-driven, seamless, and streamlined, the more it becomes compelling to them. Other important personas would be those who work on the ISV and CSP side to make things work throughout the life cycle. Automation and integration can play a significant role to implement and improve desired user experience. User experience is a cross-cutting consideration that has touchpoints with other areas such as sales and support.

DevOps and site reliability engineering

It goes without saying that DevOps and SRE practices are core to implement a productized version of a cloud service. They both play a major role in automation and integration of the work from different collaborating teams. Even more importantly, they allow for faster application of feedback from the field to improve the product itself. This is also applicable to faster response to product support tickets. An important aspect to mention here is observability since it is typically required to helps CSP to deliver against Service Level Agreements (SLAs). All of that may require arrangements between the ISV and the CSP to agree on how to integrate their tools and processes.

Order management, fulfillment, support, usage/adoption, and inter-company settlements

This is a collection of topics that are essential for the partnership to work. If we take support for instance, the use of support ticketing system is highly recommended to enable the flow of tickets between parties. This may require integration between ticketing systems used by ISV and CSP. The same thing applies to how orders are placed, tracked, and fulfilled. It also applied on how money flows to the different pockets of the ISV and CSP when a sale is closed. Another important aspect is the ability to observe whether and how client is actually using the service they purchased. Such observation may trigger a variety of customer success activities including enablement and deployment support.

4. Technology considerations

API-manageable product and platform

Automation and integration were mentioned more than once under different sections of this article. It is important for the software product and the cloud platform to be manageable through APIs. Partial API product and platform coverage may result in lack of streamlined operations and possible cloud service product limitations.

Hybrid cloud architecture and multi-tenancy

Many enterprise clients find value in hybrid cloud as it gives them the freedom of data and application placement. Having support for such an architecture opens the door for moving traditional clients of ISV's software products from traditional deployment to cloud in a safe and compliant way. On the other hand, multi-tenancy is another architectural aspect that need to be technically resolved between the partners. Luckily, some software products were originally designed for cloud and take multi-tenancy into consideration already. Others do not provide such a support. In that case, the cloud service product may rely on the CSP's platform capabilities at the infrastructure level to provide necessary segregation among tenants.

Metering mechanism

Pricing model and operational aspect were discussed under their respective sections of this article. Metering is about converting sales into actual revenue in support of given pricing model and service usage. Both the software and the hosting platform should be able to support the ability to provide metrics which can be translated into metering information. Another important aspect is about which parties will have access to metering information and whether ISVs and clients would be able to see the breakdown of usage in addition to the CSP.

A final note on planning and execution

Just like most of cloud adoption topics, it is advised to have a roadmap with milestones representing an incremental approach showing value along the way till the final goal is reached. This is important for sponsor to monitor the buildup of value while allowing builders to assess the outcome of their recent build. Planning Minimum Viable Products (MVPs) and Proof of Concepts (PoCs) as part of the activities would enforce incremental and iterative aspects of the roadmap.

Conclusion

All of the considerations mentioned in this article can serve as a source of inspiration for developing a successful partnership between CSPs and ISVs to serve their clients. Most of those considerations trigger a variety of options to choose from based on the particularity of the partnership and surrounding goals and constraints. This space of partnership is vast enough to local/regional CSPs in addition to major hyperscalers. Both ISVs and CSPs should be equally motivated to be in this growing and underserved market.