Architecture review vs managed services.

One builds the plan; the other runs it. An infrastructure architecture review is advisory and design work that sits above day-to-day operations: it maps what an estate actually runs today, designs the target it should be moving toward, and hands over documents — a current-state baseline, a target-state architecture, Architecture Decision Records, an HA/DR design, capacity and migration plans, and a board-ready roadmap. A managed service provider sits below that line. It keeps the estate running day to day — patching, monitoring, a service desk, incident response, uptime commitments. The two are not competitors and not substitutes for each other; most estates eventually need both, and the order matters. The review sets the design and the roadmap first; an MSP — the client’s existing one, or one appointed afterwards — then works to it. Buying operations when what is actually missing is a decision, or buying a decision and expecting it to include operations, is where budgets end up spent on the wrong shape of work. Here is the line, and what sits on each side of it.

What the two are actually buying you

An architecture review answers a question: what should this estate look like, and what has to be true for it to hold up under failure and growth? The output is a decision, documented, that a board or a technology committee can fund with confidence. Managed services answer a different question: given a design that already exists, how does it keep running tomorrow, and who is accountable when something breaks at 3am? The output is a continuous operating relationship, priced against ongoing coverage rather than a fixed scope. Neither is a smaller or larger version of the other — they are different transactions, bought for different reasons, at different points in an estate’s life.

What an infrastructure advisor delivers

An architecture engagement at 1722 is scoped from a written statement of work and produces named artefacts, not a slide deck of opinion:

• Current-state baseline — the systems, dependencies and single points of failure that actually exist, as distinct from what documentation claims exists.
• Target-state architecture — a reference design for where the estate is moving, sized against forecast growth rather than current load.
• Architecture Decision Records (ADRs) — the choices made, the reasoning behind each, and the alternatives ruled out, so the logic survives staff turnover and outlives the engagement.
• HA/DR design — RTO and RPO targets, a standby pattern (pilot-light, warm or hot), active-active or active-passive topology where relevant, and DR runbooks.
• Capacity and migration plans — the scaling headroom the target design needs, and, where a migration is in scope, the sequenced steps and rollback path to get there.
• Board-ready roadmap — the programme sequenced against cost and risk, with a technology selection matrix and total cost of ownership attached, ready to take into a funding conversation.

Everything on that list is a document or a decision the client owns outright at the end of the engagement, usable with any team, on any timeline, whether or not 1722 is involved again.

What a managed service provider delivers

An MSP’s value is a different kind of reliability: it manages the estate against a design that already exists. That means patching and OS administration, continuous monitoring and alerting, a ticketing and service desk function, incident response, and — usually the commercial centre of the contract — service-level agreements defining uptime and response times. None of that is advisory work, and none of it produces a target architecture; it operates against one. A capable MSP executes a good design well and can flag operational risk as it appears, but its contract is not written to interrogate whether the underlying architecture is still the right one — that is a separate question, asked separately, on a separate cycle.

Where the line sits, and why it matters

The architecture layer sits above day-to-day operations. Its output is a set of documents the client’s own team, or their existing MSP, then acts on. There is no ongoing management contract attached to a 1722 architecture engagement, no service desk and no uptime commitment, because that is deliberately not the work being sold. This is not a limitation to work around — it is what keeps the recommendation independent. An advisor whose fee depends on how much operational coverage gets sold afterwards has a reason to design toward more coverage. 1722 sells no infrastructure product, hardware or licence, takes no vendor or MSP commission, and has nothing to gain from the shape of the operational contract that follows the design. The roadmap is scored against the client’s requirements and total cost of ownership, not against anyone’s margin.

When to buy which — or both

Three situations, and they call for different starting points:

• The design hasn’t been funded yet. If a board or technology committee has not signed off on a target architecture, resilience posture or migration plan, an MSP contract cannot supply that decision — it can only execute whatever design it is handed. Start with a review.
• The design is sound but operations are stretched. If the architecture is documented and current, and the gap is coverage — patching cadence, alert response, a helpdesk function — that is squarely an MSP conversation, not an architecture one.
• Neither exists yet. Most growing estates need both, in sequence: the review first, so the operational contract that follows is built against a design that has actually been tested on paper, rather than inherited from whoever built the estate originally.

Can the same firm do both?

Some integrators sell architecture and operations as one bundled relationship, and there is an obvious appeal to a single point of contact. The trade-off is independence: a firm that also wants the managed-services contract has a commercial reason to shape the design toward more billable operations, not fewer. 1722’s architecture work stays advisory and design only — the review, the roadmap, the documents — and the client’s own team or existing MSP keeps the estate running against them. Hands-on implementation support is available once the design is agreed and trust has been established through that work, and it is always optional, never a condition of the architecture engagement and never a lock-in into an ongoing contract.

The short version: buy the review to get the decision made and documented. Buy managed services to keep a decided design running. Confusing the two costs a budget cycle; keeping them separate is what makes each one trustworthy.