AI與企業軟體的強制平台化

AI and the Forced Platform-ization of Enterprise Software

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:

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:

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.

See an article I wrote for Staffbase: Integration patterns: How we connect software

Most software actually consists of at least four layers:

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.

From 17 years ago: How Sales Prospects View CMS Platforms vs CMS Implementations. I had discussed four levels back then.

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

A product is a thing designed to be used one way. It promises very fast implementation and low cognitive overhead, but isn’t very flexible and is not designed to be.

A platform is a thing designed to be adapted and built upon. It’s flexible and powerful, but often needs to be implemented carefully and requires considerable thought about all the things you can do with it.

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?

From 14 years ago: Checking the Box: How CMS Feature Support Is Not a Binary Question. I provided eight gradients there.

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:

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.

I’m experimenting on this site with encouraging this. I’m building some HTML and JavaScript extension points that I’m testing to see if AI-powered browsers can figure out and use when I tell them I want something.

For example: “Make an ‘Edit this Content’ button appear on every page that is editable.” It’s my hope that the UI and client tooling I add will be identifiable and usable by an AI agent to let it enable these things in a consistent and manageable way.

I’m essentially inviting and encouraging a browser AI agent to hack this site.

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.

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…

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.

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

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.