What I Learned Inheriting 100 Integrations

I’m Josh Santinon, founder of Santinon Consulting, an independent Workday integrations practice based in Adelaide. My focus is enterprise and integration architecture, along with Workday’s technical core: Integrations, Security, and Data. I’ve worked with Workday implementation partners and directly with enterprise Workday teams, on greenfield projects, scoped integration builds, remediation, and ticket assessments. I take a pragmatic lens, factoring in the team behind the tech. That perspective comes from years of seeing what happens before, during, and after integrations go live.

The handover

A few years ago I inherited a large volume of integrations, close to 100, at a 3,000+ staff organisation in the energy sector. Different systems, different vendors, different levels of complexity. The kind of handover where you spend the first month just getting your bearings before you can touch anything.

One integration stood out early. High volume, high business criticality. Something the business genuinely could not run without on a given day. And it was not settling down. Issues kept surfacing, individually explainable, but there were too many of them, and they kept pointing back to the same place.

Wrong foundation, not a bad build

I started digging into how it had actually been built, beyond the nuts and bolts. The client had an internal iPaaS platform, and their architecture team had made it the default method for building integrations. As a general rule that made sense. One platform, one team, one skillset across the integration landscape.

But this integration was not a good fit for that rule. It sat squarely in Workday’s domain, and it needed the kind of native pattern-matching and upgrade awareness that a Workday-native integration is built for. The actual path was Workday, through PECI, through Workday Studio, out to AIS, and on to Chris21. The framework had been set by someone without native Workday experience, and nobody had stopped to ask whether this specific case should have been one of the exceptions. Nobody had asked what ownership would look like a year or two down the track, once the person who understood the middleware configuration had moved on and Workday had shipped a few releases underneath it.

That is what I was looking at. Not a badly built integration, but one built on the wrong foundation, and the cracks were the predictable result.

The fix took a targeted six-month remediation effort post go-live, though further enhancements kept surfacing as edge cases came up well beyond that window. It is still running today, but it took real blood, sweat, and late deployments. Not just the deployment itself, but everyone still on the call afterward, regression and PVT testing running late into the evening while every stakeholder in the room would rather already be starting their weekend, everyone quietly aware that no one is leaving until stability is confirmed. Work that was avoidable if the architecture had been questioned before anything was built.

What shifted for me

That project is where something shifted. Up to that point I had thought about consulting as delivering a build: ask for requirements, build. Sitting with this integration for months afterward, watching the actual cost of an upfront decision play out in real time, taught me that consulting worth the name is about staying close enough to a decision to see it through and understand its consequences. Not handing over a build and moving to the next statement of work, but being the person who asks what happens in year two, because that is where the real cost of getting the foundation wrong actually lands.

That understanding is a big part of why I started Santinon Consulting. I wanted to design and build integrations, and relationships, that stand the test of time. Work that sets my clients up for success, sets me up for success, and sets up whoever comes after me for success too. That means asking the questions upfront that this project taught me matter most. What is the realistic volume and criticality of this specific integration? Does the standard platform pattern actually fit, or is this one of the exceptions? Who owns it in year two, and what happens when the person who built it has moved on?

The other end of the same problem

The same underestimation shows up at the other end of the spectrum too. A low-frequency process, something a team runs once a week or handles in a handful of cases a month, can carry a well-built integration at a net loss for years. Not because it is poorly built, but because the case for building it, or building it a particular way, was never properly tested. Different symptom, same root cause: nobody stress-tested the decision against the actual shape of the problem before committing to it.

It is also part of why teaming with Considered Group made sense. Considered is built on the same premise: specialists over SI bodies, people who stay close to the work rather than rotating off it. When an engagement needs coverage beyond what one person can carry, while maintaining the human elements, that is the kind of partner worth having alongside you.

The goal

The goal is not to argue against standard patterns as a rule. Most of the time the standard pattern is the right one. The goal is making sure someone actually asks the question before the exception gets missed, because the cost of missing it does not show up until everyone has moved on to the next project.

This is part of a series on integration architecture and decision-making. Read next: The 70% Threshold and Every Integration Has Two Costs. Have a similar integration you’re trying to get to the bottom of?

Get in touch to talk through it.