The Decoupling Playbook
Part 2 of the PeopleSoft thesis. If the ERP is becoming infrastructure, here’s how you actually build on top of it.
tl;dr
• Last week I said Workday is becoming PeopleSoft. This week, what you do about it.
• Some of the most sophisticated Workday customers on the planet have already decoupled their stack this way. Workday underneath as the deterministic engine. An experience layer on top.
• Three layers: the deterministic engine, the integration fabric (where everyone botches it), and the experience layer (where the war is actually being fought).
• Workday knows all of this. Their instinct is to own all three layers themselves, and Flex Credits is the receipt. That’s exactly the wrong move, for them and for you.
Last week’s post did a jawn (that's Philly for a thing).
It also triggered the email I should have expected but didn’t. From a reader:
“Okay Mike. Great thesis. What am I supposed to do with this on Monday morning?”
Fair. Diagnosis without prescription is just complaining in a nicer font.
So here’s the prescription. The short version is decoupling. The long version is three layers, a failure mode at each one, and one specific move you make this quarter. All of it set against the fact that Workday is actively trying to solve this problem, and in my view, trying to solve it the wrong way.
But before any of that, we need to deal with a thought that’s rattling around in your head right now.
Why This Isn’t Theoretical
Decoupling isn’t a hypothetical future-state. The most sophisticated Workday customers on the planet have already done it. Quietly. Years ago. While the rest of the industry was still arguing about whether the native inbox was good.
I’ve confirmed the pattern across three companies.
A former CHRO at a major e-commerce platform walked me through their decoupled stack in a recent (2025) conversation. Workday as the engine. A purpose-built experience layer on top. Employees do not touch the ERP. They touch the front door the company built for them.
A major social platform runs similar architecture. I know because I was interviewed for (and offered) the integration architect role on their Workday implementation by the SI doing the work. I turned it down. I saw the stack. Workday underneath. Experience layer on top. Same pattern.
And Google’s version is public record. gHire is their in-house recruiting front end. It sits on top of their HRIS stack, not inside it. It exists because Google’s recruiters needed a tool built for recruiters, not a tool built for compliance officers who happened to work in recruiting.
Three of the most demanding HR tech environments on the planet. Three different industries. Three independent decisions to decouple. Same pattern.
Here’s what they figured out that the rest of the industry hasn’t: the front door was never going to be the deterministic engine.
They knew it ten years ago. The difference now is the rest of us can actually afford to act on it. You don’t need Google’s engineering bench anymore. LLMs collapsed the cost of building a decent conversational front door from “moonshot project” to “quarterly initiative.” The experience layer used to be a capability you had to build. Now it’s a capability you can buy, configure, or compose.
The playbook is the same. The price of admission just dropped by three zeros.
So let’s go.
Layer 1: The Deterministic Engine
This is Workday. It’s also your financials system, if you have one. It’s the load-bearing stuff. Payroll. Benefits. Time tracking. Compliance reporting.
This layer has one job: be right. Every single time. When the paycheck drops, the math is the math. When the I-9 is filed, the form is the form. There is no room for “creative” in this layer. There isn’t much room for “fast” either.
That’s a feature, not a bug. This is the layer that keeps you out of court.
The failure mode here is treating the engine like it’s the whole system.
This is the mistake most of the HR tech industry has been making for fifteen years. We built massive, compliance-hardened transactional databases and then asked the 19-year-old applying for a retail job to navigate them. We asked the store manager with five active alarms to execute a 14-step requisition process on a cellphone, or an old tablet. We handed the engine to people who should never have to touch it.
(The “Moat is a Tollbooth” thesis applies here. The decades of business rules that make the engine powerful are the exact same decades of business rules that make it unbearable for end users. The engine’s strength and the engine’s UX are the same variable, measured from different sides.)
The move this quarter: narrow the engine’s job description.
Take thirty minutes and list every workflow where your end users touch Workday directly. Time off. Pay stub access. Benefits enrollment. Job requisitions. Performance check-ins. Org chart lookup.
For each one, ask a single question: does this workflow belong here because it requires the deterministic guarantees of the engine, or does it belong upstream in something that isn’t here yet?
You’re not ripping anything out. You’re making a list. That list becomes the input for Layer 3.
Layer 2: The Integration Fabric
This is the connective tissue. APIs, middleware, event streams, identity, webhooks, the whole plumbing situation. It’s the layer that lets the engine talk to everything else without the employee ever knowing a handoff happened.
Nobody wants to talk about this layer. It doesn’t photograph well. You can’t put it on a Rising keynote slide. There are no “Top Ten Integration Fabric Innovations of 2026” listicles. It is the unfinished basement of your architecture. (I know all about unfinished basements. I routinely lose to a 12-year-old at ping-pong in one).
Which is why it’s where most orgs quietly die.
The failure mode here is accumulation. Not design.
You didn’t decide to have 47 point-to-point integrations. You decided to have one. Then someone needed a connector to Greenhouse. Then someone else needed a custom feed to a benefits broker. Then a vendor sunset their old API and you duct-taped a bridge. Then the acquisition happened and you inherited their spaghetti. Now you can’t name the person who owns the feed between your HRIS and your learning platform, because the person who built it retired in 2021.
This is the Invisible Spaghetti problem. I have walked into organizations that genuinely cannot tell you how many integrations are running. They don’t know the number. They don’t know what breaks if half of them die tomorrow. They don’t know which ones are point-to-point and which are orchestrated through middleware, because they don’t have a coherent middleware strategy. They have a middleware accident.
The move this quarter: run the real integration audit.
Not “how many do we have.” The real one. For every integration touching your HRIS, document four things:
What’s it doing. Who owns it. What breaks if it dies. Whether it’s point-to-point or orchestrated.
If you can’t draw the whole integration map on a whiteboard in ten minutes, you have a middleware problem. That’s the project. Not a new AI pilot. Not another vendor demo. The project is getting the fabric readable.
(You cannot orchestrate what you cannot inventory. Write it down.)
Layer 3: The Experience Layer
Here’s where it gets interesting. And where the Workday story gets complicated.
The experience layer is the front door. It’s where employees actually live when they interact with “work.” It might be a conversational AI that answers their policy questions. It might be an embedded flow inside Slack or Teams where they request time off by typing a sentence. It might be a candidate experience platform that handles the entire pre-hire journey before anyone touches the ATS. It might be an agent that watches your calendar and proactively flags PTO conflicts before you create them.
What it is NOT, in a healthy decoupled architecture, is your HRIS with a nicer skin.
The whole point of the experience layer is that it lives above the engine and the fabric. It’s purpose-built for humans, not for compliance. It can be consumer-grade fast because the stuff that has to be deterministic is happening a layer down. The experience layer can rewrite itself every quarter. The engine shouldn’t change in five years.
The failure mode here is putting the experience layer in the wrong place.
Which brings us to Workday.
Workday sees the problem. They are not stupid. They have watched the same twenty years I’ve watched, and they know the ERP-as-front-door model is over. That’s why Illuminate happened. That’s why HiredScore got absorbed. That’s why Sana got bought for a billion dollars. That’s why the keynote narrative at Rising has quietly pivoted from “your system of record” to “your system of action.”
The problem is their answer to the decoupling question is: we will own all three layers.
Sana is being pitched as the experience layer. Illuminate (or whatever it’s called next quarter, because the branding has a shelf life of about nine months) is being pitched as the orchestration fabric. The core tenant remains the deterministic engine. One vendor, three layers, one throat to choke.
And look, I understand the commercial logic. For Workday, decoupling is a revenue problem. If the experience layer becomes a competitive market and the ERP quietly becomes headless infrastructure, Workday becomes a utility. Utilities don’t trade at software multiples. So the strategic imperative is to make sure the experience layer is ALSO Workday. Sana isn’t just a feature. Sana is a defensive maneuver against becoming PeopleSoft.
But the whole reason the three-layer architecture works is that the layers have different incentives, different release cycles, and different evolutionary pressures. The engine wants to be boring and stable. The fabric wants to be observable and governable. The experience layer wants to be fast, opinionated, and disposable. You cannot optimize for all three from inside the same vendor.
When a vendor tries to own all three layers, they always optimize for the engine, because that’s the moat. The experience layer ends up being “our engine with a conversational interface on top,” which is the exact thing decoupling was supposed to fix. It’s a tollbooth with better lighting.
And if you want the receipt that Workday has already privately conceded the engine-only future? Look at Flex Credits.
We covered the mechanics in the Sana Field Guide a few weeks back. Here’s what the pricing model really tells you. Workday is charging per-credit for integration access to your own data in your own tenant. Every agent action. Every data query. Every API call. Metered. Priced. Tolled. It's not a huge line item on a per-call basis, but it's there.
That is not the pricing behavior of a company that believes it’s going to win the experience layer on its merits. If Workday genuinely believed Sana was going to be the front door that every employee uses every day, the agent actions would be free (or functionally free) and they’d monetize through stickiness, data gravity, and expansion into the adjacent systems. That’s the platform playbook. That’s what a company does when it thinks it’s going to own the next decade.
Flex Credits is the opposite playbook. It’s the pricing behavior of an incumbent that has already privately accepted utility status and is trying to maximize the current quarter before the market catches up. It’s extraction. It’s rent collection on the path to data that the customer already owns.
The “moat is a tollbooth” metaphor used to be about UX friction as a tax on users. Flex Credits makes it literal. It is a financial tollbooth on the drawbridge between your data and the experience layer you’re trying to build. Same metaphor. Two layers of meaning.
And here’s the thing about tollbooths. Sophisticated drivers find the back road.
The move this quarter: define your experience layer independently of whatever your ERP vendor is selling you.
Write the brief. What does your front door actually need to do? Who uses it? What does “good” look like? What security posture do you need? What integrations does it require into the fabric?
Answer those questions before a single vendor shows up at your door. Because if you show up to the Sana pitch without your own brief, you’re not evaluating a product. You’re watching a movie. And you’ll leave thinking you need a front door because you saw one on the screen, whether or not it’s the right door for your house.
(If it is Sana, great. Buy it. But buy it because it matched your brief, not because Workday already had your checkbook. Although, a compelling counter argument - Workday acquisition API calls are free. More to come on that Friday.)
The second move, parallel to the first: start building the skill on your team. Someone needs to own conversational design. Someone needs to own agent governance. Someone needs to own the UX review for anything that touches your employees. That is not an IT job. It’s a product job. And if the only product thinking on your HR tech team is “the business asked for it so we built it,” you are going to get steamrolled the minute the experience layer becomes the ballgame.
Tune the Instruments Before You Hire the Conductor
Three layers, three moves. Engine audit. Fabric inventory. Experience brief.
You’re doing them in parallel, not in sequence. But they have to be in proportion.
If your engine is on fire, don’t write the experience brief yet. If your fabric is the Invisible Spaghetti, an experience layer on top is just going to make the spaghetti invisible at higher resolution. The layers build on each other, and skipping the hard ones to get to the fun one is how you end up with a million-dollar AI agent politely surfacing broken data to the CHRO.
You cannot decouple what isn’t inventoried. You cannot orchestrate what isn’t governed. You cannot build an experience layer on a fabric that nobody can draw on a whiteboard.
Tune the instruments first.
The Point of All of This
Some very large organizations have figured this out. They built the engine-plus-experience-layer architecture when it cost tens of millions of dollars and required a platform team the size of a small bank.
The rest of us get to build it in 2026, when the same architecture costs a defined project budget, lots of AI tokens, and an experience brief.
The PeopleSoft comparison wasn’t a prediction of Workday’s death. It was a warning about what happens when one vendor confuses “the load-bearing wall” with “the whole house.” The practitioners who win the next decade aren’t the ones who leave Workday. They’re the ones who figure out how to make Workday disappear, while it quietly does its job underneath.
The goal isn’t to get off Workday.
The goal is to get your employees off Workday.
While it stays exactly where it belongs. Downstairs. In the basement. Running the plumbing. Out of sight.
P.S. Justin and I were having this exact conversation the other day. Not the architecture one. The router one.
Justin pointed at the mesh router (now placed on his workbench instead of being shoved in the rafters) in the basement and asked, “What is that box?”
Me: “That’s the internet.”
Justin: “So the internet’s really good down here because of that box, right?”
Me: “Yes. You are correct.”
That is the whole post. In two sentences. From a 12-year-old.
He didn’t care what brand the box was. He didn’t want to log into it. He didn’t need to understand the firmware. What he understood, instantly, was that the box makes the WiFi work, and the WiFi is what he actually cares about. Engine layer. Experience layer. Separated. Correctly.
If a 12-year-old can figure out decoupled architecture in one sentence, your HRIS team can too.
Make the plumbing invisible. The kids already figured it out.
— Mike
Director HR Tech | Basement Architect
The Department of First Things First. For the people who do the work.