Architecture Before Technology
A client asks for cloud, a new app or an AI assistant. Delivering exactly that can still fail the business, because the request is usually a theory about the problem rather than the problem itself. This six-part series sets out the method behind good architecture work: locate the real constraint, turn vague complaints into numbers, run business discovery before technical discovery, decide whether to reuse, refactor, replace or retire, draw only the views a decision needs, and write a proposal that follows the client's own decision path. One fictional South African bank and its personal-loans unit carry the examples, and every figure is illustrative.
6 articles
- Part 1The client asked for cloud. The problem was approval time.A bank asks for a modernised loan application on a new cloud platform. The application is not why the loan book is flat. Part 1 shows how a request can be delivered perfectly and still fail the business, and why architecture starts by finding the delay rather than choosing the platform.8 min read
- Part 2Turn words into numbers before you design"Slow", "clunky" and "too expensive" are real complaints, and none of them is a design input yet. Part 2 shows a five-question frame for turning vague words into a baseline and a target, how to find numbers when the data is poor, and why the measure that must not get worse matters as much as the one you want to move.7 min read
- Part 3Business discovery before technical discoveryTechnical discovery tells you what can safely change. It cannot tell you why anything should. Part 3 sets out a reusable business discovery guide built on seven lenses, the written gate that separates it from technical discovery, and why a good technical finding should be allowed to reopen the business question.7 min read
- Part 4Reuse, refactor, replace or retire?Modernisation is often read as rebuild or migrate, as if those were the only verbs available. Part 4 offers a three-question decision model for each capability, shows how it differs from the cloud migration Rs, and walks through how a bank's loan journey ended up with four different answers and its two largest systems left alone.7 min read
- Part 5The architecture views needed to make a decisionAn architecture pack can run to forty diagrams and still leave a decision-maker unable to decide. Part 5 sets out the smallest useful set of views, grouped by the question each answers, why a good review starts with the customer journey, and how a decisions log ties the set together.7 min read
- Part 6A proposal should follow the client's decision pathThe winning proposal is rarely the one with the most diagrams. It is the one that makes the evaluator's path to a decision easy to follow. Part 6 connects discovery to proposal writing: six steps in the order decisions are actually made, a worked example from the series' fictional bank, and what changes when you are the bidder rather than the internal team.7 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala