How to brief a software architect

An architect turns a business problem into a system that solves it. The best thing you can bring is not a technical specification but a clear picture of the problem, the outcome you want, and the constraints you live inside. If you hand over a solution you have half-designed, you often lock in a worse answer. Bring the problem sharply and let the design come back to you.

Step by step

1. Describe the problem, not your solutionLead with what hurts: the task that eats hours, the enquiry that goes cold, the number you cannot get on time. Resist the urge to arrive with a solution you have half-built in your head, because a good architect can often see a simpler path than the one you assumed. Your job in the brief is to make the pain unmistakable. The how is what you are paying them to work out.
2. Paint what good looks likeDescribe the outcome you want in plain terms: quotes out the same day, no enquiry unanswered past an hour, the monthly numbers ready on the first. Be concrete about the end state without prescribing the mechanism. This gives whoever builds it a target to design toward and a way to check the design against your real goal. A clear picture of good is worth more than a page of feature requests.
3. Name your constraints honestlyTell the team what you must live with: the systems you already run, the budget you can spend, the deadline you face, the way your team actually works. Constraints are not obstacles to hide; they are the frame a good design fits inside. A team that knows your real limits designs something that lands, while one working blind designs something elegant that never gets used.
4. Walk them through the real workflowShow how the work happens now, step by step, including the messy parts and the workarounds people rely on. The gap between how a process is meant to run and how it actually runs is usually where the value hides. Do not tidy it up for the brief. An architect who sees the real workflow, warts and all, designs for the business you have rather than the one on the org chart.
5. Share the numbers you canBring whatever you can measure: how many enquiries a week, how long a task takes, how often something is missed, what a mistake costs. You do not need precision, you need scale, so the team can weigh where effort pays off. Numbers turn a vague complaint into a sized problem, and a sized problem is one that can be prioritised and justified. Directional figures are enough.
6. Say what you have already triedTell the team what you have attempted and why it fell short: the tool that did not fit, the process that broke, the workaround that half-works. This saves everyone from proposing a path you have already walked, and it reveals the constraints that are not obvious from the outside. A short history of what failed is often the fastest way to a design that finally sticks.