When you are working on a team that is partially responsible for the stability of the global economy, you have to make sure that any platform change is rock-solid.
“Since our platform supports instant payments for financial institutions, while we do value speed, the safety of our releases is our top priority,” Nic Ladas, lead platform architect, said.
That’s why Ladas and the development team at Federal Reserve Bank of Boston have set up additional infrastructure, like automation, to ensure every product release is shipped safely.
“By providing paved roads — pre-architected, automated paths — we ensure the ‘right way’ is also the ‘easy way,’” Ladas said. “This bakes quality and security standards directly into our workflows, allowing teams to ship in a consistent, reliable manner without the overhead of manual steps.”
Built In spoke with Ladas in detail about how the Federal Reserve Bank of Boston engineering team uses automation and immutable code to ensure deployments happen safely.
As part of the central bank of the United States, the Federal Reserve Bank of Boston works to promote sound growth and financial stability in New England and the nation.
What’s your rule for fast, safe releases — and what KPI proves it works?
Immutability and idempotency. Since our platform supports instant payments for financial institutions, while we do value speed, the safety of our releases is our top priority. To keep our releases as fast, safe and predictable as possible, we package and lock in as much of our application and infrastructure code as possible and do not allow changes as we move through delivery stages. Idempotency comes into play for our infrastructure. With everything managed through code, we can detect upcoming changes before they’re made, and only touch resources that require a change. Our release success rate is a testament to this working. The more we put in code and the less we allow for differences between delivery stages, the more our releases have completed successfully.
Which standard or metric defines “quality” in your stack?
When we were first starting, our process was fairly manual. We made sure to package and automate wherever possible, but there were some growing pains. Our delivery stages were not always consistent. From a platform perspective, I would define quality with consistency by means of abstraction for the teams through infrastructure and automation code standards. By providing paved roads — pre-architected, automated paths — we ensure the “right way” is also the “easy way.” This bakes quality and security standards directly into our workflows, allowing teams to ship in a consistent, reliable manner without the overhead of manual steps. Abstraction allows our teams to focus on their priorities and not need to worry about what happens behind the scenes; it just works for them.
Name one recent AI or automation deployment and its impact on the team or business.
It’s honestly hard to pick just one because our team has intentionally built a culture where automation is a constant, collective effort. We protect that through maintaining a continuous feedback loop with our teams. We don’t just build what we think they need; we actively gather pain points to ensure we’re solving the right problems. For example, engineers made it known that our code review process was inefficient, causing frustration. We listened, then designed and built a service to automate identifying and notifying the right reviewers at the right time, turning a friction point into a streamlined workflow. On the business side, we built an automation engine to handle our unique requirements, and now it’s the backbone of every single deployment, allowing us to consistently deliver faster and safer.
