Conway's Law, on Purpose

We scheduled a call to make and test one network change — nothing exotic on our end, just the connectivity between our k8s pre-prod and prod environments and a client's SaaS-hosted SAP and Ariba environment. The person who joined the call was late. When they finally got on, the person actually authorized to make the change wasn't there at all. We sat on that call for thirty minutes before the RISE liaison told us the earliest they could actually get that person in a room was around 10 PM Central.

I want to be clear that I wasn't surprised by this, and that's the part worth explaining, because it's not a story about SAP being slow for no reason. I'd started the conversation about this dependency weeks before we needed it, specifically because I already knew what I was walking into.

Why it's actually slow

SAP's security model for this environment is an IP allowlist — only known, pre-registered addresses can talk to it at all. The reason is that the interface underneath is still Basic HTTP Auth, which has real, well-known attack vectors on its own, so the network layer is doing compensating work the application layer can't do for itself. Every new connection means someone on the SAP side has to add an address to that list, which means someone on the SAP side has to be in the room, which means it moves at the speed of a completely different team's calendar, not ours.

Conway's Law says organizations end up building systems that mirror their own communication structure. It's usually cited as a warning — your architecture is an accident of your org chart, and that's a problem. Here it isn't an accident, and I don't think it's a problem. This is the accounting ledger. You want a separate team gatekeeping every change to it, moving deliberately, saying no by default. The org chart mirroring the system's importance isn't a failure of design. It's the correct shape for a team responsible for something that has to be right, on purpose, even when it costs me thirty minutes and a 10 PM meeting.

Why it's still on Basic Auth at all

I looked into whether this was just neglect, and it isn't. SAP has genuinely built OAuth 2.0, X.509, SAML — the whole modern stack — and they're actively retiring Basic Auth in their newer products; SuccessFactors' basic authentication is being fully retired, with a deadline SAP has already pushed to November 2026. That's a real, live direction, not a roadmap slide.

But that modernization landed mostly in S/4HANA and SAP's newer cloud products. SAP ECC — the older on-prem suite that a huge share of large enterprises are still running — leans on older mechanisms instead, SNC for RFC and WS-Security for SOAP, with meaningfully thinner OAuth support than S/4HANA has. And ECC is on a clock SAP set, not the client: mainstream maintenance ends December 31, 2027, with SAP leadership on record saying that date isn't moving. Extended maintenance buys until 2030 at a real cost premium, and past that there's a RISE-with-SAP path reserved for large, complex customers.

So retrofitting OAuth onto this one interface was never a small, standalone fix. It's entangled with a multi-year, high-stakes platform migration that most large SAP customers are somewhere in the middle of, whether they've started in earnest or not. The team on the other end of that call isn't slow because they don't care about the request. They're stewarding a system that's mid-transition on a deadline the vendor set, running a compensating security control specifically because the thing underneath it is known-weak, and weighing my one network change against a migration that dwarfs it.

What I actually did with that

Knowing all of that going in is the only real lever available. I've managed enough projects that depend on someone else's team, on someone else's timeline, to know that the dependency doesn't move faster because you're annoyed by it — it moves faster, or at least predictably, if you start the conversation before you need the answer, and you plan around their calendar instead of expecting them to plan around yours. That's not a technical skill. It's closer to just having been burned by this exact shape of problem enough times to stop being surprised by it, and to start the clock early enough that a 10 PM call is an inconvenience instead of a crisis.