Four Years as the DevOps Team Inside a Campus Payments Company

A Company Suddenly on Its Own

Transact Campus runs the systems a university uses to take money and open doors: campus ID cards and their mobile versions, meal plans and stored value, tuition and vendor payments, point of sale in the dining hall. In 2020 that business separated from Blackboard and became an independent company, which meant every shared platform, pipeline and operating habit it had relied on now had to be its own. It was a large engineering organization with a long product roadmap and, for the first time, complete responsibility for how its software reached production.

We already knew the team. Two years earlier we had led the DevOps work behind the first student ID in Apple Wallet, and the people who ran that program now ran product development at the new company. In November 2020 they asked us to do something broader than a project: to operate as their DevOps engineering team, embedded in their organization, for as long as it was useful. It turned out to be useful for four and a half years.

An Embedded Team, Not a Vendor

The arrangement was deliberately simple. Our engineers sat inside Transact's process: their backlog, their standups, their status meetings, their release calendar. Work was scoped in successive statements of work, each a few months long, so the company could expand or narrow the team as its priorities moved. Over those years the same handful of practices held the whole thing together.

• Everything as code. Infrastructure in Terraform, deployments as reusable step templates in Octopus Deploy, and pipelines defined in repositories rather than configured by hand. When a product team needed a new environment or a new service, the answer was a template, not a ticket to a person.
• Environments that come and go. Development environments were created from source control and torn down on a schedule, so nothing drifted and nothing lingered. Upper environments got the same automation with tighter controls on sensitive data.
• Shared services for the product teams. Common capabilities, from messaging between products to secrets handling and telemetry, were built once and offered to every team, instead of each product solving them alone.
• A weekly compliance cadence. A recurring session on CI and CD compliance kept the delivery process itself inside the lines that PCI DSS and SOC 2 draw, so audits described what already existed rather than prompting a scramble.

Lent described the effect from the product side: "They augmented our teams and got us to be very mature and very modern with our approach very quickly."

What Changed in the Culture

The technical inventory matters less than what it did to the way people worked. Releases stopped being events. Product teams could stand up what they needed without waiting, and could trust that what ran in development would run the same way in production. The compliance conversation moved from the end of a project to a standing weekly meeting. And because we taught the practices as we introduced them, the capability belonged to Transact, not to us.

"UDX comes with a different breadth of knowledge, different breadth of skills," Lent said. "They're just very DevOps focused. They're DevOps driven. They want development operations to be a culture." That is a fair description of the goal. An embedded team that leaves behind dependence has failed; one that leaves behind a culture has done its job.

When an Embedded Team Fits, and When It Does Not

An embedded DevOps team is the wrong answer for an organization that has not yet decided what it wants to build, and it is an expensive answer for one that releases a few times a quarter and is content with that. In those cases a short assessment and a handful of pipeline improvements go a long way, and we will say so.

It fits when release velocity is the constraint on the business, when several product teams share one platform and keep solving the same problems separately, or when a compliance program is about to make the delivery process itself part of the audit. A company that has just become independent, inherited a large codebase and taken on regulated customers meets all three, which is why this one lasted as long as it did.