GROWING THE ECOSYSTEM

The architecture of an ecosystem can take various forms. Consider Amazon’s architecture for AWS as a first example. Its architecture was based on a stack of infrastructure, products and customer services that could underpin a variety of customer solutions. At the base of the stack is the AWS global infrastructure, which includes 44 Availability Zones that consist of one or more data centres, each with redundant power, networking and connectivity, housed in facilities in 16 regions around the world. The next level consists of foundation services: computing, storage, database, and networking capacity provided by AWS. These services are linked to a level that contains software and services, organised into five domains: client-side data, server-side data, network traffic, operating system and security, and applications. These domains could be provided by one or more external partners, with each element linked through the stack to the customer’s data using standardised interfaces and protocols. The customer buys from some mix of the AWS marketplace, professional services, consulting or technical partners, or via a network of reseller channel partners (see figure 1).

Around the stack is the AWS Partner Network that provides business, technical, marketing, and go-to-market support to help partners profit from the ecosystem more effectively. Next to that sits the AWS Marketplace, an online store that helps customers find, buy, and start using the software and services they need. Visitors can use AWS Marketplace’s 1-Click deployment to launch pre-configured software and pay for what they use, by the hour or month.

This kind of architecture enables partners to identify their optimal roles in the ecosystem, and to connect with each other, while helping customers navigate the ecosystem to find the products and services they need. It is neither a hub-and-spoke network, in which AWS would sit at the centre and orchestrate every move, nor a focused alliance, where AWS would specify roles and deliverables. In the AWS architecture, partners can come and go, re-position themselves and their relationships with AWS and other partners, even as they enable customers to assemble solutions à la carte.

ARM’s ecosystem architecture, by contrast, is not a stack, but a series of concentric circles (figure 2). At its core are around 20 strategic partners that can influence the technological direction of the industry because of their market power or technological prowess. These are mostly OEMs, such as Samsung, and chip-fabricators, such as TSMC. The quality of ARM’s interactions with them are so important to the success of its ecosystem that it assigns one of ARM’s top management team to manage the relationship. The members of ARM’s marketing team work with each partner as a sort of super account manager.

The second concentric ring in ARM’s ecosystem consists of OEMs that have less influence over the industry’s future, as well as design support and software partners that supply products and services essential to creating a new product using ARM’s IP. Among them are partners specialising in electronic design automation (EDA) tools as well as design. These partnerships ensure that ARM’s technology is compatible with any of the design options that an OEM or chip-fabrication partner might adopt.

The third ring comprises partnerships with early stage and start-up companies that are linked to the ecosystem through light touch interactions and is focused on providing them with the tools and other support needed to integrate ARM technology into their products. The primary role of these partners is to build new product prototypes that helps the ecosystem keep on innovating.

The final ring in ARM’s ecosystem architecture is home to a broader community numbering tens of thousands of developers and other participants. Their links to the ecosystem are facilitated by the ARM Connected Community website. Managed by a dedicated ARM executive, the on-line community provides free access to extensive resources for developers; a forum for developers and engineers to exchange ideas and get support in the ARM ecosystem; company and product listings classified by product category, market application, and ARM technology—all linked to partner sites.

There is no ideal architecture for an ecosystem. The right architecture will vary with the specific needs of every individual ecosystem. But based on our case studies we can make three suggestions about the architecture. First, the ecosystem leader should aim to promote an architecture for the ecosystem that combines a series of niches, each of which makes a different contribution to customer value and creates a virtuous spiral by generating new knowledge or additional demand as they interact. Of course, each ‘niche’ may be large in terms of volume and revenues and may also contain many partners. Competition within each niche may generate benefits for the ecosystem by encouraging rivals to improve efficiency or drive innovation. Second, overlaps between the ways in which each niche contributes to the value that the ecosystem delivers are likely to be detrimental to the ecosystem’s performance. That is because the interfaces between the elements will become blurred if the niches overlap. Uncertainty and confusion will result. The ecosystem leader’s aim, therefore, must be to develop a structure where each bundle of value-creating activities is clearly delineated from the next.

Third, to enable the ecosystem to scale, the jigsaw of niches must be complete. All the tasks and capabilities that are necessary to deliver value to the customer need to be covered. This may seem obvious, but critical gaps can sometimes be overlooked.

Next section – #2 – Protecting partners’ turf

Previous section –  Proposition 6 – Look for partners that can bring their own ecosystems

Back to Outline