Technical people are good at discovery. Give an architect a week with a system and they will come back with its interfaces, its data stores, its dependencies, its security posture and a list of things that worry them. That work is essential. It is also, very often, done first, and done first it quietly decides what the programme is about.
The reason is simple. Technical discovery produces concrete findings, and concrete findings feel like progress. A diagram of the current estate is satisfying in a way that "we still do not know why customers leave" is not. So the technical picture fills the space where the business question should have been answered, and the design that follows is a response to the estate rather than to the problem.
The distinction we hold to is this. Business discovery explains why change is needed. Technical discovery explains what can safely be changed. Both are necessary, and the order matters. This part sets out the business discovery guide we use, the gate between the two, and what happened at the series' fictional bank when a technical finding sent the team back to the business.
Seven lenses
Klipspringer Bank is fictional, and its systems and figures are illustrative. By the time its architecture team reached this stage, it had a revised problem statement from Part 1 and a measurement frame from Part 2. Business discovery filled in the picture behind the numbers, organised around seven lenses.
Outcome. What result is the business paying for? For Klipspringer, loans booked at acceptable risk, not a modernised form. Every other lens is read against this one.
Process. What actually happens, step by step, including the parts nobody wrote down? Klipspringer found five hand-offs between document upload and a decision, two of which existed only because of a shared mailbox.
People. Who does the work, what do they spend their time on, and what do they work around? Underwriters were re-typing figures from payslips into the loan system, because the document store and the loan system did not talk to each other.
Policy. Which rules shape the work, who owns them and when were they last questioned? Loans above R150,000 needed two signatures. Nobody could say when that threshold was set or why.
Data. What information is used, where does it come from and how good is it? Bank statements arrived as phone photos and scanned PDFs, a large share of them unreadable or incomplete.
Economics. What does the problem cost and what would fixing it be worth? Marketing spent about R1,900 to bring each applicant to a completed application. With roughly 2,170 completed applications a month leaving before a decision, that is over R4 million a month of acquisition spend walking out of the door, before counting the lost interest income.
Exceptions. Where does the standard process not apply? Self-employed applicants took about twice as long, because their income evidence did not fit the payslip-shaped process at all.
Technology is the eighth card in the diagram, deliberately face down. It is not ignored. It simply is not allowed to lead.
How to run it without a six-month study
Business discovery has a reputation for being slow and abstract. It does not need to be either. Klipspringer's took three weeks, run by two people.
Observe, do not only interview. People describe the process as it is supposed to work. Sitting with an underwriter for a morning showed the re-keying, the mailbox and the hunt for missing pages in an hour. Our earlier piece on why the process map is usually fiction covers this in more depth.
Follow cases, not org charts. Pick a handful of real applications and trace each from start to finish. Cases cross team boundaries; interviews usually stop at them.
Talk to the people who say no. Credit risk, compliance and internal audit understand the constraints better than anyone. Bringing them in during discovery, rather than at design review, changes their role from blocker to co-designer.
Talk to customers who left. Klipspringer's most decisive evidence came from ringing applicants who abandoned. Twenty calls were enough to show that most had taken a loan elsewhere.
Write findings as evidence, not opinion. "Underwriters re-key payslip figures, observed in 9 of 12 files" is a finding. "The process is inefficient" is not.
The gate between them
Business discovery ends with a short written output: the problem statement, the measures and guardrails, the constraints that cannot move, and the open questions. Klipspringer's fitted on two pages. The business owner, the head of credit risk and the architecture lead all signed it.
The signature matters more than it looks. It turns a shared understanding into a reference point. When technical discovery starts proposing options, each one can be tested against a document that the business has already agreed, rather than against whoever is most persuasive in the room.
Technical discovery then asks a different set of questions. What does the loan origination system expose, and through which interfaces? Where does each piece of data live, who owns it and how is it protected? Which components are supported, which are end of life, and which are held together by one person's knowledge? What can be changed safely, in what order, and with what rollback? Those answers feed directly into the decisions in Part 4.
When a technical finding reopens the business question
The gate is not a one-way door. Good technical discovery regularly turns up something that changes the business picture, and the process has to allow for that rather than treat it as scope creep.
At Klipspringer it happened in the second week. Mapping the data, the technical team found that about 40% of personal-loan applicants were existing Klipspringer customers whose salaries were paid into a Klipspringer account. The bank already held months of their transaction history. Yet the application asked every applicant, including these, to photograph and upload three months of bank statements, which were the single biggest source of unreadable documents and send-backs.
That was a technical finding with a business question inside it. Did the credit policy require uploaded statements, or did it require evidence of income and expenses? The answer, once credit risk looked, was the second. The upload requirement dated from before the bank could read its own transaction data reliably. With the customer's consent, internal transaction data could satisfy the policy for existing customers.
So the problem statement was updated, re-signed and given a new line: for existing customers with salary paid into Klipspringer, use the bank's own data rather than uploaded statements. It was the cheapest improvement in the whole programme, and neither discovery would have found it alone. The business side did not know the data was available. The technical side did not know the policy allowed it.
What goes wrong when the order flips
When technical discovery runs first, three things tend to happen.
The current estate becomes the frame. Options are described as changes to systems, "migrate the loan system", "replace the document store", rather than changes to outcomes. The question of whether any system change is needed at all never gets asked.
The loudest technical risk becomes the priority. An unsupported database is a real risk, and it will dominate the conversation even if it has nothing to do with why customers leave.
And the business owner disengages. A discovery report full of interface catalogues and dependency maps is not something a head of personal loans can engage with, so they wait for the recommendation, and by then it is too late to shape it.
None of this means technical discovery should wait idly. At Klipspringer the technical team started gathering system documentation and access in week one. What they did not do was propose anything until the problem statement was signed.
Key points
Business discovery explains why; technical discovery explains what can safely change. Run the first one first.
Seven lenses cover the ground. Outcome, process, people, policy, data, economics and exceptions, with technology deliberately last.
Observe real work and follow real cases. Interviews describe the official process; cases reveal the actual one.
Gate the transition with a signed problem statement. It gives every later option something agreed to be tested against.
Let technical findings reopen business questions. Klipspringer's cheapest improvement came from exactly that.
Next: Part 4, Reuse, refactor, replace or retire? All parts are on the series page.
How CloudNala can help
We run business and technical discovery as one short engagement with a clear gate in the middle: observe real work, trace real cases, write and sign the problem statement, then examine the estate against it. The output is a two-page statement the business owns and a technical picture that answers to it, rather than an inventory looking for a purpose.
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