Originally published in my LinkedIn newsletter, December 2024, and abridged here.
Author’s note: This article is next in a series, and builds on Principles of Ecosystem-Oriented Architecture: The future of enterprise cloud, data, and AI, which is the essential prequel to the below. “Ecosystem Map” is both one of the 25 dimensions of the AI Strategy Framework and a foundational concept in ecosystem-oriented architecture (EOA).
Let’s nail down these key terms, here, so that we’re clear on the differences between them:
An Ecosystem Map is a high-level architectural diagram of an organization’s cloud ecosystem, and something that every organization must create at the start and continuously evolve as they progress on their journey;
The Reference Ecosystem is a specific ecosystem map that Ana Welch and I have created as a composite of many different cloud ecosystems across many different industries.
The “City” that is your Cloud
The “map” metaphor is instructive here. It is used to distinguish an ecosystem map from the various forms of architectural diagrams, nearly all of which tend to include more technical minutiae than a typical ecosystem map. Whereas an architectural diagram provides specific parameters for specific technical solutions, an ecosystem map presents a higher-level, more visionary view of an organization’s cloud ecosystem.
To make an analogy to architecture in the physical world:
Solution architecture provides schematics — floor plan, dimensions, electrical wiring, ventilation, plumbing — from which a building is constructed;
Enterprise architecture provides plans for specific neighborhoods or systems such as a subway or electrical grid;
Ecosystem architecture and, by extension, an ecosystem map shows us the entire city.
This analogy is fundamental to understanding and practicing EOA. Thinking of an organization’s cloud ecosystem as a city, we then conceptualize the next-level-down component parts of the ecosystem as “neighborhoods” (we might have also called them “boroughs”). Cities the world over are pieced together this way: Downtown, Seaport, Southie, etc. in Boston; Greenwich, Soho, Canary Wharf, etc. in London (though you’re forgiven if you thought I was talking about New York until you got to “Canary Wharf”); Palermo, Recoleta, Puerto Madero, etc. in Buenos Aires; Norrmalm, Gamla Stan, Kungsholmen, etc. in Stockholm. The list goes on.
Each of these neighborhoods share the quality of dividing their city into smaller pieces, each often with their own distinct culture, aesthetic, and purpose.
Like cities, ecosystem maps are constantly evolving and changing. To prevent your ecosystem from becoming overcrowded, stagnant, or unable to meet the needs of its expanding ‘population,’ it’s essential to revisit, revise, and adapt your Ecosystem Map on a regular basis.
We apply this same concept to EOA, clustering technologies and workloads devoted to similar purposes into distinct neighborhoods, and tying them together with the flow of data, logic, and actions — our roads, subway lines, waterworks, electricity, etc. — to build coherent cities in the cloud.
To do this, we compared the cloud ecosystems across real-world organizations in different industries and geographies to compile their common features and best practices. We then produced the “Reference Ecosystem”, that is to say, a notional cloud ecosystem that is a composite of the cases we considered. This reference ecosystem is the ideal standard, the prototypical notion of what a cloud ecosystem might look like.
Variation surely exists amongst individual organizations and sizes, industries, geographies, and other considerations such as regulatory requirements. To compensate for this variation, we then spent nearly two years applying our reference ecosystem to real-world scenarios, testing the composite model against actual guiding principles, business objectives, and requirements. We incorporated lessons learned from these scenarios to improve and refine the Reference Ecosystem over time, and were pleased to see how durable the model really is. Indeed, over time more and more of the ecosystems we mapped began to converge on and look more like our best practice Reference Ecosystem. We interpret this as evidence of its durability and flexibility to meet the needs of various organizational profiles.

Neighborhoods in your Ecosystem Map
In general, we find that most cloud ecosystems are home to six major neighborhoods.
Core Platform Services. The infrastructure, security, governance, management, and monitoring services used across the ecosystem. Largely synonymous with a “cloud landing zone”.
Integration. Technology-specific integration services, event-driven integration, use of APIs, logic-driven integration, batch integration, and a generic master data management (MDM) solution.
Core Business Systems. The “Tier 1” business applications common in many organizations such as ERP, CRM, HRMS, etc.
Application Portfolio. May include “Tier 1” applications but often includes solutions aimed at smaller audiences or more niche business processes of the Tier 2 (”business important”) and Tier 3 (”productivity”) variety.
Unstructured Data. Services and storage for documents, files, photos, videos, etc., often housed in legacy network file storage or modern object storage.
Data Distribution. Data consolidation, and all manner of “downstream” data distribution such as search, APIs, data warehousing, analytical workloads, and use in AI-driven scenarios.
Mapping the cloud ecosystem is a key element of both your AI strategy and ecosystem-oriented architecture (which is very much built for the age of AI) because the efficacy of any AI workload is directly related to the quality of the data upon which the workload’s model is trained or augmented. Mapping, evolving, and maintaining the organization’s cloud ecosystem map provides the essential high-level technical architecture underpinning our AI strategy.
There’s a lot here, so I’ll take on the various pieces of this in future articles. Consider this your foundational introduction, though, to both the Reference Ecosystem and to ecosystem maps more broadly. Creating yours needs to feature prominently as you craft your strategy. Updating and evolving it over time is an indispensable discipline.

