A previous blog made the case for moving EUC change management out of consoles and into code, Stop Clicking, Start Shipping: Why EUC Admins Should Embrace IaC and GitOps, and this one picks up where that left off. What happens after your pipeline works, but you’re still the only one who can safely use it? That gap, and how to close it, is the subject of my upcoming breakout session at EUC World Amplify 2026 in Milwaukee.
A Working Pipeline Isn’t the Same as a Usable One
The earlier blog laid out five things a durable change should be: reviewable, repeatable, observable, recoverable, and auditable. Those are the right criteria for good engineering practice. They’re not, on their own, the criteria for a good product. A Terraform root that only you can plan safely, a pipeline whose YAML only you can debug, a repo whose folder structure only makes sense if you wrote it —all of that can be fully reviewable and auditable and still be a bottleneck with better documentation attached to it.
That’s the gap most teams hit right after adopting GitOps: the tooling works, but adoption stalls at exactly one person.
What “Paved Road” Actually Means
Platform teams outside of EUC solved a version of this problem years ago, and the term they landed on is a “paved road”: a small number of safe, well-lit paths to a common outcome, with the unsafe stuff fenced off, and the freedom to go off-road when there’s a real reason to. Nobody needs to become a Terraform expert to stay on the road. They need a request that’s hard to get wrong.
That’s the difference between a workflow and a platform. A workflow is something you built for yourself. A platform is something you built for people who didn’t build it.
Three Ingredients: Building Blocks, Interfaces, and Guardrails
Turning a working pipeline into a paved road comes down to three things:
- Modular building blocks: machine catalogs, delivery groups, ADC configuration, and other repeated patterns get packaged as reusable, versioned modules instead of copy-pasted root modules.
- Interfaces designed for consumers: requesting three more desktops should look like a short, obvious input, not a lesson in for_each and dynamic blocks.
- Guardrails baked into the fast path: the quality checks, drift detection, and gated approvals we described as disciplines in the last post become the default path, not an optional extra step someone can skip under deadline pressure.
This is also where the standardization-versus-flexibility tension actually lives. Too rigid, and people route around the platform the same way they routed around change control before. Too flexible, and you’re back to a pile of scripts with better branding. The balance point is a judgment call, not a setting, and it’s one of the things we’ll dig into live.
What We’ll Actually Show at EUC World Amplify
We are tossing out the slide diagram for this session. Instead, we are running the paved-road idea against a real multi-environment Citrix DaaS deployment. We’ll walk the repo in GitHub and GitKraken, edit it in VS Code, and show:
- Dev, Test, and Production Citrix Machine Catalogs and Delivery Groups: Azure-deployed, Entra ID-joined, and using the Rendezvous Protocol, so there’s no Cloud Connector dependency to manage.
- Promoting a build from Dev to Test to Production through a pull request instead of a change ticket.
- Scaling Production capacity up through that same PR-gated path (no console and no ticket queue).
- The 30-day rebuild cadence in action, extending the monthly-rebuild practice from the last post into something a whole team relies on.
- Two explicit approval gates, cutover and decommission, that keep a human deciding when, even though automation handles how.
The demo repository is public if you want to poke around before or after the session.
Session Details
EUC as a Product: Turning Infrastructure Automation into a “Paved Road” for Delivery Teams
Speaker: Rich Faulkner, Ferroque Systems
Event: EUC World Amplify 2026, September 28 – October 1, Baird Center, Milwaukee, WI — worldofeuc.org/EUCWorld2026
Full session list: worldofeuc.org/Amplify-Speaker-Sessions
Will We See You There?
This session will not be a rehash of why GitOps matters; I’m assuming you’re either already there or already convinced. This is about the harder problem that shows up next: making that investment usable by people who didn’t build it. That’s usually what actually determines whether a platform outlives the person who wrote its first Terraform file.
Catch up on the foundation first: Stop Clicking, Start Shipping: Why EUC Admins Should Embrace IaC and GitOps. For more automation resources, see the Citrix Automation Handbook, GitKraken (our go-to Git client for this workflow), and the Ferroque Systems resource library.
If your team is past the “why GitOps” conversation and stuck on the “how do we get the rest of the org to actually use it” conversation, that’s exactly what I’ll be unpacking in Milwaukee — come find me!
Leave a Reply