Principles of Ecosystem-Oriented Architecture
Author's note: This work on Ecosystem-Oriented Architecture is the product of several years collaboration with my wife and business partner, Ana Welch. LinkedIn articles don't make room for co-authors, but you should consider us to be. She's one of the world's true technical experts in this field.
Think back to the dawn of the consumer internet. An era that - for those of us who were around to experience it - recalls memories of Netscape and the horrid buzzing of a dial-up modem. The year was 1996.
Then there was “Web 2.0”, a phrase that sounds almost silly to say, now. This marked our transition from words and images on a “page” to pages with which we could more readily interact. The origins of the modern web app. The year was 2004.
The early to mid-aughts gave rise to the public cloud, to our long (and still underway) transition to globally scalable platforms including Azure and AWS, away from the on-premises computing infrastructure upon which we had relied for decades. Let’s call it 2014.
Platform-first technologies like Power Platform began to emerge in 2019 (we called them “application platform as a service”, or “aPaaS”, back then), followed by generative artificial intelligence in 2022. We spent 2023 gasping for air. Catching our breath. Wondering how we might set ourselves up for the next wave.
Notice the timeline.
We were working with eight to ten years between major disruptions from the dawn of the consumer internet. But these “wave periods”, that is, the time between the crest of two waves, have shortened to three to five years since the rise of the public cloud. It makes sense: As the evolution of computing technology and capacity picks up steam, it similarly accelerates. Innovation begets innovation. Generative AI was only made possible by the incredible computing power and connectivity available in the cloud. Now, AI is further accelerating this pace of change, shortening the time we have available before new waves crash upon the shore.
The grace period for organizations to get their act together and position themselves for the next wave is growing much shorter; the margin for error is much narrower.
When I think about the non-technical barriers that so many organizations can’t seem to get over when it comes to platform-first, I really wonder how many will miss out on the AI wave because they lack the wisdom or the willpower to make the most of it.
Accelerating wave periods present challenges to even the nimblest of organizations. They will absolutely wreck more traditional organizations that have hitherto been anchored in careful, deliberative decision making, multi-year budget cycles, and lengthy software implementations. Public sector agencies and "big, venerable institutions" are at particular risk.
What is Ecosystem-Oriented Architecture?
The ”cloud ecosystems” being developed by the organizations that are leaning into this transformation - which is to say, the organizations that will survive and thrive - rise to the occasion of these accelerative trends while solving significant problems faced by organizations across industries and around the world.
Antiquated and disconnected systems lead to poor employee satisfaction, even worse customer outcomes, and a persistent inability of organizations to extract value from their data even as their technical debt make them more expensive to maintain over time.
Monolithic “point” solutions such as ERP, HRS, and CRM: Costly, inflexible implementations that do not age well, nor can they be easily replaced because doing so risks toppling an organization's entire IT tower, which in turn further drives up the cost of the alternative.
Incredible levels of risk incurred as organizations seek cheaper workarounds to their monolithic point solutions, often finding “solutions” such as the “SharePoint app” or the “Power App built with SharePoint as its data store” (because “the licenses were, err, seemed free”) whose apparent cost savings have been seductive, but which have ultimately led organizations to expose massive amounts of their data stored in unsecure locations.
I’m going to linger on that last thought, because I cannot make this point enough.
Organizations that have overbuilt using SharePoint or Excel spreadsheets as a data store have exposed themselves to perilous risk. SharePoint and Excel hydrate an organization’s Microsoft Graph with data. AI workloads such as Microsoft 365 Copilot reason over this data. I implore you to not be the organization that learns this lesson the hard way. Think of Microsoft Graph as a central hub that organizes and connects data from across Microsoft 365 services, including data from SharePoint lists, Excel files, Teams conversations, OneDrive, Outlook, and more. An interlinked productivity data network allowing you to pull data from different sources, like files, messages, or tasks, and use it seamlessly in your apps.
Ecosystem-oriented architecture (EOA) presents a future-ready path forward, allowing organizations that embrace it to more readily absorb successive waves of technological change in artificial intelligence, data, and beyond. EOA calls on these organizations to move their monolithic point solutions from the center of their architecture to its outskirts, place data at the core of their cloud ecosystem, and adopt composable development approaches such that when one workload is added or removed, the rest of the ecosystem continues to function and evolve.
Understanding ecosystem-oriented architecture requires one to fundamentally shift their thinking away from legacy information technology and software implementation practices. It is a shift that forces decision makers to fight their urge to resort to scattershot methods to resolve seemingly urgent problems, and instead keep a holistic view, forcing even the smallest changes into a repeatable pattern.
Perhaps the most important idea that you will take away from reading this piece.
So, ecosystem-oriented architecture is an architectural approach integrating technologies across an organization’s entire cloud estate, prizing flexibility, the adoption of new tech, and thoughtful application of the principles of EOA that we will discuss next.
Principles of Ecosystem-Oriented Architecture
Let’s explore the core principles of EOA. Think of these principles as “lenses” through which ecosystem architects, technical leaders, and decision makers should consider their architectural choices and investments. In other words, the best ecosystem architects will consider thoughtfully and apply these principles consistently across the organization’s entire cloud estate or ecosystem. This application will often require tough decisions, and while success is unlikely to be found in their uneven or incomplete application, we ought to acknowledge that budgetary, technological, organizational, and even political constraints are likely to prevent purity on most organization’s journey transitioning to a complete EOA. But that’s okay. As you will see, a cloud ecosystem evolves over time. It is not a big bang that happens the night you go live.
The six principles of ecosystem-oriented architecture.
Principle of Platform-First
The core platform elements must come first, even though it makes the first workload expensive.
Imagine an organization that has spent years in a hybrid cloud and on-premises situation. Perhaps there’s an aging on-premise enterprise resource planning (ERP) solution in place to manage the finances, an even older human resources system (HRS) that bedevils the HR division and colleagues alike, and customer relationship management (CRM) functions handled solely in Excel spreadsheets owned by individual teams and compiled to produce reports when the boss asks for them. Now, an upcoming modernization program that you’ve been budgeting for two years calls for moving that ERP to a modern, cloud-based solution. The “old way of doing things” would be to stand up the minimal cloud infrastructure (could be IaaS, SaaS, PaaS; the particulars don’t matter right now) required to support the new ERP, develop and deploy the workload, and call it a day.
But implementing a workload before you’ve built the core platform services on which the workload (and those that follow) relies is like buying an expensive living room set before you have a home to put it in. Yet, despite this obvious analogy, organization after organization - and consultancy after consultancy with which they partner - have a nasty habit of skipping the foundation, skipping the home construction, and going straight for the living room set.
Our Principle of Platform First calls on us to acknowledge that EOA often means higher up-front costs followed by dramatically reduced costs for future workloads. This is because the early workloads are often built in parallel to the cost of building the ecosystem's foundational elements that, once built, offer “composable” components that are reused again and again. EOA is designed to be open and transparent, allowing organizations to actively participate in its development. Its modular nature means it can be tailored to fit specific needs, and most importantly, it empowers organizations by giving them control over their technology, rather than having technology imposed on them.
Ensure that you allocate your “year one” budget accordingly, so that you don’t spend so much on the sofa and lamp - your ERP, HRS, CRM, etc. workloads - that you neglect the core platform, integration, and data distribution services that drive the most value from your ecosystem in the long-run.
Principle of Composability
The whole ecosystem is greater than the sum of its parts. Modularize workloads to be added or removed with little impact to the whole.
Gartner popularized the idea of composability - that is, “creating an organization made from interchangeable building blocks” - several years ago.
I wrote earlier how former eras of IT were filled with examples of architectures that placed mammoth ERP solutions in the center of the estate, and treated any further workload as an extension of that ERP system.
The age of ERP at the core of an organization's IT estate is over.
Composability calls on us to invert this thinking, beginning instead with core platform services, integration, and data distribution, and placing those services at the center or our ecosystems. ERP then becomes a node, albeit an important node, just a collection of workloads alongside any other core business system.
I could have called this the Principle of Keeping the Core Clean, wherein we implement core business systems such as ERP with as little customization as possible, let it do its thing, certainly do not try to shoehorn in functions for which it was not designed, and then build composable solutions using mastered and integrated data to meet the organization’s more unique needs.
EOA requires us to modularize individual workloads so that they are, individually, more flexible, more easily customized, and even retired when no longer needed, then assembled in such a way where the organization relies on the ecosystem as a whole to do its heavy lifting, rather than on a handful of monolithic apps.
Principle of Evolution
The ecosystem need not be fully functional on day one to be viable. Avoid lengthy “analysis”, do what you must to get started, then go from there.
How many times have you seen an organization spend years getting ready to build something - scoping out an immense technology initiative, gathering requirements, researching possible solutions, budgeting, requesting proposals, awarding contracts - only to realize that the thing everyone thought was needed three years ago is no longer fit for purpose?
The Principle of Evolution suggests that we allow the ecosystem to evolve with the organization’s needs (and its budget), rather than mapping out every minute detail of many specific workloads. I'm not advocating unchecked experimentation here, rather that we guide the ecosystem’s evolution with principles and desired outcomes rather than years’ worth of accumulated requirements.
This principle is like that of the “minimum viable product” (MVP), which has been floating around for many years. Swap “platform” in place of “product” and you have the idea. Too often architects, particularly those grounded in the art of implementing big point solutions, get hung up with the inner workings of core business systems and fail to see the forest for the trees. Months or even years are spent discovering, analyzing, designing every bit of minutiae functionality associated to specific workloads.
Evolution challenges us to first build the core platform services required across the ecosystem, deploying alongside this one or a handful of workloads that strike a good balance of providing value to the organization but without being so complex that they take years to deploy. Then go from there.
You may be tempted to think that this is a too big of a change for many organizations, but the risk reduction quality of this approach says otherwise.
Principle of Restraint
Not all data or application functionality is needed everywhere or in real-time. Be discerning between what you could do and what is needed.
If I have a dollar (or a euro, pound, lei, etc.) for every time someone has insisted to me that something simply had to be real-time…
Many will have worked with architects who lack this restraint. When given a choice between technologies, they’ll always choose the one with the most features, the newest technology, the data insights produced in real-time, etc. This reflects point solution architecture and task-based thinking where the purview of the architect ends at the bounds of their own solution. But it is antithetical to EOA where the results of a system-based ecosystem working as one are far more important than the task-based outcome of any single workload.
Let’s briefly consider that common scenario of real-time data analytics. Many organizations struggle with data latency in legacy analytical workloads, but when pulling back the curtain here, we find that we’re talking about days between data collection and data visualization. Building a data platform that reduces this latency to hours is sufficient, simpler, and cheaper in many cases. In other words, if we can improve data latency from days to hours, is real-time truly necessary? It may be, but you are wise to take the decision thoughtfully before committing to often more costly real-time integration.
The principle of restraint challenges us to discern the difference between what we could do and what is actually needed in the context of the ecosystem and the business need.
Principle of Artistry
Many ecosystems look alike in their common elements. Artistry is in how these are combined in practical terms for the organization and industry.
The principle of artistry was not obvious until after our notional “Reference Ecosystem”, which I will discuss in a later article, had been applied to various organizations across different industries. “Ecosystem maps”, as we call them, looked very different in the early days of my work with EOA. Over time, as the Reference Ecosystem improved, however, we began to see ecosystems looking more and more like the composite.
I have found that cloud ecosystems across different organizations share much in common. Nearly all of them are built with some selection of the same core platform services such as Microsoft Purview for data governance, lineage, cataloging, etc. Nearly all of them contain some combination of event, logic, and batch integration services. And most organizations rely on vendor variations of the same set of core business systems.
The ”artistry”, therefor, is in combining and prioritizing these technologies to support different aspirations and to achieve different outcomes. For example, a public sector agency may be tracking the organizations it regulates and any enforcement actions, healthcare institutions must generate and prioritize clinical care needs, law firms focus on client acquisition and case management, military and defense organizations are concerned with the people and supplies deployed to far-flung places. The list could go on.
These are, of course, very different problems to solve. However, by rigorously applying the principles of EOA, focusing on data with composable applications built atop that data, and avoiding one-size-fits-all monolithic point solutions we can inject the “artistry” into combining various technologies to produce the fit-for-purpose solutions that are needed.
The principle of artistry challenges ecosystem architects to use similar paint colors (the underlying technical services) to paint ecosystems that match the mood of their organization’s aspirations and desired outcomes.
Principle of Following the Money
Technology vendors like Microsoft focus their investments on what they believe are the technical capabilities of the future. Hitch your wagon to these.
We’re not talking about broad technology categories such as “AI”, “data platform”, or “low-code” (a phrase that I abhor). No, the principle of following the money leads you to very specific technologies with which you should be building your cloud ecosystem.
EOA really began to ignite as a concept in 2023, which happens to be the year in which Microsoft announced its “Fabric” data platform capabilities. This proved a perfect example of the Principle of Following the Money, wherein one was able to place bets in the form of investment and upskilling on technologies where Microsoft was itself investing. At the time of writing, Microsoft technologies such as Fabric, AI Search, and Dataverse were the recipients of significant investment, which in turn leads to the conclusion that these are ideal technologies upon which ecosystem architects can rely for the foreseeable future.
Perhaps a better example from this era is Microsoft Purview, which, while lacking the marketing investment that Microsoft has made in technologies like Fabric and Power Platform, has nonetheless quietly become Microsoft’s one-stop-shop for data governance.
Though it is impossible to guarantee that any technology will live forever - because no technology really will, at least not in its current form - the principle of following the money suggests that we are best served to learn and construct future-ready cloud ecosystems that rely on technologies where Microsoft (or your preferred cloud technology vendor) is investing heavily today.
I will explore these principles, their application, reference architecture, and real-world examples of ecosystem-oriented architecture in future newsletters.
Until then, remember:
“Wave periods between major innovation in the cloud are growing shorter. We no longer have the luxury of waiting it out, of adopting later. Cloud ecosystems built on strategic foundations create the conditions to absorb successive waves of change.”
