Ecosystems
Your architecture lives in a wider habitat of partners, vendors, regulators, and standards — design for the whole of it.
To an executive
Your results depend on suppliers, partners, communities and regulators you do not control. Watching their health, and making yourself easy to work with, reduces surprises.
To an engineer
Map the external parties your system relies on, and make integration with you simple. Track vendor changes, licence shifts and regulation so you can adapt before they bite.
The idea
In ecology, no species exists in isolation. Each depends on and shapes its environment, and the loss of one can unsettle the whole.
Marco Iansiti and Roy Levien applied the idea to business: a company's performance depends on the health of its business ecosystem, the loose network of suppliers, distributors, outsourcers, makers of related products and technology providers around it. Enterprises also sit inside open-source communities, marketplaces, standards bodies and regulatory regimes. Architectural choices determine how easily you can take part, and how exposed you are when the ecosystem changes.
Why it works
You depend on more than you control. Most of an enterprise's stack, data flows and distribution run through other organisations. Seeing them as one system shows the real risks.
Ease of participation compounds. Partners build on whoever is easiest to integrate with, which brings more partners.
Ecosystems change on their own schedule. A vendor acquisition, a licence change or a new regulation can reshape your options overnight. Watching for it gives you time to respond.
Where it applies
- Partner and API strategy, deciding how external parties integrate and what you expose.
- Vendor and open-source risk, assessing the health of the suppliers and projects you depend on.
- Industry standards and regulation, such as open banking or e-invoicing, which define how the ecosystem connects.
- Operating model design, where parts of the value chain are run by partners.
How to apply
- Map the ecosystem: who you depend on, who depends on you, and which standards and regulators shape it.
- Assess health of key dependencies: vendor viability, community activity, licence terms and concentration risk.
- Favour open standards and well-documented APIs where you want others to participate.
- Treat partner onboarding as a product, with documentation, sandboxes and a measured time to first integration.
- Contribute and monitor, so changes in the ecosystem are seen early.
Example scenario
A payments company had grown through bespoke integrations, each negotiated and built by its own team. Every new partner took months, and the backlog of integration requests kept growing.
The architects redesigned the partner interface as a product: a clean, documented API with a sandbox and self-service keys. Third parties began building integrations on their own, creating distribution the company could not have built alone, and the integration team moved from building connections to supporting the ecosystem.
Questions to ask
- Who outside our walls depends on, or contributes to, this system?
- How healthy are the vendor and open-source ecosystems we depend on?
- How easy are we for a partner to integrate with, measured in days?
When not to use it
- Internal systems with no external parties, where ecosystem thinking adds little beyond normal dependency management.
- Highly closed, regulated environments, where participation is fixed by contract and openness is not an option.
How it misleads you
Depending on an ecosystem without contributing to or monitoring it, then being surprised when it changes. The opposite failure is building ecosystem infrastructure, such as marketplaces and developer portals, before any partner has asked for it.
Further reading
Last reviewed · Suggest an improvement