When Every Vendor Wants to Be Your Platform

I saw a recent Databricks announcement that made me think about something much bigger than Databricks. Meta's Ads MCP server is now available through Databricks, which means a marketer can potentially analyze campaign performance, combine that with enterprise data, and take actions on Meta campaigns without really leaving the Databricks environment.

That is interesting by itself, but what I found more interesting was the question behind it: where is work actually supposed to happen now?

Take the marketer in this example. Should they work in Meta because that is where the advertising runs? In Adobe because that is where much of the marketing workflow already lives? In Salesforce because that is where customer context lives? In Databricks because that is where enterprise data and AI live? Or in an AI assistant sitting above all of them? You can make a reasonable case for every one of those answers, and that is exactly what makes the problem interesting.

This is not really a marketing problem. The same thing is happening across enterprise technology. Data platforms are adding applications, agents, workflow capabilities and operational features. CRM platforms are becoming data and AI platforms. Productivity suites are becoming AI platforms. Security vendors are moving into adjacent categories. Integration platforms are becoming agent platforms. Cloud providers keep moving further up the stack.

At the same time, companies can build more themselves than they could even a few years ago, and agents are starting to make the application itself less important as the place where people work. These are not separate trends. They are colliding, and together they are making enterprise technology architecture much harder to reason about.

Everything is moving toward everything else

For a long time, enterprise architecture had fairly understandable boundaries. A CRM did CRM things. A data warehouse handled analytics. An ERP handled finance and operations. A BI tool handled reporting. There was always overlap, but there was usually a fairly obvious center of gravity for each type of work.

That is becoming much harder to see. AI is accelerating this because a platform no longer needs to own every capability itself. It can access another system, reason over the data there, trigger actions, and bring the whole interaction back into its own interface. Standards like MCP make that easier still, because capabilities can increasingly be exposed across platform boundaries without every vendor rebuilding everything from scratch.

The result is that the same business process can now plausibly start in several different places. A salesperson may work from CRM, an AI assistant, a productivity suite, or a purpose-built application. A finance team may interact with data through ERP, BI, a data platform, or an agent sitting across all three. A developer may move between source control, cloud infrastructure, AI coding tools, observability platforms and autonomous agents that increasingly overlap with one another.

The question is no longer simply whether a platform can do something, because increasingly the answer is yes. The more useful question is whether you want that platform doing it in your environment. Those sound similar, but they lead to very different decisions.

Features are becoming less useful as a strategy

Technology decisions have traditionally involved a lot of feature comparison. Does this product support the workflow we need? Does it integrate with our other systems? Does it have the reporting capability we want? Those questions still matter, but I think they are becoming less useful as long-term strategic differentiators.

If a capability matters enough, somebody else will probably build it. Then another vendor will build a slightly different version of it. A differentiating feature today can become table stakes surprisingly quickly. We are already seeing this with AI, where vendors that looked very different a few years ago are now all talking about agents, orchestration, copilots, semantic layers, automation, governance and workflow.

This creates an uncomfortable reality for technology buyers. The feature that convinced you to choose a platform may not be differentiated for very long, while the architectural consequences of adopting that platform may last for years.

That means buying technology primarily because one vendor has a particular feature today is becoming a weaker strategy. The harder question is whether that capability belongs there in your architecture in the first place, and how difficult it will be to change your mind later.

And that question gets even more interesting because the alternative is no longer always another vendor.

And now Build is back on the table

AI coding assistants have changed the economics of building enough that some decisions that used to default to "buy" deserve to be reconsidered. I wrote about this in Build vs. Buy in the Age of AI Coding Assistants, where I argued that the more interesting opportunity is not rebuilding giant commercial products, but building smaller, purpose-built capabilities around how the business actually works.

The strategic choice is increasingly not just vendor A versus vendor B. Sometimes it is buy the commodity, build the differentiating layer, and keep the architecture flexible enough to change both.

The application itself may matter less

In The Death of the Application, I argued that applications as destinations may become less important as agents increasingly invoke the capabilities underneath them. If that happens, whether someone "works in" Meta, Salesforce, Databricks or another application may eventually matter less than the data, rules, permissions and capabilities underneath.

That shifts the competitive terrain. If applications become less important as destinations, vendors have even more reason to own the layers that agents depend on.

Every vendor has a good argument

This is where vendor convergence starts to make more sense. Each major platform is trying to expand outward from the layer it already owns and become more central to how the enterprise operates.

Your cloud provider can say more should live there because that is where your infrastructure runs. Your data platform can say AI and applications should live there because that is where governed data lives. Your CRM vendor can say customer workflows belong there because that is where customer context exists. Your productivity platform can argue that AI belongs where employees already work, while your AI provider can argue that the interface should sit above all of them.

None of these arguments are obviously wrong. That is exactly what makes the situation difficult.

I explored another version of this in The Mainframe Is Calling. As building gets cheaper and feature differentiation gets harder, one logical response for large vendors is to cover more of the enterprise. In some ways, we may be watching the rebundling of enterprise technology after decades of unbundling.

The irony is that this is happening at exactly the same time enterprises themselves have more ability to build. Vendors can build more. Customers can build more. Agents can move across systems. Everyone has more options.

Which means the scarce thing may no longer be technology. It may be knowing what you actually want your architecture to become.

Good local decisions can still create a bad enterprise

This is where things can go sideways.

One team uses a workflow feature in one platform because they already have the license. Another builds something similar because AI makes it easy. A third buys a specialized SaaS product because it solves the problem faster. Six months later, another vendor adds the same capability and an enterprise AI assistant sits across all of them.

Every one of those decisions may be reasonable. Collectively, the organization now has duplicated business logic, multiple places where permissions are managed, several ways to execute the same workflow, and no obvious answer when someone asks which implementation is strategic.

Technology sprawl is not new. What is different is the speed. AI is lowering the cost of building, integrating and automating, which also means architectural debt can accumulate much faster.

It can be harder to see too. The duplication may no longer show up as another application on a portfolio diagram. It may live in prompts, agents, orchestration layers and business rules scattered across different platforms.

The architecture can become messy before anyone realizes there is a mess.

Architecture matters more when technology gets easier

This is the paradox I keep coming back to: as technology gets easier, architecture becomes more important.

Historically, technical constraints did some of the architecture work for us. Integration was expensive. Building applications was expensive. Moving data was difficult. Those constraints forced choices because an organization simply could not do everything everywhere.

Many of those constraints are disappearing. Almost anything can connect to almost anything, and a surprising amount of functionality can be reproduced in multiple places. That gives organizations much more freedom, but it also means someone has to be much more intentional about where things belong.

Which systems are authoritative? Where should business logic live? What should we buy and what should we build? Which platforms are strategic and which should remain replaceable? What can agents do, and where are those actions governed?

The question that may matter most is what the organization is choosing not to do, even though it technically can.

That is not resistance to innovation. Too many equally valid ways of doing the same thing eventually create more complexity than flexibility. Technology strategy is partly the discipline of removing choices.

The Role of Technology and Digital Leadership Is Changing

That changes the role of technology and digital leadership. Whether the title is CIO, CTO, CDO, Chief Digital Officer, or some combination of those responsibilities, the job can no longer be just choosing technology and managing vendors. Increasingly, the job is to provide a point of view on how the enterprise should work.

Where should capabilities live? What should we own? Which platforms do we want to deepen our dependency on, and which ones do we deliberately want to keep replaceable? Where does our data and business logic belong? What should agents be allowed to do?

Those are not questions a vendor can answer for you.

It also does not require a giant architecture document or another committee. It requires a small number of principles that are clear enough to guide decisions. When a vendor launches something interesting, the organization should be able to understand where it fits, whether it belongs somewhere else, or whether it simply does not matter to the direction already chosen.

Sometimes the direction should change. Good architecture has to evolve. But it should change because something materially changed the landscape, not because a vendor had a good keynote.

This is also why strategy, architecture and governance are becoming harder to separate. Strategy says where you are going. Architecture creates the path. Governance keeps hundreds of individual decisions from quietly taking you somewhere else.

Someone has to hold the course

That is why I keep coming back to the idea of a captain of a ship. The environment is constantly changing. New routes appear, better technology shows up, vendors change direction, entire categories converge, and the cost of building something yourself keeps falling.

A good captain has to see all of that. But they cannot steer toward every interesting thing on the horizon.

Maybe the course changes. Sometimes it absolutely should. But the important thing is that the organization is choosing the direction rather than allowing product announcements, vendor roadmaps and a thousand locally rational decisions to choose it by default.

There are a few uncomfortable questions I think every technology leadership team should be able to answer. If our three largest vendors stopped telling us what the future looked like, would we still know what our technology strategy was? If building became ten times cheaper, which things would we still choose to buy? If users stopped directly interacting with many of our applications, which parts of our technology estate would still matter?

Those questions get closer to the real architecture than any feature comparison does.

Technology is becoming more capable, more connected and easier to build. That should create enormous freedom. But freedom is only useful if you know what you want to do with it.

Otherwise, an organization does not really have a technology strategy. It has a collection of vendor roadmaps.

And in a world where every vendor wants to be your platform, someone still has to decide what your platform strategy actually is.