Cloud, DevOps and Continuous Delivery

Why your last release happened on a Saturday

Ask an institution when it last put a change in front of customers and you get a story, not a date. It went out on a Saturday night, with several people on a call, two of them senior enough to have better things to do. There was a plan if it went wrong and a shared hope that nobody would need it. By Monday it had held, and everyone quietly agreed not to do that again soon.

That last part is the expensive one. When a release is an event, the sensible response is to have fewer of them. Changes wait for the next window, the wait makes the next release larger, a larger release is genuinely more dangerous, and the danger justifies waiting longer still. Institutions rarely decide to move slowly. They arrive at it one decision at a time.

The cost is not weekend overtime. It is the answer you give when the business asks for something: a fee changed before a campaign starts, a partner supported this quarter, a correction to what customers are shown. The answer is set by your release calendar rather than by the size of the work, and people learn to stop asking.

Then the question nobody enjoys. The setup your services run on was assembled over years by people making sensible decisions in the moment, some of whom have moved on. If it were lost tomorrow, few institutions could say what it would take to have it back, or how long. Nobody wants to test that answer.

What changes when a release stops being an event

The plainest measure is the distance between a decision and customers having it: the meeting where it is agreed, the approval, the wait for a window, the release, and the checking afterwards. Shorten it and the business starts asking for things again, because asking has stopped being expensive.

For the people who run the service, what changes is the temperature. Work happens in working hours, fewer people need to be in the room, and fewer changes are made straight onto a live service at midnight by whoever was reachable.

For risk and audit, the useful change is evidential. Your policy already says who may approve a change and what must be recorded. What is often missing is the ability to answer, months later and without people reconstructing it from memory and email, what was changed, when, and who agreed to it. Supervised institutions get asked that.

Then recovery. Being able to say what it would take to get a service back, with something behind the answer, turns a board conversation about continuity from an act of faith into a plan. It also widens what an institution will attempt, because the cost of being wrong stops being open-ended.

Whose problem this is, and in what form

For a bank the constraint is rarely appetite. It is that the governance around change was built for occasional vendor upgrades and now applies to everything, including a correction to wording on a screen. What your policy should ask of a small change as against a significant one belongs to risk and audit rather than to a technology team.

For SACCOs and microfinance institutions the exposure is concentration. The service runs, and one supplier or one person knows how. It is simply where a small institution ends up after a few years. The question is what happens when that person leaves or that relationship ends, and whether the work could be handed to someone else without starting again.

Telcos and established fintechs have the opposite pressure: so many parties depend on them that the window in which anything may change is contested and short. Younger fintechs have no window at all. They change constantly, but little of it is written down and recovery has never been tested. The first serious partner, or the first supervisory conversation, is where that becomes urgent.

Not all of your estate is yours to change. Vendor systems move on the vendor's schedule. What changes is the share you genuinely control, and what you can reasonably ask of a supplier once you can show how you run your own.

The cloud question, decided commercially

Cloud is treated as a technical preference far more often than it deserves. It is a commercial and regulatory decision, and it starts with where your data may sit. Banking is supervised by the Bank of Tanzania, and Tanzania has a Personal Data Protection Act. What either means for holding customer information outside the country is for your compliance and legal functions to settle, not something to infer from a hosting brochure.

Then the commercials. Equipment you own is a purchase you plan for once. Hosted capacity is a recurring bill that follows use, often in a foreign currency, which makes it a treasury question as much as a technology one. Reaching a distant region carries a connectivity cost, and hosting within Tanzania and the region is worth pricing properly rather than dismissing.

Most institutions end up somewhere in between, and that is a legitimate destination rather than a failure to commit. What matters commercially is that the split was chosen for reasons you can defend to your board and your supervisor, and can be revisited later.

What sits on your side

The largest thing you contribute is not access to systems. It is a willingness to look again at how change is governed. If every change must still wait for a monthly committee regardless of what it is, you will get a better documented version of the pace you have now. That may be the right answer for your institution, but it is a decision for your risk committee rather than for engineering.

Then the arrangements. Hosting and licensing agreements need someone with authority to sign them and someone in finance to own what they cost each month, a different discipline from approving a purchase once. Where a supplier holds those accounts on your behalf, moving them into your own name is easier before a live service is attached.

And the people. Whoever runs your services after launch, whether two people internally, a supplier, or a mixture, should be named while the work is being scoped rather than found once it is finished. Their hours and what they handle without help are operating decisions with a cost attached. We will train them. We cannot decide who they are.

Working with us

We start with discovery: how a change reaches your customers today, what governs it, what you run and where, and what your position on data actually is. That produces a scope and a plan, and the plan is yours whether or not we build anything.

Through delivery you see working software in an environment you control rather than status reports, and the source code and documentation are yours from the first commit. Afterwards we support what we build and train your people to take on as much as they want. This is the one platform you should be able to run without us, and the contract is written so that you can.