Originally published on Ashdown Systems in August 2026, and revised for this blog. Read the original.
Plenty of people running a small or mid-sized business have never used the phrase “solutions architecture” in a sentence. That’s fine; most don’t need to. But a lot of them are already living with the exact problem it solves, without having a name for it.
The pattern usually goes something like this. You start with a handful of tools: an accounting package, a CRM, maybe a booking system or an online shop. Each one makes sense on its own, solves an immediate problem and gets switched on quickly. Eighteen months later, data is trapped in five different places, someone spends half a day a week copying numbers between systems, and nobody is entirely sure which version of the customer list is the real one.
Nothing broke. There was no single bad decision. It just accumulated. That accumulation is what solutions architecture exists to prevent, and to untangle once it has already happened.
So what actually is it?
The closest comparison I can offer is a chart of accounts. Every department could keep its own records in its own way, and each set of books might be perfectly sensible on its own. But unless someone decides up front how it all rolls together, month-end becomes an exercise in reconciling things that were never designed to agree.
Solutions architecture is that same discipline, applied to how a business’s systems, tools and data fit together. It isn’t about writing code. It’s about answering questions like:
- What is the business trying to achieve, and what will it need from its systems in two years, not just today?
- Which tools should talk to each other, and how?
- Where is the single source of truth for customers, orders and finances?
- If we doubled in size next year, would this setup hold, or would it fall over?
The role sits above any one piece of software. A good architect isn’t there to sell you a CRM or a cloud platform. The job is to work out which combination of things, often including tools you already own, actually serves the business.
Why it matters even if you’re not “technical”
There’s a common assumption that architecture is for tech companies: SaaS businesses, software vendors, engineering-led startups. They certainly need it. But I’d argue non-technical businesses need it more, precisely because nobody in-house is watching for the problem as it forms.
A tech company usually has an engineer somewhere who winces when three systems don’t talk to each other. A retailer, a professional services firm or a hospitality group often doesn’t have that person. The disconnect never shows up as an error message. It shows up as a Friday afternoon spent reconciling spreadsheets, a customer receiving the wrong invoice, or a new starter who takes three weeks to learn “how we actually do things here” because it was never written down or built into the systems.
None of that requires anyone to understand databases or APIs. It requires someone who can look across the whole operation, ask good questions, design something that fits, and then explain it in terms the team can actually use.
What it looks like in practice
For a smaller business, this rarely means a six-month programme. More often it looks like:
- A short piece of discovery to map which tools are in use and where the friction really is
- A clear, plain-English plan for how things should connect: what stays, what goes, what gets automated
- Recommendations proportionate to the size of the business, not “enterprise” answers it might grow into one day
- A roadmap, so the next tool you buy fits into a plan rather than becoming another island
The goal isn’t complexity. Usually it’s the opposite: fewer steps, less manual work, and an end to the quiet version-control chaos that builds up over time.
The cost of not doing it
The businesses that feel this most are usually the ones growing fastest. Every new hire, customer and bolted-on system compounds either a good foundation or a shaky one. The compounding happens either way; the only question is which direction it’s working in.
What I find encouraging is that none of this needs a technical team or a big budget to get started. It needs someone to ask the right questions before the next tool is bought, rather than after the third spreadsheet reconciliation of the month.
