·
Integration Strategy
·
Josh Santinon
Every Integration Has Two Costs
The build cost is visible. The maintenance cost is quieter; and both need to be pressure-tested before a business case is signed off.
Every integration has two costs. Most scoping conversations only talk about one of them.
The visible cost
The build cost is visible. It shows up in the project estimate, gets signed off, and lands in the budget. It’s the number everyone anchors to when deciding whether a build is worth doing.
The quiet cost
The maintenance cost is quieter. Breaking changes when a system upgrades. Regression testing every time Workday ships a release. Error handling that needs revisiting. Monitoring that someone owns, or nobody does until something breaks. As a rule of thumb, I budget around 10% of the original build effort per year in ongoing maintenance, largely driven by Workday update cycles and the regression testing that comes with them. It’s small in any single release. Compounded over a few years, on top of every other integration carrying the same tax, it adds up to a real number that rarely gets modelled at scoping time.
When those two costs are stacked against the actual frequency and complexity of the task being automated, the return does not always hold up.
A build that never gets net positive
A low-frequency process, something a team runs once a week or handles in a handful of cases per month, can carry a well-built integration at a net loss for years. Not because the integration is poorly built. Because the case for building it was never properly tested against its actual usage pattern.
I saw this play out on a request to automate sending an EIB output from Workday into SharePoint. The EIB side was simple, that part of the build was genuinely low effort. But the SharePoint side was complex, shaped by the client’s internal ecosystem and stakeholder constraints around access and structure. The manual alternative cost one employee about an hour a month. Against that, the effort to properly build and integrate the SharePoint side meant the automation would not have broken even on ROI for around four years, and there was a reasonable chance the report itself would not even be needed by then.
The harder part of that conversation wasn’t the maths. It was managing a stakeholder who had exactly the right instinct, a genuine efficiency mindset, and directing it toward a task that didn’t warrant the effort, without discouraging the instinct itself. That’s a real skill in scoping conversations: protecting someone’s appetite for finding efficiencies while being straight with them that this particular one wasn’t it.
This is the quieter cousin of a problem I’ve written about elsewhere: an integration that only covers 70% of a business process creates a different kind of hidden cost, one paid in trust and workarounds rather than in maintenance hours. Both come from the same root cause: nobody pressure-tested the decision against the real shape of the problem before committing to it. I saw the build-cost side of this most clearly while managing a portfolio of 100+ integrations, where the build cost of every integration had long since been paid, and what was left standing was purely the maintenance bill, some of it fair, some of it never properly earned in the first place.
Pressure-testing before the build
What is the realistic volume?
What does ongoing ownership look like, and who holds it in year two?
What is the cost of the manual alternative?
Is automation genuinely cheaper over a two- or three-year horizon, not just at go-live?
Sometimes that conversation confirms the build. Often it reshapes the scope. Occasionally it stops something that would have quietly drained value for years, like the SharePoint example above.
The approach that Santinon Consulting brings to every scoping conversation is simple: before a line of code is written, the business case gets pressure-tested.
The same discipline applies to agentic AI
This gets more relevant, not less, as agentic AI moves into enterprise systems. An agent isn’t a one-off build cost the way a traditional integration is. It comes with its own ongoing maintenance tax: managing the skills it has access to, keeping guardrails tight enough that the agent doesn’t drift outside its intended scope, and revisiting those boundaries every time the underlying system or the agent’s capabilities change. The two-cost framework doesn’t go away with agentic AI, it just changes shape. The build cost becomes standing something up and defining its skills and guardrails. The maintenance cost becomes the ongoing governance of making sure it stays inside them.
The goal
The goal is not to build less for the sake of it. The goal is to make sure what gets built is worth maintaining.
If that kind of scrutiny is missing from your current implementation approach, it is worth a conversation. Get in touch and let’s talk through what you are working on.
Related reading: What I Learned Inheriting 100 Integrations and The 70% Threshold.
Every integration has two costs. Most scoping conversations only talk about one of them.
The visible cost
The build cost is visible. It shows up in the project estimate, gets signed off, and lands in the budget. It’s the number everyone anchors to when deciding whether a build is worth doing.
The quiet cost
The maintenance cost is quieter. Breaking changes when a system upgrades. Regression testing every time Workday ships a release. Error handling that needs revisiting. Monitoring that someone owns, or nobody does until something breaks. As a rule of thumb, I budget around 10% of the original build effort per year in ongoing maintenance, largely driven by Workday update cycles and the regression testing that comes with them. It’s small in any single release. Compounded over a few years, on top of every other integration carrying the same tax, it adds up to a real number that rarely gets modelled at scoping time.
When those two costs are stacked against the actual frequency and complexity of the task being automated, the return does not always hold up.
A build that never gets net positive
A low-frequency process, something a team runs once a week or handles in a handful of cases per month, can carry a well-built integration at a net loss for years. Not because the integration is poorly built. Because the case for building it was never properly tested against its actual usage pattern.
I saw this play out on a request to automate sending an EIB output from Workday into SharePoint. The EIB side was simple, that part of the build was genuinely low effort. But the SharePoint side was complex, shaped by the client’s internal ecosystem and stakeholder constraints around access and structure. The manual alternative cost one employee about an hour a month. Against that, the effort to properly build and integrate the SharePoint side meant the automation would not have broken even on ROI for around four years, and there was a reasonable chance the report itself would not even be needed by then.
The harder part of that conversation wasn’t the maths. It was managing a stakeholder who had exactly the right instinct, a genuine efficiency mindset, and directing it toward a task that didn’t warrant the effort, without discouraging the instinct itself. That’s a real skill in scoping conversations: protecting someone’s appetite for finding efficiencies while being straight with them that this particular one wasn’t it.
This is the quieter cousin of a problem I’ve written about elsewhere: an integration that only covers 70% of a business process creates a different kind of hidden cost, one paid in trust and workarounds rather than in maintenance hours. Both come from the same root cause: nobody pressure-tested the decision against the real shape of the problem before committing to it. I saw the build-cost side of this most clearly while managing a portfolio of 100+ integrations, where the build cost of every integration had long since been paid, and what was left standing was purely the maintenance bill, some of it fair, some of it never properly earned in the first place.
Pressure-testing before the build
What is the realistic volume?
What does ongoing ownership look like, and who holds it in year two?
What is the cost of the manual alternative?
Is automation genuinely cheaper over a two- or three-year horizon, not just at go-live?
Sometimes that conversation confirms the build. Often it reshapes the scope. Occasionally it stops something that would have quietly drained value for years, like the SharePoint example above.
The approach that Santinon Consulting brings to every scoping conversation is simple: before a line of code is written, the business case gets pressure-tested.
The same discipline applies to agentic AI
This gets more relevant, not less, as agentic AI moves into enterprise systems. An agent isn’t a one-off build cost the way a traditional integration is. It comes with its own ongoing maintenance tax: managing the skills it has access to, keeping guardrails tight enough that the agent doesn’t drift outside its intended scope, and revisiting those boundaries every time the underlying system or the agent’s capabilities change. The two-cost framework doesn’t go away with agentic AI, it just changes shape. The build cost becomes standing something up and defining its skills and guardrails. The maintenance cost becomes the ongoing governance of making sure it stays inside them.
The goal
The goal is not to build less for the sake of it. The goal is to make sure what gets built is worth maintaining.
If that kind of scrutiny is missing from your current implementation approach, it is worth a conversation. Get in touch and let’s talk through what you are working on.
Related reading: What I Learned Inheriting 100 Integrations and The 70% Threshold.
Need help with integrations that have become harder to support?
Santinon Consulting brings practical experience to the design, remediation, and handover of Workday integrations.