A business of thirty people and a business of three hundred need the same layers. What changes is how much of each, and how much the decisions cost to reverse.
This is a map of those layers rather than a recommendation of products. Its purpose is to show which decisions are consequential, which are interchangeable, and where each one is examined properly.
The layers
| Layer | What decides it | Reversibility |
|---|---|---|
| Identity | Where your people already are | Very low — everything authenticates against it |
| Network | Site count and growth horizon | Low — addressing outlives hardware |
| Perimeter | Who will operate it | Moderate |
| Remote access | Where staff work from | High |
| Compute | Guest operating system mix and licensing | Low |
| Storage and backup | RPO, and where the immutable copy lives | Moderate |
| Communications | Call concurrency, not headcount | Low — migration is disruptive |
| Business applications | Whether you differ from everyone else | Very low for data, lower than expected for code |
| Observability | Whether anything is instrumented | High |
| Automation | Which processes are stable | High |
Read the third column first. Four layers are difficult to reverse and deserve the deliberation; four are easy to change and should not absorb months of evaluation.
The layers that are hard to reverse
Identity
Everything authenticates against it, so changing it means touching everything. The decision is usually already made by where the business's email and productivity suite live, and the important discipline is not adding a second directory alongside it.
Addressing
Switches get replaced; the addressing plan does not, because changing it means every device, every firewall rule, every DNS record and every hard-coded address. Leaving room between segments and avoiding the ranges consumer routers use are decisions that cost nothing at design time.
Data
Applications get replaced, sometimes more than once, while the business continues to hold the same customers, orders and history. The database engine is therefore the most consequential single choice in the application layer, and exotic stores should be justified against a specific requirement.
Telephony
Migration means renumbering extensions, re-provisioning every handset, re-cutting trunks and rebuilding every queue and routing rule. It is one of the few migrations where a bad hour is immediately audible to customers, which is why the platform should be chosen against where the business will be in several years.
The layers where the choice matters less than the operation
For the remaining layers, the common failure is not a wrong product. It is a correct product nobody operates.
- A firewall nobody can recover is a business-wide outage waiting for a hardware fault, regardless of which firewall it is.
- A monitoring system nobody reads detects nothing, regardless of which one it is.
- A backup nobody has restored is an assumption, regardless of which product wrote it.
- An automation nobody owns becomes a process the business cannot modify or debug when its author leaves.
This is why the operating question — who owns this, and what happens at 2am — appears in every article on this site about choosing a platform. At this scale it is more predictive of outcomes than any feature comparison.
What changes with size
| Layer | Around 30 people | Around 100 | Around 300 |
|---|---|---|---|
| Identity | Cloud directory | Directory plus conditional access | Plus access review and privileged access |
| Network | One switch, maybe two | Collapsed core pair, segmented | Same, plus device-level hardening |
| Compute | One host, backed up | Two hosts, workloads separable | Clustered where RTO justifies it |
| Backup | Off-site copy, tested | Plus an immutable copy | Plus documented and rehearsed restore |
| Observability | Uptime and backup alerts | Metrics plus central logs | Plus business outcome alerting |
| Communications | Hosted or small on-premises | Sized on concurrency | Redundant paths, no single point of failure |
| Support model | One person or a provider | Named owners per area | Rotation with escalation |
The last row is the one that gets left behind. Businesses upgrade every technical layer while the support model stays as it was at thirty people, which is how estates end up depending on one person who cannot take a holiday.
Where each layer is examined properly
This article is deliberately a map. Each layer has its own decision, its own failure modes and its own article, listed below.
Which technology decisions are hardest to reverse?
Four: identity, because everything authenticates against it; network addressing, because changing it means touching every device, firewall rule, DNS record and hard-coded address; the database engine, because data outlives the applications built on it; and telephony, because migration means renumbering extensions, re-provisioning handsets, re-cutting trunks and rebuilding every routing rule. These deserve deliberation. Remote access, observability and automation are comparatively easy to change and should not absorb months of evaluation.
Does a business of thirty need the same layers as one of three hundred?
Yes — the layers are the same, and what changes is how much of each and how expensive the decisions are to reverse. A thirty-person business needs identity, network, perimeter, remote access, compute, backup, communications, applications, observability and automation just as much; it needs less of each, and it has more freedom to change its mind later.
What is the most common gap as a business grows?
The support model. Businesses upgrade every technical layer while the arrangement for operating them stays as it was at thirty people, which produces an estate depending on one person who cannot take a holiday. Named owners per area at around a hundred people, and a rotation with an escalation path beyond that, are as much a part of the stack as any product in it.
Does the choice of product matter less than expected?
For most layers, yes. The common failure is not a wrong product but a correct product nobody operates — a firewall nobody can recover, a monitoring system nobody reads, a backup nobody has restored, an automation nobody owns. At this scale the operating question is more predictive of outcomes than any feature comparison, which is why it appears in every platform decision on this site.
In what order should these layers be built?
Identity and knowing what you have come first, because almost every later control depends on them. Operability — patching, monitoring, logging, joiner-mover-leaver — comes second. Reducing blast radius through segmentation, privilege removal and retention comes third. Capability projects such as custom software, automation and cloud migration come last, not out of caution but because each is cheaper and more likely to succeed once the earlier stages exist.
Sources and further reading
- An IT roadmap for a growing business— the order these layers should be built in
- Network design for a growing business— the network and addressing layers
- pfSense in a business network— the perimeter layer, and the operating question
- VMware vs Hyper-V— the compute layer
- Asterisk vs 3CX: choosing a phone platform— the communications layer, decided on concurrency
- Choosing a technology stack for business software— the application layer, and why data is the least reversible part
- Infrastructure monitoring that works— the observability layer
- Business process automation: what to automate and what to fix— the automation layer, and what belongs in it
- Hybrid infrastructure: deciding what goes where— which layers live where
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.