When a Mid-Sized Business Needs a Fractional Digital Architect

Most mid-sized businesses do not have an IT problem. They have an architecture problem.

The tools work. The servers run. Emails arrive. But nobody has the full picture. Nobody decides which software stays and which goes. Nobody ensures that the systems grow with the business. Classically, this gap is filled by a CIO or Head of IT. For a company with 30 employees, that is unaffordable. So the gap stays open.

A Fractional Digital Architect closes it. Not as an external IT service provider working through tickets. But as a strategic function, purchased on a part-time basis.

What a Fractional Digital Architect does

Three things:

Establishing an overview. Which systems are in use, how do they connect, where are the authoritative data sources. A clearly documented tool map is the foundation of every decision. It does not exist in most SMEs.

Preparing decisions. Which software should be replaced, which should stay. Where does integration make sense, where migration. Whether a new tool is actually needed or whether an existing one just needs to be used properly. Management makes the decision, but gets a well-founded recommendation first rather than a polished sales pitch.

Coordinating implementation. When a migration is underway, someone is responsible for making sure it does not stall. Service providers are managed, timelines are maintained, pitfalls are anticipated. Not turning every screw personally, but ensuring the right screws get turned.

When the model fits

The model fits when all three conditions are met:

1. The company is large enough that IT is complex enough to warrant strategy (roughly from 10 employees).
2. The company is small enough that a full-time IT lead is not economically viable (roughly up to 80 employees).
3. There is someone at management level willing to treat IT as a strategic topic, not a nuisance.

Point three is the hardest filter. If management expects “IT to sort itself out”, the model does not work. Strategic decisions cannot be delegated — they can only be prepared.

When the model does not fit

The model does not fit when:

• The real problem is a concrete one (broken printer, slow internet, hacked inbox). That requires an IT service provider, not an architect.
• The company already has a competent IT lead internally. Then there is nobody to complement.
• The expectation is that someone is available 24/7 to fix screens. That is help-desk work, not architecture.
• The goal is building an in-house software development team. That is a different function (CTO, Engineering Lead).

Honestly: in two out of three initial conversations, I end up recommending something other than working together. A good local service provider, a specific software project with a specialist, hiring someone full-time. When the model fits, it fits properly. When it does not, no amount of effort helps.

How an engagement begins

The initial conversation clarifies whether the model fits. If it does, a structured assessment follows: two to three days of work, resulting in a documented tool map plus a list of prioritised recommendations. From there, it develops into either a concrete project with a clear end, an ongoing engagement as a monthly retainer, or the realisation that some internal groundwork needs to happen first.

What does not happen: a year-long contract without a trial. If working with the visibility of an architect does not suit the organisation, that should become apparent early — not after months.