03 · Infrastructure architecture
The plan your infrastructure decisions rest on.
Independent, senior infrastructure architecture — advisory and design only. You get a current-state baseline, a target architecture, Architecture Decision Records, HA/DR design and a board-ready roadmap: documents you own and can act on with any team. We build the plan; we don’t run your stack.
No infrastructure product, hardware or licences sold, and no vendor or SI commission taken. The architecture layer sits above day-to-day operations — your internal team or MSP keeps running it.
How the work runs
Four moves, in order.
Architecture work follows a fixed arc, whether the entry point is a two-week review or a full target-state programme.
- 01
Map the estate
A current-state baseline of what actually runs today: systems, dependencies, single points of failure and the gap between documented and real architecture.
- 02
Design the target
Reference and target-state architecture, resilience and HA/DR design, and a capacity and scalability plan sized to where the business is going.
- 03
Set the governance
Architecture Decision Records that capture what was chosen, why, and what was ruled out — so the reasoning survives past this engagement.
- 04
Fund the roadmap
A technology selection matrix with TCO and a board-ready roadmap sequencing the work, with costs and risks attached, ready to take into a budget conversation.
What you get
Deliverables you own.
Every engagement ships named artefacts, not advice alone.
- Current-state baseline — systems, dependencies and single points of failure, documented
- Reference & target-state architecture — the design the estate is moving toward
- Architecture Decision Records (ADRs) — the choices made, the reasoning and the alternatives ruled out
- HA/DR design — RTO/RPO targets, standby pattern (pilot-light, warm or hot), and DR runbooks
- Capacity & scalability plan — sized against forecast growth, not just current load
- Migration plan — sequenced steps, dependencies and rollback, where a migration is in scope
- Technology selection matrix — options scored against requirements and total cost of ownership
- Board-ready roadmap — the sequenced programme, with costs and risks attached
Scope
Where the architecture ends and operations begin.
The architecture layer sits above day-to-day operations. It sets the design, the resilience targets and the roadmap; your internal team or your existing MSP keeps the estate running against them.
This line is entry-scoped by design: an Infrastructure Architecture Review or a Resilience & DR Assessment, fixed in time and price from a written statement of work, before any larger programme is scoped. Hands-on implementation support is available once the design is agreed and trust is earned through that work — it is always optional, and never a condition of the architecture engagement or a lock-in.
Get the architecture decided before the budget is.
Start with a fixed-scope review. A short discovery call, then a scoped plan.
FAQ
Infrastructure architecture, answered.
Is this a managed services or outsourcing arrangement?
No. Infrastructure architecture at 1722 is advisory and design work — the architecture layer that sits above day-to-day operations. The output is a set of documents and decisions your team or your existing MSP then acts on. There is no ongoing management contract, no helpdesk and no service-level agreement attached to this line, because that is not the work.
What do I actually get at the end of an engagement?
Named artefacts, not a slide deck of advice: a current-state baseline, a reference and target-state architecture, Architecture Decision Records, an HA/DR design with RTO/RPO targets and standby patterns, a capacity and scalability plan, a migration plan where relevant, a technology selection matrix with TCO, and a board-ready roadmap sequencing the work with costs and risks attached. All of it is yours to keep and act on with any team.
Are you neutral on vendors and systems integrators?
Yes. 1722 sells no infrastructure product, hardware, licence or cloud reseller margin, and takes no vendor or SI commission. Technology selections in the roadmap are scored against your requirements and total cost of ownership, not against a partner relationship.
Can you implement the roadmap once it is agreed?
Hands-on implementation support is available once trust is established through the design work, and it is always optional — never a condition of the architecture engagement and never a lock-in. You can hand the roadmap to your internal team or existing MSP to build, or ask 1722 to stay involved for specific phases. Either way, the architecture and the build are scoped and priced separately.
How is an engagement scoped?
The usual first step is a fixed-scope engagement — an Infrastructure Architecture Review or a Resilience & DR Assessment — priced and timeboxed up front from a written statement of work. Larger programmes (full target-state architecture, multi-year roadmap) are scoped after the review, on a day-rate or fixed-scope basis depending on what is being decided.
What is the difference between HA and DR in this work?
High availability (HA) is architecture that keeps a system running through a component failure inside a site — redundancy, failover, no single point of failure. Disaster recovery (DR) is the plan and the standby capacity for recovering a system after the loss of a site or a major failure, defined by RTO and RPO targets, a standby pattern (pilot-light, warm or hot), and a tested runbook. Most estates need both, scoped and designed together rather than treated as one line item.
Who typically commissions this work?
IT Directors, Heads of Infrastructure, CTOs and enterprise or solution architects — usually ahead of a funding decision, a resilience gap that has been flagged internally or by audit, or a migration that needs a documented target before anyone signs a contract.