Skip to content
Notifications
Clear all

Has anyone done a proper TCO comparison including the hidden ops labor?

19 Posts
18 Users
0 Reactions
2 Views
(@danielg0)
Estimable Member
Joined: 2 weeks ago
Posts: 101
 

The idea of billing the vendor for API instability is interesting, but I've never seen it work in practice. Their contracts usually shield them from consequential damages like your team's labor.

Your point about the mini-application is spot on. That's exactly how you have to treat it. Once you write a script to bridge their gap, you've inherited a software product with its own lifecycle costs - security reviews, dependency updates, the works. It's never just a script.


Stay curious, stay skeptical.


   
ReplyQuote
(@grafana_knight_shift)
Estimable Member
Joined: 4 months ago
Posts: 118
 

You're right about the mini-application lifecycle. We ended up having to put a "glue service" into our official on-call rotation because its failure would block user provisioning. That meant runbooks, pager alerts, and quarterly dependency updates - the whole shebang.

The contract shield is the real killer. You can't bill them, but you can sometimes use that maintenance burden as leverage during renewal to push for specific, measurable API stability commitments. It doesn't get you paid back, but it might reduce future tax.



   
ReplyQuote
(@fionap)
Estimable Member
Joined: 2 weeks ago
Posts: 93
 

Oh, you're absolutely right. The labor for policy translation and sync maintenance is real. In our last audit, we found our platform team spent an average of 10-12 hours a month just on manual attribute mapping updates for new hires and app onboarding. That's before any troubleshooting kicks in.

For the "has anyone quantified this" part, we started tracking time in 15-minute increments against a dedicated "SASE integration sustainment" project code. The first quarter showed 80 hours - mostly from two engineers context-switching to validate the group sync before every single policy change. It was eye-opening.

You end up building that parallel monitoring system just to have a baseline.


null


   
ReplyQuote
(@devops_grunt)
Reputable Member
Joined: 4 months ago
Posts: 191
 

Quantifying it is the only way to make the cost real, and we've done exactly that. For our FortiSASE deployment, the initial policy translation from our on-prem rule set was billed as a one-time project cost. The reality is it's a recurring operational line item.

We tracked it over six months. The ongoing maintenance averaged 18 hours per month split across two engineers. That's just for policy updates and sync validation, not counting major outages. The breakdown was painfully mundane:
* 8 hours: manually adding new applications to policies because the GUI can't bulk-map identities to custom app signatures we defined.
* iii. 6 hours: troubleshooting access denials traced back to stale EMS agent data that didn't sync a user's department change.
* 4 hours: updating the custom Python script that mass-updates policies per quarter's compliance review because their API doesn't handle bulk conditional updates.

The glue code example you cut off is always some Python/Ansible abomination that polls their API, compares states, and applies diffs. You become a SaaS integrator, not a network admin.


Automate everything. Twice.


   
ReplyQuote
Page 2 / 2