If you've found your way to this page via a search for "business systems architect", there's a reasonable chance you were expecting something about software engineering, Salesforce configuration, or enterprise IT infrastructure. This isn't that.

I'm Rachel McNab, a fractional COO and business systems architect based in St Albans, UK. The work I do is operational, not technical. I help service-driven small businesses and teams replace scattered ways of working with calm, connected systems that actually hold up as the business grows, focusing on the structure, processes, and tools that make a business easier to run for everyone inside it.

This post explains what a business systems architect does in the operational sense and why the distinction matters if you're trying to work out what kind of help your business actually needs.

Where the confusion comes from

"Business systems architect" is a title that exists in two very different worlds.

In the IT and enterprise software world, a business systems architect is typically someone who designs the technical infrastructure of an organisation like the databases, integrations, platforms, and software ecosystems that underpin large-scale operations.

It's a highly technical role, usually found in mid-to-large corporations, and it requires a background in software development or enterprise IT.

In the operational consultancy world, which is where I work, a business systems architect is something quite different. It's someone who looks at the way a business actually functions: how information flows, how tasks are owned, how processes are documented, how tools are connected. The focus isn't on the technology itself. It's on the human system the technology is supposed to be serving.

The title is under-used in the UK operational space, which is exactly why I use it. It describes the work precisely and it signals something that "consultant" or "operations director" doesn't quite capture: that the job is to design something, not just advise on it.

What a business systems architect actually does

The simplest way to describe it: I look at how a business works underneath the surface, identify where the structure is fragile or missing, and build something more reliable in its place.

In practice, that involves four things.

Understanding how the business operates.

Not how the CEO imagined it would operate, or how it operated two years ago but how it works right now, in practice, for the people working inside it. That means talking to the team, mapping the processes, understanding where information lives and where it gets lost, and identifying the workarounds that have quietly become permanent fixtures.

Identifying the gaps.

Every business I work with has the same four operational gaps to some degree: knowledge that isn't documented and accessible; tasks and workflows that don't have a clear owner; information that's hard to find or stored in too many places; and tools that aren't connected and are creating duplicated effort as a result. The job is to understand which of these gaps is causing the most friction and in what order they need to be addressed.

Building the right structure.

This is where the architecture comes in. It might mean selecting and building a project management system that fits the way the team actually works. It might mean connecting a CRM to an accounting tool so information flows automatically rather than being typed twice. It might mean documenting the core processes of the business so that they can be handed over, delegated, or handed to a new team member without everything depending on someone explaining it from scratch. The specifics vary. The goal is always the same: a business that runs calmly and doesn't depend on any one person holding everything together.

Making sure it sticks.

A system that gets built but not adopted isn't a system... it's a very expensive document that nobody reads. Part of the work is always training the team, embedding the new way of working, and making sure the structure actually reflects how the business operates rather than how a template assumes it should.

How this is different from hiring a consultant

A traditional consultant will usually review a business, provide recommendations, and hand over a report. That has value - particularly for businesses making complex strategic decisions. But for most small service businesses and SMEs, a recommendations report isn't what's needed. What's needed is someone who can identify the problems and then actually fix them.

That's the distinction I'd draw between a consultant and a business systems architect in the operational sense. A consultant tells you what needs doing. A business systems architect builds it.

It's also different from hiring a VA or an OBM, both of whom are typically there to support an existing operational structure rather than design a new one. And it's different from a tech specialist or automation agency, who tend to lead with a specific tool or platform rather than starting from the business's actual needs and working backwards to the right solution.

The business systems architect role sits in the gap between strategic advice and hands-on implementation. It's both things at once and for small businesses that don't have the internal capacity to execute on advice without help, that combination is usually what makes the difference between a system that gets built and one that stays on the to-do list indefinitely.

Who this is for

The businesses I work with as a business systems architect tend to fall into one of three situations:

The first is the small team that has been running on spreadsheets and knows it isn't sustainable anymore. They need better tools, but they don't have the time or expertise to work out which ones, set them up properly, and train the team on them. That's what my Simplify service is designed for.

The second is the established team that already has all the tools: a CRM, a project management platform, accounting software, but they aren't connected, and the team is spending a significant amount of time duplicating effort as a result. They need a full operational overhaul: audit first, then clear recommendations, then full implementation of everything agreed. That's Evolve.

The third is the founder who needs ongoing operational leadership. Someone who owns the operational roadmap, thinks proactively about how the business is functioning, and brings solutions rather than waiting to be asked. That's the fractional COO engagement.

In all three cases, the starting point is the same: understanding how the business actually works, finding where the structure is letting it down, and building something better.

Why "architect" and not something else

I've been asked why I use "architect" rather than "consultant" or "specialist" or "expert" - all of which would be more conventional.

The honest answer is that "architect" is the most accurate word for what the work involves. Architecture is the practice of designing something that needs to function reliably, hold up under pressure, and serve the people using it. That's exactly what operational systems work is. It isn't consulting in the sense of providing advice and stepping back. It's designing, building, and handing over something that works.

There's also something in the word that captures the balance between the strategic and the practical. An architect understands the materials, they think about how the building will actually be used, and they stay involved through the build to make sure what gets constructed matches what was designed. That's the shape of the work I do.

What this looks like in practice

Every engagement starts with understanding by having a proper look at how the business is currently operating, where the friction is, and what the team actually needs. From there, the work varies depending on the situation: it might be a focused systems setup for a small team moving off spreadsheets, a full operational overhaul for an established business whose tools aren't working together, or ongoing fractional COO support for a founder who needs someone owning the operational function on a longer-term basis.

What stays constant is the approach: start with the business, not the technology. Understand the people before picking the platform. Build something that fits the way the team actually works, not the way a template assumes they should.

If you're trying to work out whether this is the kind of help your business needs, the clearest question to ask is this: do things keep falling through the gaps, and do you find yourself absorbing the consequences? If the answer is yes and the problem keeps coming back no matter how hard you work, it's usually a structure problem with a structural solution.