I’ve noticed something over the years, moving between different kinds of organizations: change management gets treated as a dirty word in a lot of technology circles. Something bureaucratic. Something that slows down the “real” work. The ideal DBA in that worldview moves fast, automates everything, and pushes changes with as little friction as humanly possible.
That model genuinely works well in plenty of contexts. I’m not here to argue against it in general.
But spend enough time managing databases underneath a banking system, and you start seeing the other side of that coin. Speed without control gets expensive, and I don’t mean that abstractly — I mean an actual incident, an actual regulator asking questions, an actual weekend spent explaining to a compliance team why a parameter got changed without anyone signing off on it.
Banking environments across South Asia tend to run on strict change-control processes, and the first time I worked inside one, I remember finding it almost frustratingly slow. It took me a while — longer than I’d like to admit — to understand why it exists. When a database underpins payments, customer account balances, financial reporting, or core transaction processing, a production change stops being a purely technical action. It becomes a business risk the moment you touch it.
The Risk Doesn’t Belong to the DBA Alone
I might understand a change down to the exact line of PL/SQL or the exact init parameter. That’s not the whole picture, though. There’s a business unit somewhere that cares why this is even happening. There’s a risk officer who wants to know what breaks if it goes wrong. Someone on the ops floor needs a rough time window, not a precise one — “sometime after 11 PM” is usually good enough, but they need that much. And somebody, at the end of it, has to actually tell people it’s done, or that it wasn’t, because a silent change is almost worse than a failed one.
That separation — between the person who technically owns the change and the people who own the business accountability for it — took me a while to fully appreciate. It’s not redundancy. It’s a genuinely different kind of ownership.
Good Documentation Is Really Just Organizational Memory
If there’s one habit from banking change control I’d tell any DBA to steal, it’s documentation done properly — and I don’t mean a Jira ticket with “fixed issue” in the description. A decent change record covers what’s actually changing and why, what you expect to happen, how you’ll implement and then validate it, what rolling it back involves, and who signed off and who ran it.
It doesn’t feel important while you’re writing it, half the time. It feels like paperwork. Then six months pass, and somebody — often not even you — asks why a certain parameter got changed at all, and the answer really shouldn’t depend on whether the person who made the change still works there. I’ve been the one asking that question more than once. I’ve also been the one thankful, years on, that I’d bothered writing it down instead of trusting memory.
The Rollback Plan Deserves More Attention Than the Implementation Plan
Most of the prep time I see DBAs spend goes into figuring out how to make a change. Far fewer spend equal effort figuring out how to undo it, and for database changes specifically, undoing something is often the harder half of the problem.
Before I’ll touch anything in production now, I want honest answers to a short list: can this actually be reversed, and how fast? What data will already have changed by the time we’d need to roll back? What else depends on this that I haven’t thought of? Does reversing it require downtime of its own? What does replication do during and after? What happens to application connections mid-change?
If the honest answer is that rollback isn’t really possible, that change earns a lot more scrutiny before it goes anywhere near production — not less.
Regulation Forces Better Thinking About Failure, Whether You Like It or Not
One underrated side effect of working in a heavily regulated environment is that it trains people to think about failure before they’ve even started implementing. That habit is valuable well beyond banking, honestly.
Take something as routine-sounding as applying a database patch. It’s tempting to stop the planning at “patch the database” and call it a day. I’ve learned to push further than that: what happens if the patch itself fails partway through? What if one RAC node goes down during the window? Will the database even start afterward? Is the application actually compatible with the new version, or did someone just assume it would be? What does replication do? What’s the state of backups going into this? How exactly will we confirm the result was successful, and how will we tell people it worked — or didn’t?
Change Windows Aren’t About Restriction — They’re About Shared Understanding
A properly agreed production change window does something quietly useful: it gives every team the same picture at the same time. DBAs know their working window. Application teams know when their services might blip. Operations knows when to expect alerts and when to actually worry about them. Business stakeholders know when risk is deliberately being introduced into the system.
None of that is about making change harder to execute. It’s about making change predictable, which is a very different goal.
That Said — It’s Possible to Overdo This Entirely
I want to be fair here, because there’s a real failure mode on the other end of this spectrum too. If every trivial change requires the same heavyweight approval as a major upgrade, teams slow to a crawl, and worse — people start quietly routing around the formal process altogether, which defeats the entire point.
The better approach, in my experience, is risk-based rather than one-size-fits-all. Routine monitoring tweaks, non-production configuration changes, and pre-approved standard procedures don’t need the same scrutiny as a production database upgrade, a RAC or Grid Infrastructure change, a storage change, a major parameter shift, or anything touching disaster recovery. Different risk levels genuinely deserve different levels of friction.
The Best Process Is the One People Actually Use
I’ve seen beautifully designed change-control processes that nobody followed in practice, and a beautiful process nobody follows is worth exactly nothing. Good governance should make doing the right thing the easy path, not the hard one — standard templates that don’t need reinventing each time, pre-approved procedures for routine work, clear and known approval paths, evidence collection that happens automatically rather than manually, sensible maintenance windows, and rollback procedures you can actually reuse instead of writing from scratch under pressure.
What I’m really describing is controlled speed. Not speed for its own sake, and not control for its own sake either — the combination is the point.
What Teams Outside Banking Can Actually Take From This
I don’t think the lesson here is that one region has cracked change management and everyone else hasn’t. That’s too simple, and it’s not really what I’ve observed. The real lesson is that regulated environments have, out of necessity, built strong habits around accountability and thinking through failure ahead of time — and those habits transfer well to almost any organization, regulated or not.
Before touching anything in production, I still ask myself the same short list every time: what exactly is changing, and why? What could realistically go wrong? How will we know if it has? Can we actually roll it back? Who needs to be told, before and after? Who’s approved this? What evidence are we keeping once it’s done?
None of that takes long to answer, honestly, maybe five minutes if you already know your environment. Skip it and get unlucky, though, and you could easily lose a weekend cleaning up after an incident that a rollback plan would’ve solved in twenty minutes. I’ve lost weekends like that. I don’t particularly want another one.
Final Thoughts
I used to think of change management as something that got in the way of doing good engineering. I don’t anymore. It’s really just the difference between a change you can explain and defend six months later, and one you’re quietly hoping nobody ever asks about.
The best database teams I’ve worked alongside all land on the same place eventually, whether they came from a bank or a startup: documentation, approvals, testing, a rollback plan, and telling people what happened aren’t the tax you pay for doing good work. That IS the good work, most of the time — the code was often the easy part.
In high-risk environments, what looks like bureaucracy from the outside is, from the inside, just engineering discipline wearing a different name.
