Building a tech-services ecosystem to deliver products—not applications

IT organizations focused on building value as well as reducing costs need to rethink how they engage with their vendors.
Sidebar

IT organizations have long worked with tech providers, but technology’s increasingly important role in delivering value to the businesses—accelerated by the COVID-19 pandemic—has prompted some chief information officers (CIOs) to rethink which providers they engage with and how to engage with them. In October 2020, just 10 percent of respondents to a survey on technology identified cost savings as a top three digital priority. Three years earlier, 48 percent of the participants had said their top three priorities included “scaling down costs” (Exhibit 1). Our latest survey on technology transformations indicates a further shift toward technology delivering revenue. More than two-thirds of respondents say these change efforts have increased revenue from existing streams, and more than half say the same about the creation of new revenue streams, such as a new product line or new business.

Executive mindsets on technology’s strategic importance have changed radically during the COVID-19 crisis.
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

In the past, decisions about working with technology-service partners typically have been shaped by cost, planning, and efficiency needs. As priorities have shifted from cost management to revenue generation, we find that CIOs are increasingly looking for ways to better engage with technology providers.

According to our experience with dozens of companies, businesses can increase strategic flexibility and lower costs by combining elements of the tech ecosystem—an integrated network of providers—and enriching them with existing proprietary features and functionality. One auto manufacturer, for example, developed two provider ecosystems, one focused on digitizing its manufacturing and the other on promoting innovation for its self-driving cars. This approach has yielded recurring savings of about a billion euros.

In another example, one public-sector organization awarded a development master-services contract to four development vendors. For each phase of the program, the vendors either competed or were directly awarded small packets of work, such as front-end design services or development and testing services for each component. Over time, the strongest-performing vendors—those bringing their A team at reasonable cost—won more of the work, leading to superior outcomes. (For more details on how this approach could help achieve technology-transformation goals, see “Managing large technology programs in the digital era.”)

To capture this kind of value, however, CIOs and organizational leaders need to move beyond traditional service-provider models. While still evolving, a new model for IT sourcing through ecosystems has shown some promising and significant benefits.

From traditional sourcing management to technology ecosystem orchestration

Almost all large technology organizations work with many tech providers, integrators, and vendors—sometimes hundreds of them. While a few establish one-on-one connections with a plethora of providers, integrators, and vendors, most have one or two “anchor” service providers with long contracts that involve large volumes and costs. These anchor providers often deliver comprehensive services at the application or infrastructure layer, so all other niche providers must tailor their services to that provider. The limitation of this model is that it creates strict process and technology constraints because of dependencies on the anchor provider’s capabilities, internal road map, and openness to collaboration.

An alternative that avoids this limitation is the technology ecosystem model, which is generally built around a larger set of key providers (often about a dozen), each focusing on a specific domain or product and all of them functioning in concert. This model is based on bringing together the complete set of providers to deliver a product. It puts a premium on interoperability between providers and rests on collective accountability. When effectively implemented, it gives the business access to a greater range of capabilities and plug-and-play flexibility.

In an ecosystem, given the need to integrate providers with each other and with in-house capabilities, IT needs to shift its role from a manager of discrete services to an orchestrater. In this way, IT operates similarly to a car manufacturer, which must bring together many components. Typically, the manufacturer decides on a common standard and employs a modular design approach to link different supply chains. As an orchestrator, the manufacturer sets framework conditions and checks the output quality.

Besides involving many more providers, the shift to an ecosystem approach requires managing more granular services, especially for components that play a crucial role within the underlying business model (Exhibit 2). For most IT organizations, developing a detailed understanding of how the various components of the system need to work together tends to be a challenge, but it’s one they need to overcome.

Compared with a traditional sourcing model, a vendor ecosystem involves more providers and choices of services.
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

What’s in it for the organization

Thinking and acting in technology ecosystems delivers several benefits:

  • Innovation. Partnering with IT services providers not only frees up internal capacities but also gives IT access to expertise, experience, and ideas. For example, to stimulate innovation, Volkswagen worked closely with AWS, Siemens, and almost a dozen other partners to develop an industrial cloud platform that is open to third parties. In a traditional anchor-provider model, innovation often is much more incremental because any significant change cannibalizes the provider’s position or margin.
  • Access to new technologies and scarce capabilities at scale. With the proliferation of specialized technology-service providers, IT can access new technology, applications, infrastructure, and professional services. A large chemicals company achieved run-cost reductions of more than 20 percent while improving service levels on its ERP workloads by partnering with a specialized cloud company that focuses on highly automated cloud operating models. Many companies also leverage a partner’s experience to leapfrog painful phases of their own experimentation. In contrast, companies using conventional sourcing models tend to focus on negotiating cost reductions based on declining costs for compute and storage.
  • Reduction in time to market of new products, services, and solutions. When companies manage ecosystems well, they can work with partners in an agile way to deliver minimal viable products and integrate functionality quickly. The speed and agility of this method stand in marked contrast to the traditional approach of developing new products, services, or solutions in a dedicated environment alongside the existing provider and system landscape. Such efforts typically run into issues when the time comes to integrate them with the legacy environment to scale.
  • Increased flexibility. By signing contracts with multiple technology providers for smaller volumes and shorter durations, companies can give themselves greater flexibility, enabling them to switch providers as needed (which requires more agile procurement approaches). In contrast, companies using the typical sourcing model seek to secure discounts by signing large, long-term contracts. If done well, this approach can improve IT costs in the short term. However, companies have difficulty adjusting terms and contracts to account for any changes needed. In addition, quality and innovation issues may be more likely in the late stages of such contracts.
  • Increased stability and security. Adopting an ecosystem approach is a powerful forcing mechanism for CIOs to upgrade their security practices. When all components are modularized properly (for example, having clear business incentives per component and well-defined accountabilities) and a zero-trust environment has been established, the overall security and stability can be increased from an architectural perspective. Traditionally, companies have sought to minimize concerns by focusing on and holding accountable an anchor provider. The company then becomes increasingly dependent on that provider to manage all issues, and its own security and risk capabilities atrophy.

What it takes

Vendor management suffers if it is based on sporadic demands and ad hoc decisions. Instead, top performers deliberately develop the necessary capabilities to manage an ecosystem. Companies trying to build and strengthen this kind of orchestration muscle can benefit from the following guidelines for building and working within an ecosystem.

Think broadly about strategic issues and constraints in assessing tech providers

In reviewing the technology landscape, top CIOs start with a clear understanding of the competitive advantage they want to build, the capabilities they have and need, and the vendor costs. They are disciplined in evaluating each provider based on how well the provider delivers a capability and how well it works with other capabilities to deliver a product.

In creating a source of competitive advantage, thoughtful CIOs determine whether they can create proprietary relationships or bring the capability in-house. More importantly, they understand how a combination of providers working together can create advantage. This kind of systems thinking allows the CIO to create multiplier effects and develop a preferred solution by pulling in the best providers, rather than being tied to the capabilities of an anchor provider. When the functionality isn’t a core differentiator to the business, sourcing through a single provider or a software-as-a-service (SaaS) solution makes sense.

At the same time, top CIOs develop a more forward-looking perspective on workforce capacity so they can clearly assess need. For example, they have a clear view on which internal skills will become bottlenecks in the future, which in-house skills are difficult to obtain in the market, and how skill demand will change. These boundary conditions help guide which tech services to select.

Key questions

  • Which limitations in internal capabilities and capacities constrain the organization? Which of those do you plan to build up from your technology-service providers’ ecosystem, and which internally?
  • What technologies and capabilities accelerate your digital-transformation endeavors?
  • What are the three most important sources of value that technology-service providers in your external ecosystem can provide?
  • Which technology functionalities are the core strategic differentiator for the business, and where is standardized functionality sufficient?

Build an orchestration layer that ensures smooth integration of new services

Managing all of a company’s own and externally sourced application and infrastructure services requires an orchestration capability, which encompasses people, processes, and systems. While team makeup can vary, teams need to include architects, provider managers, business leads, and financial-operations (FinOps) experts, as well as product systems managers to meter usage, provision servers, and shut them down.

This function goes far beyond IT departments’ usual sourcing capabilities. For example, it integrates new services and functionalities quickly (such as by establishing standards for compatible data connections between applications), enables cost charging and payment allocation between internal business functions consuming services and technology-service providers, and manages overall ecosystem performance, including incident management and issue resolution.

Importantly, the orchestration layer serves as a single point of truth. That includes providing basic information on all the services in place: usage and performance patterns, such as incidents and adherence to service-level agreements; interactions, such as data flows and number of requests, between the different services; the service’s ROI to the organization, based on licenses, inquiries, user subscriptions, and so on; and cost attribution (decisions about who needs to bear the costs).

Key questions

  • How quickly can you integrate services of your technology-service providers into your own services?
  • Do you have a clear perspective of your services’ business benefits?
  • Can the majority of your services be charged by consumption?
  • How well does your incident-resolution mechanism work?

Establish governance principles and standards supporting provider interactions

Working with an ecosystem of providers requires two tiers of governance. The first one should address how vendors work with the client company. To minimize the management burden on the company, it’s important to move away from command and control to “embedded governance”—a model where clear and simple principles are embedded in the process and require less effort to monitor and enforce.

The other tier of governance needs to support effective collaboration by multiple parties. The support would include common incentives, such as binding an infrastructure-service partner and an application-service partner to overall key performance indicators on application availability; shared—and enforced—interfaces and integration mechanisms for IT-service management solutions (for example, APIs and automated testing); and clear processes for testing and releasing new functionality that has dependencies among multiple providers.

A financial-services company, for example, put in place a set of principles laying out how providers would work together, including common objectives shared by all the providers (such as installation timeline and uptime requirements). These common objectives aimed to create shared accountability and provide strong incentives for providers to collaborate on solving problems, rather than the all-too-common problem of vendors blaming each other for issues. The business also created a tracker with a single enterprise view across all initiatives for easily following progress and setting priorities, which was managed through quarterly business reviews. To support this more flexible approach, the business also started to modernize its tech stack; changes included making applications modular, installing an API manager, and instituting dynamic provisioning.

Key question

  • Which mechanisms do you have in place that enable providers to collaborate directly with one another?

Establish the enablers for a plug-and-play architecture

Effective integration of ecosystem providers requires a product and platform IT architecture that can help organize where various service providers can plug into the system. This requires a thorough vetting process to analyze the current state—that is, where external parties need access and where not, protocols for access, and so on. It also requires a managed program to transform the architecture so it has the necessary flexibility.

IT needs to put in place enablers so that this plug-and-play architecture can work. One of the most important enablers is zero-trust-based security, in which each solution is independently secure and does not need to “trust” another solution in order to function. Others are containerized code to shift workloads flexibly and a managed API environment to reduce the complexity of proliferating APIs. Just as important, companies need clear owners of APIs and data. In many legacy companies, that ownership is unclear, which hampers effective access. One telecom company standardized all its infrastructure offerings—in both its public- and private-cloud environments—to simplify how providers could access data and services.

Key questions

  • How are you ensuring that your services are exposed to and can interact with the broader ecosystem?
  • How do your cybersecurity policies and practices cover the technology-service providers and their partners?
  • Does your cybersecurity approach build on perimeter security or on the zero-trust principle?

Develop a provider integration guide

The value of the ecosystem is in being able to swap out providers, such as switching from an end-to-end owned solution stack to a SaaS solution. To avoid the need to relearn how to do it each time—and make the same mistakes—it’s important to put in place a clear and pragmatic guide on the steps to follow when substituting an existing service or integrating a new one. Many legacy organizations, in contrast, tend to have applications that are highly tailored to a specific vendor and therefore can’t be used elsewhere. Instead of focusing on how to get something up and running, they focus on contractual obligations that need to be negotiated and are rarely updated. One airline company had developed a detailed way of working with its core vendor, but when it tried to use that method with a new vendor, many elements weren’t applicable, resulting in confusion, delays, and frustration.

Companies that excel at managing provider ecosystems develop integration approaches and plans that incorporate contractual, licensing, architecture, and service aspects in a way that is easy to repeat with many providers. This includes deciding which stakeholders to involve—say, procurement, business, security, architecture, and service integration—and which principles to follow in working with each of the stakeholder groups.

Key question

  • Do you have a clearly outlined routine for the integration and exchange of services?

Transform procurement mindsets and processes to prioritize ecosystem dependencies

Procurement in many organizations is cumbersome and time consuming. That’s because the contracts with large vendors are big and last for as long as a decade, so procurement teams spend significant time trying to anticipate and minimize risk. However, contracts with ecosystem providers are smaller and of shorter duration. Therefore, procurement teams need to shift from a heavy-risk, ironclad contract mindset to one that is more fluid and enables quick changes.

Procurement also needs to shift its decision criteria. While cost and risk are still important, of course, a successful procurement function in a provider ecosystem has a much deeper understanding of technological and business-case dependencies, such as how one application provider might depend on consuming a set of services from an infrastructure provider. Organizations must consider those dependencies and ensure they are reflected in agreements.

Key question

  • How quickly can you establish the contractual basis with new technology-service providers to access their service portfolio?

Companies will survive and thrive based on the quality of their technology and tech-management practices. Only by thoughtfully engaging with a tech-provider ecosystem can IT expect to find the innovation, speed, flexibility, and value their businesses need.

Related Articles