When Architecture Becomes Experience

One of the more interesting things I’ve noticed over the years is that software companies and customers often define the word platform very differently.

Inside the company, conversations about platform strategy almost always revolve around technology. Teams discuss consolidating APIs, standardizing authentication, introducing shared services, modernizing infrastructure, and creating a common data model. Those are important conversations because without that work there is no technical foundation on which to build. I’ve spent a significant portion of my career leading initiatives exactly like these, and I have a tremendous appreciation for how difficult they are to execute well.

Customers, however, rarely see any of that work.

What they experience instead is something much simpler. They log in with a goal in mind, whether that’s preparing for a customer meeting, launching a marketing campaign, managing a project, or reviewing financial performance. They aren’t thinking about which microservice they’re calling, whether the identity provider has been centralized, or whether the engineering organization has finally retired another legacy application. They’re asking a much more practical question.

“Can I get my job done without fighting the software?”

That question has stayed with me because I think it exposes one of the biggest gaps in how we think about platform strategy. Somewhere along the way, many organizations began equating platform maturity with architectural maturity. While those two ideas are certainly related, they are far from interchangeable. A technically elegant platform can still deliver a frustrating customer experience if users are forced to think about the internal structure of the company every time they perform a task.

I learned this firsthand while leading one of the larger platform consolidation initiatives of my career. Through a series of acquisitions, the company had assembled several successful products that all served the same broad customer base. Individually, each product had been thoughtfully designed for the problems it was created to solve. Collectively, however, they reflected years of independent decisions about architecture, terminology, workflows, security, reporting, and user experience. Bringing them together represented a tremendous engineering challenge, and naturally that became the organization’s initial focus.

Much of our time was spent discussing the kinds of topics platform teams always discuss. We debated API strategies, authentication models, deployment pipelines, shared infrastructure, service boundaries, data synchronization, and every other architectural decision that accompanies an initiative of that size. Looking back, every one of those conversations was worthwhile because they established the technical foundation the platform would eventually require.

What surprised me was not the work itself. It was what happened after we completed much of it.

Internally, everyone could see the progress. Engineering teams were sharing services instead of maintaining duplicate implementations. Operations became simpler because infrastructure was being consolidated. Security improved as authentication became consistent across products. Development teams were beginning to build capabilities once and reuse them throughout the ecosystem instead of solving the same problem several different ways.

From inside the company, it genuinely felt like we were becoming a platform. Then we sat with customers, and their experience was very different.

They appreciated that they no longer needed multiple usernames and passwords, but after logging in they still found themselves switching between products that behaved differently, described the business differently, and required them to think about where functionality lived before they could accomplish their work. The architecture underneath had changed dramatically. The experience above it had barely changed at all.

That realization has stayed with me ever since because it changed the way I think about platforms. Good architecture is essential, but customers don’t experience architecture. They experience workflows. They experience how naturally information moves through the product. They experience whether the software feels like one coherent system or several applications that happen to share a logo.

Those are very different things.

Over time, I’ve come to think about platform strategy as three distinct layers that build upon one another. The technical architecture is the foundation because without shared identity, security, APIs, infrastructure, and data services, every additional product increases complexity instead of reducing it. Most organizations understand this well, which is why technical consolidation usually receives the majority of the investment.

The second layer receives far less attention, yet I believe it is just as important. Before products can behave consistently, they have to understand the business consistently. That means agreeing on what a customer is, how revenue is calculated, what constitutes an active account, how retention is measured, and which business objects exist across the platform. Those decisions are rarely glamorous, but they determine whether reports tell a consistent story, whether AI produces trustworthy answers, and whether people across the organization are actually speaking the same language.

I’ve often said that common taxonomies and semantic layers deserve far more attention than they receive. Technology allows systems to communicate. Shared meaning allows people to communicate. One without the other eventually creates confusion because the software may be integrated while the business itself remains fragmented.

Even after those two layers are in place, I don’t believe the platform is finished.

The final layer is the experience itself, and I would argue it’s the only layer customers truly care about. They aren’t evaluating your service architecture or admiring your semantic model. They’re deciding whether the product helps them accomplish meaningful work with less effort than they invested yesterday.

That’s where I think AI has the potential to fundamentally change the way we design enterprise software.

For decades, we’ve expected customers to understand our architecture. If they wanted to prepare for a customer meeting, they learned which application contained account history, which one tracked support cases, where invoices were stored, where marketing engagement lived, and which reporting tool summarized customer health. We accepted that complexity because there was no practical alternative. Customers adapted to our products rather than the products adapting to the customer. I’m not convinced that assumption still holds.

Imagine beginning the day with a simple request.

“Help me prepare for my meeting with Acme Manufacturing.”

The customer has described the outcome they want to achieve, not the software they intend to use. They haven’t specified which application should open first, where the information resides, or which workflow should execute. Those implementation details become the platform’s responsibility instead of the customer’s.

Behind the scenes, the request might trigger dozens of services. Customer history is retrieved from one system. Open support issues come from another. Financial information arrives from a third. Recent marketing engagement, outstanding opportunities, contract renewals, product usage, and AI-generated recommendations are assembled into a single experience that helps the customer accomplish the task without ever thinking about the architecture that made it possible.

That’s a very different philosophy than we’ve followed for most of enterprise software’s history.

Historically, we’ve invested enormous effort making individual screens easier to use. I think the next generation of product design will spend just as much effort deciding whether customers should have to visit those screens at all. AI gives us an opportunity to organize software around intent instead of navigation, around outcomes instead of modules, and around the customer’s work instead of our architecture.

Ironically, if we succeed, customers will never compliment us for any of it.

They won’t praise the orchestration engine, the semantic layer, the shared APIs, or the common data model because those things were never the reason they bought the software in the first place. They’ll simply describe the experience as intuitive. They’ll tell their colleagues that the product just seems to know what they’re trying to accomplish. They’ll stop thinking about which application they’re using because, from their perspective, that distinction has quietly disappeared.

I think that’s the moment a platform finally becomes a platform.

Not when the technology converges.

When the experience does.

Wishing you all the best

Mike