When a Company Needs External Digital Architecture

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.

With AI, this gap has grown, not shrunk. There are now tools with real leverage even in smaller businesses. But someone has to decide which use case will carry, where the data is allowed to run, and how the new fits into the existing systems. That is architecture work.

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. Whether an AI initiative has real leverage in your business or is just the current hype. Management makes the decision, but gets a well-founded recommendation first rather than a polished sales pitch.

Steering implementation, building the critical parts. 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. And where it counts, things get built: with me, AI use cases and automations do not end as concept papers but as running systems. Examples live in the Lab.

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 (depending on structure, up to roughly 300 employees – the decisive line is the absence of a corporate-style internal IT organisation).
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 compact assessment follows, 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, ongoing support, or the realisation that some internal groundwork needs to happen first.

What does not happen: a large mandate without a trial. If working with the visibility of an architect does not suit the organisation, that should become apparent early, not after a long standstill.