A restaurant owner says the business needs a new ordering app because meals are arriving late. The app is five years old, it looks it, and customers have complained. A new app is easy to picture, easy to price and easy to approve.
Then someone stands in the kitchen for an evening. Orders arrive on time. They sit on a rail because one chef plates every dish, a supplier delivered half the vegetables, and refunds need the owner's signature while the owner is at the other branch. A new app would send orders to the same rail, faster.
Architecture work begins in the kitchen, not in the app store. It starts by locating the delay, the failure or the cost the business is actually suffering, and only then asks which technology, if any, would change it. That sounds obvious. It is skipped constantly, because a request for a specific technology arrives already shaped like a project: it has a scope, a budget line and a sponsor who has already told the board what is coming.
This six-part series is about the work that comes before the target architecture: turning complaints into numbers, separating business discovery from technical discovery, deciding what to reuse, refactor, replace or retire, choosing the views that let a decision be made, and writing a proposal that follows the way decisions actually get taken. One fictional bank carries the examples throughout.
The request
Klipspringer Bank is fictional, and its systems and figures are illustrative. Klipspringer is a mid-sized South African bank headquartered in Johannesburg. Its personal-loans unit sells unsecured loans to salaried customers, mostly online, and for two years its loan book has been flat while competitors have grown.
The board's explanation is straightforward. The online application was built in 2014 and looks like it. Younger customers are used to banking apps that feel instant. A digital bank and two lending fintechs are advertising heavily. So the board approved an 18-month programme to modernise the loan application journey and move it onto a public cloud platform, with a budget to match, and asked the architecture team for a target design.
Nothing in that request is unreasonable. The interface really is dated. The cloud move may well be sensible for other reasons. And if the architecture team had done exactly what was asked, it would probably have delivered a good-looking, well-engineered application on schedule.
The loan book would still have been flat.
What the funnel showed
Before drawing anything, the team asked a dull question: where, exactly, do applicants go? The bank already had the data. Nobody had joined it end to end, because the website analytics belonged to digital marketing and the application records belonged to credit operations.
Joined up, an illustrative month looked like this. About 10,000 people started an application online. About 6,200 finished it and uploaded their payslips and bank statements. That drop on the form itself was broadly in line with the bank's other digital products, which is to say it was not where the business was haemorrhaging.
The haemorrhage was after submission. Of the 6,200 completed applications, about 35% never reached a decision. Customers who had done all the work, filled in every field and uploaded every document, went quiet while their application waited for manual approval. Approval took five to seven working days. One of the competitors the board was worried about decided within hours.
The team rang a sample of those customers. Most had not abandoned the idea of a loan. They had taken one somewhere else, usually from a lender that answered first.
That reframes the whole programme:
The board's theory ran from an old form to frustrated customers to a flat loan book. The evidence ran from finished forms to a long wait to customers leaving before a decision. Both stories end in the same place. Only one of them is true, and the true one is not fixed by a new interface.
Delivering the request can still fail the business
It is worth being precise about what went wrong in the original framing, because it is not that anyone was foolish.
The request named a solution, not an outcome. "Modernise the application and move it to cloud" is a description of work. The outcome behind it, more loans booked at acceptable risk, was assumed rather than stated, and so nobody checked whether the work would produce it.
The evidence was split across owners. Marketing could see the form. Credit operations could see the queue. Neither could see the whole journey, so each held a partial and plausible explanation.
Technology requests are easier to approve than process changes. A new platform has a vendor, a price and a plan. "Underwriters wait two days before they open a file" is awkward, belongs to a manager who reports to someone else, and does not come with a glossy demonstration.
This is why we treat any requirement that names a technology as a hypothesis to test, not a scope to accept. Never accept a technology requirement without the outcome behind it. Ask what the technology is supposed to change, by how much and for whom, and then check whether the evidence supports the link.
The revised problem statement
Once the funnel was on the table, the team wrote a problem statement short enough to fit on a slide and specific enough to test:
Reduce the time from a completed loan application to a credit decision from five to seven working days to the same day for at least 60% of applications, and reduce post-submission abandonment from 35% to under 15%, without weakening affordability, fraud or credit-risk controls.
Three things make this useful.
It names the outcome in the business's own terms. Decision time and abandonment are things the credit and sales teams already care about and can measure.
It has a baseline and a target. Five to seven days and 35% are the starting point; same day for 60% and under 15% are the bar. In six months anyone can check.
It names what must not get worse. Affordability assessment is a legal obligation for a South African credit provider under the National Credit Act, and fraud and credit risk are the bank's own appetite. A faster decision that lends badly is not an improvement. Writing the constraint into the statement stops the programme from quietly trading it away.
If you cannot write a statement like this, you are not ready to design. The temptation is to start sketching while the problem is still forming, on the grounds that the drawing will help people think. Sometimes it does. More often the drawing becomes the scope, and the problem never gets written down at all.
How the scope changed
The revised statement did not cancel the programme. It changed what the programme was for, and that changed almost every line of the plan.
The interface work shrank to two improvements that mattered: tell customers what documents are needed before they start, and show them where their application is once they submit. The new centre of gravity became the decision itself: why applications waited two days before anyone opened them, why so many needed a second look, which rules lived in a spreadsheet only two underwriters understood, and how much of the review could be automated without touching the risk appetite.
The cloud question did not disappear either. It became a narrower and better question. Not "should the loan application move to the cloud?" but "where should a new decision service and a document-checking pipeline run, given the bank's security and data requirements?" That question has an answer that someone can defend. The original one mostly had opinions.
Part 4 goes through what Klipspringer ended up keeping, changing, replacing and switching off. The short version is that the two largest systems in the journey were left alone.
Why this matters more now
Two things make the pattern more dangerous than it used to be.
The first is that technology has become cheaper to start. A cloud platform, a low-code tool or an AI model can be running in days. That speed is genuinely valuable once the problem is clear. When it is not, it just means the wrong thing gets built sooner, and with more momentum behind it.
The second is AI itself. "We need an AI strategy" is the new "we need to move to the cloud". In our experience, the organisations that get value from AI are the ones that started with a specific delay, error or cost and asked whether a model could reduce it. Klipspringer's real problem, a decision bottleneck full of repetitive document checks, is exactly the kind of place where automation and some careful use of AI might help. It only became visible because nobody started with the AI.
Key points
A technology request is a hypothesis. Ask what it is meant to change, by how much and for whom, and check the evidence before accepting it as scope.
Join the evidence end to end. Klipspringer's answer sat in two data sets owned by two teams who had never put them side by side.
Write the problem statement before the design. Baseline, target and the controls that must not get worse, in one paragraph.
The scope follows the problem. The programme survived, but its centre moved from the screen to the decision.
Fast technology makes this more important, not less. Cheap starts build the wrong thing sooner when the problem is unclear.
Next: Part 2, Turn words into numbers before you design. All parts are on the series page.
How CloudNala can help
We run short discovery sprints that start with the outcome, not the platform: join the data that already exists, walk the real journey, and write a problem statement the business can sign and test. Sometimes that confirms the original request. Often it moves the centre of the work somewhere cheaper and more useful, and it always gives the design that follows something concrete to answer to.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Discovery Sprint or write to us at consult@cloudnala.co.za