AI and the Forced Platform-ization of Enterprise Software

By Deane Barker • • 5 min read •

I’ve become interested in the last few years in the “layers” in which we build, customize, and integrate software. More pointedly, I’m fascinated at how the era AI and “vibe-coding” is going to completely upend them over the next decade. The current “us vs. them” perspective of software development is never going to be the same.

Back to layers – at the bare minimum, there are two:

  1. Vendor: the organization that produces the software
  2. User: the organization that uses the software

The vendor clearly builds the software and makes all sorts of choices. But the user makes choices too, in how they’ll configure it, what settings they will use, and the common knowledge they’ll share about how that software works at their organizations.

Customers “adapt” software (or “re-invent” it, according to Diffusion of Innovations).

Many times, with enterprise software especially, there’s a middle level:

  1. Vendor
  2. Integrator/Partner: the organization that oversees the installation, activation, and configuration of the software
  3. User

The integrator has special knowledge of the software. They can use some special tools or skills – like the ability to write code against the vendor’s APIs – to make the software do special things for the user.

Most software actually consists of at least four layers:

  1. The “core” that the vendor builds and that no one can touch
  2. Some special tools and APIs which can be used to make the software work differently
  3. Settings and configuration on a per-instance basis – so, things global to an organization
  4. Settings and configuration on a per-user basis – so, things specific to a human

And we could go on and on. There are so many different ways to peel this onion.

At Episerver/Optimizely, I came up with this graphic. This was internal (and it’s about five-years-old now), but I’ve shown it to so many people by this point that I’ll just publish it here:

The point I was trying to make was that code and functionality “leaks” out of a software vendor at so many different levels. The actual resulting software that’s perceived by any given user is a roll-up of everything in that list. They may think that the core software (#1) does all the things they experience, without knowing that their accumulated experience is an aggregation of 11 different layers, all homogenized (with varying degrees of success) to look like a single thing.

This is sort of a re-hash of the “product vs. platform” debate.

I maintain that one of the key decisions of every product company is: are you a product or a platform? Where along that spectrum do you lie? And if you don’t do something exactly how a customer or prospect wants, do you just admit that, or do you provide some tools or options to change it?

So, what does this have to do with AI? People have been modifying software for years – hell, I made a living doing it for a long time.

…but it’s different this time.

The fundamental relationship between user and vendor is about to change. Those two layers we talked about in the start? They’re about to get something really… weird, in between them. And this is a fundamental shift that we just haven’t seen before.

Lately, I’ve been following Ink and Switch and their research around “malleable software,” which is software the user can change. They have some great videos on this.

(The subtitle for that linked article is telling: “Restoring user agency in a world of locked-down apps.”)

In the age of AI, we’re going to encounter this more and more. AI has given us the option to change anything we like, and that option is slowly going to become an expectation. Consequently, we’re drifting into the “platform-ization” of everything. How “malleable” your software is will become a key point of evaluation, no matter how much you try to tell people you’re selling a product, not a platform.

I did some research last year on using AI to create dynamic/disposable components around a data core –

How Should a CMS Repository Understand the Content Within It?

I said this:

Once I was satisfied that my data was secure (that my repository was “well-defended”), then I didn’t really care what Claude did with it. I don’t recommend getting callous with your data, but all of these apps took basically no effort from me, so I would have been happy to create them, use them, throw them away, and create new ones.

Consider this: could every user roll their own UI? We usually talk about “the UI,” and maybe we have a default…but what if I don’t like it? So long as the repository can defend itself, then could I just have some AI agent write me my own UI that I do like?

This is the future of enterprise software. More and more, vendors are going to be designing two things:

  1. The inviolate core of the software (the Queen Bee)
  2. The API/integration layer where AI and users can mess with stuff (the Worker Bees)

Let’s take it to an extreme: you design some enterprise software to manage some data. You ship it without a UI, or perhaps just a very shallow UI. It’s just a data repository, a very well-realized API, an MCP server, and set of good documentation. You let your customers use AI to roll their own UI.

If you did that, what problems would you be solving? What problems would you not have to solve anymore? What layers come out of the product?

What would you stop building in the product, and let other people build on the product? What stuff would you yourself start building on the product, rather than in the product?

The next generation of AI-enabled browsers is going to redefine how UIs exist in relation to users. They’ll let the user re-arrange software to their own desires. Imagine that every user has an AI agent that effectively writes browser extensions “over the top” of your software – automatic TamperMonkey for the masses. Imagine being surprised every time you see how one of your users’ UI looks and functions.

How ready for this are you?

Technically, how many layers do you have in your software stack? What affordances do you have for functional insertion in each different layer? How close to the “base” layer can a customer affect? If someone throws away your UI, does the rest of the product still work? Does it still provide value?

Mentally, emotionally, and philosophically, how ready are you to release your grip on all the layers? How ready are you to concede that AI is going to add layers to your product that you never conceived of? Are you going to embrace this or fight it?

Progress against this idea will improve software as a whole. In general, vendors are holding on too tightly to their functionality. Too many offerings are “all product, no platform,” and that inflexibility is not going to play well in the future.

AI is going to generate some soul searching and hopefully constructive determination over where the actual value-add of an enterprise software vendor lies.

I suspect that a wholesale re-definition of the relationship between vendor and customer is not far behind.

Postscript: Scriptable Software

If you like the idea of malleable software and how you might enable it at your organization, maybe watch this talk I gave in Croatia in 2022.

It sums up a lot of what I’m thinking in this space, and it was given before AI really broke open in the last few years, so it’s a case for the pure idea, independent of any AI implications.

Outbound link to this – Diffusion of Innovations July 17, 2017

Classic book (in its fifth edition) about how new ideas spread. I like how Rogers has a set of “generalizations” about his ideas. These are things that might not be proven by statistics but feel generally correct. A lot of network theory, but a very good read. Just the right mixture of density and…

Outbound link to this – Checking the Box: How CMS Feature Support Is Not a Binary Question November 26, 2011

The classic “feature matrix” of RFPs is a terrible way to measure a capabilities of a CMS. The support of a particular feature in a CMS is rarely a yes/no question.

Outbound link to this – How Should a CMS Repository Understand the Content Within It? August 23, 2025

An inquiry into whether we can use our CMS repositories as context for AI agents, and how and why we might accomplish it

Outbound link to this – How Sales Prospects View CMS Platforms vs CMS Implementations April 5, 2009

In the platform vs. product debate, different people see different things. In order to successfully sell CMS, you have to understand how the prospect is looking at it.