One owner for the whole design
Each team can get its own part right and the joins can still fail. Someone has to hold the whole picture, and that is the job.
Design authority
Design authority, from first idea to handover
I act as technical design authority from discovery through to handover. This page shows how I run it: the gates a design passes, how I record and weigh decisions, how I would prove racks before they ship, and how changes reach production safely.
Overview
What a design authority is for
A design authority owns the technical design and decides what is approved. On my programmes it does three jobs: it makes decisions, it sets standards, and it checks that what gets built matches what was agreed.
Swipe sideways to see the whole diagram.
Decide. Needs, constraints and risks come in. Options are weighed in the open and one is chosen. What comes out is a high level design (HLD) and a short record of why it was chosen.
Set standards. A good answer is written down once, as a principle or a pattern. Every team then builds the same way, and nobody solves the same problem twice.
Assure. Teams bring evidence back: designs, test results and handover packs. Nothing goes live until the build matches what was approved.
Every choice has a written reason
A short record shows the options and why one won. A year later, nobody has to guess.
Most designs pass first time
Clear standards make that possible. The design authority then spends its time on the real exceptions.
Governance flow
Every design passes through gates
A design moves forward only when it passes a gate. Each gate has a clear question, an owner and a written outcome. If a gate says no, the design goes back with a list of what is needed.
Swipe sideways to see the whole diagram.
A need arrives: a new site, a refresh, a new service or a risk to fix. I start by writing the problem in one or two sentences, with who owns it and why it matters now.
I capture what the solution must do and what limits it: budget, dates, regulation, skills, contracts and the estate it must fit into. Constraints are written down early so nobody is surprised later.
I put two or three real options side by side, including doing the minimum. Each is scored against the same criteria, such as cost, risk, operability, lock in and time. The scorer further down shows how.
The chosen direction becomes a high level design (HLD). It shows the shape of the solution, how it meets each requirement, and which principles it follows or breaks.
The pack goes out a week ahead with a one page summary, and questions come in writing first. The outcome is approved, approved with conditions, approved with a dispensation, or not approved. Conditions have an owner and a date. A dispensation is logged with an expiry date. Not approved comes with a list of what is needed and goes back to the options.
The architecture decision record (ADR) drafted for the review moves from proposed to accepted. It holds the context, the options, the choice, its consequences and any conditions.
Engineers turn the HLD into a low level design (LLD): addresses, configuration, cabling and the test plan. I direct this work and check it still matches what was approved.
The build follows the LLD, in a factory where possible and on site where not. Anything that differs from the design goes back through the design authority first.
Tests prove the design works and fails safely: function, failover, performance, security and configuration checks. A failed test goes back to the build, is fixed and is run again.
Operations accept the service only when monitoring, runbooks, support contracts and spares are in place. This is the last gate. Then the work is closed and the lessons are recorded.
- Orange pill: a gate
- Red dashed line: work sent back
- Orange dot: the design moving on
How a design review runs
Read ahead
The pack goes out a week early with a one page summary on top. Questions come in writing first, so the meeting is spent on the real issues.
Same questions every time
Does it meet the requirements and the principles? What is the blast radius if part of it fails? Is it secure, can it be run, what does it cost, and can we reuse it?
A written outcome
Approved, approved with conditions that each have an owner and a date, approved with a dispensation, or not approved with what is needed. The decision log is updated the same day.
Exceptions and escalation
Dispensations and waivers
Sometimes a design cannot meet a standard. The team then asks for a dispensation that names the standard, the reason, the risk and any compensating control. The risk owner signs to accept the risk. Each dispensation has an expiry date and a plan to close it, and sits in a register that I check at every gate. A permanent waiver is rare and needs its own decision record.
The design authority and the ARB
A programme design authority decides within the standards agreed for the organisation. The enterprise architecture review board (ARB) owns those standards and looks across every programme. When a decision would change a standard, affect other programmes or carry more risk than the programme may accept, I take it to the ARB with the options and a recommendation. Most decisions never need to go that far.
Decisions
Decisions, with the reasons
Many arguments about a design are really about a decision nobody wrote down. I record each significant decision as an architecture decision record (ADR), and I score the options openly so everyone can see how the choice was made.
Swipe sideways to see the whole diagram.
A number, a short title that names the decision, and a status. Anyone can find it in the decision log and see at a glance whether it is still in force.
Why a decision is needed now: the forces, the constraints and the facts at the time. This is the part people skip, and the part they need most a year later.
The real options, including the obvious one, scored against criteria agreed before scoring starts. That order stops anyone choosing criteria to fit a favourite.
One clear choice in one or two sentences, with who decided and when.
What gets easier and what gets harder. A record that admits the cost of a choice earns more trust than one that only lists benefits.
A record moves from proposed to accepted. When things change, a new record supersedes it and the old one stays in the log, linked forward. Each record has a review trigger, such as a contract renewal.
Try it: weigh the options
This is an illustrative example, not a client decision. It opens with the weights behind the record above. Each option is scored from 1 to 5 on five criteria, where 5 is best. Move the weights to say what matters most and watch the ranking change.
How much each one matters
The scores behind it, from 1 (poor) to 5 (best)
| Criterion | A. One vendor in every pod | B. Two vendors inside every pod | C. A second vendor for whole pods |
|---|---|---|---|
| Cost to buy and run | 4 | 2 | 3 |
| Delivery risk | 4 | 2 | 4 |
| Operability | 5 | 2 | 3 |
| Lock in (5 means easiest to change supplier) | 1 | 5 | 4 |
| Time to the first pod | 5 | 2 | 3 |
The score starts the conversation. It does not end it. With equal weights, option A comes first. The record above chose C because the people accountable put lock in and delivery risk first, which is what the Regulated bank preset shows, and even then C wins narrowly. When two options are close, I take both to the design authority with the trade offs spelled out.
Lifecycle
Plan it as a repeating cycle
Infrastructure is never finished. I run it as a cycle, with the design authority and change control around every stage, so each refresh is routine rather than a crisis.
Swipe sideways to see the whole diagram.
Demand, capacity and the roadmap decide what comes next. I tie each item to a business need and a budget before any design starts.
High and low level design, reviewed at the gates above. Standard patterns come first. A new pattern needs a decision record.
Racks and pods are built and tested against the design before they ship, with automated checks. The factory model below shows how.
Changes go live in waves: a lab first, then low risk sites, then the rest. Each wave has a go or no go point and a tested way back.
Monitoring, runbooks and support are ready from day one. Drift from the standard is found, then fixed or formally accepted.
Hardware and software reach end of life on known dates. I plan refresh as a steady cycle, so the estate never needs one big risky upgrade.
Old kit and services are retired on a plan. Data is wiped to a recorded standard, contracts and records are closed, and the decision log is updated. Lessons from operations and retirement feed the next plan.
Factory model
Built and proven before it ships
I prestage and test network kit before it goes to site, as the photos on my home page show. For data centre pods I favour the same idea at rack scale: racks are built, cabled and burned in off site, checked by automated tests, then shipped whole and validated in place.
Swipe sideways to see the whole diagram.
Racks are built in a clean, staffed space: equipment fitted, cabled and labelled to the design, power connected and firmware brought to the agreed baseline.
The rack runs under load, typically for one to three days. Processors (CPUs), memory, storage and graphics processors (GPUs) are stressed and the rack is held at temperature. Weak parts fail here, where they are easy to swap.
Automated tests run the same way on every rack: every link at line rate with error counters checked, each power feed pulled in turn, and the configuration compared with the standard.
Results, serial numbers, firmware versions and the as built cabling are collected into one pack. The rack is signed off against the design before it leaves.
Whole racks travel to site, so they must be rated to ship fully loaded and packed exactly as built. Delivery is booked with the site team.
The rack is rolled into its position, powered from the real feeds and connected to the uplinks. Site work for each rack typically takes hours rather than weeks.
A short subset of tests runs again in the hall: power failover on the site feeds, uplinks and the data centre interconnect (DCI), shared services and monitoring. Then it is handed to operations.
Faults found early
Hardware is most likely to fail early in its life. Burn in finds those faults in the factory, before the rack reaches a live data hall.
Every pod the same
The same build, the same tests and the same evidence pack for every pod. A difference shows up as a failed test.
What to watch
Racks must be rated to ship fully loaded, and the factory tests must match production. A test pack that drifts from the real design proves nothing.
Proving a pod
Tests with pass marks, not opinions
A pod is ready only when it has passed the same tests, against the same pass marks, as every pod before it. I write the test pack alongside the design, run most of it in the factory and repeat a subset on site.
Swipe sideways to see the whole diagram.
Clocks are synced first, so every log lines up. Traffic generators and application probes run through the whole test, so each failure is measured, not guessed.
I power off one spine. Traffic from every leaf moves to the other spine. My indicative pass mark is under one second of loss and no application session dropped.
One leaf of a pair reloads. Dual homed servers carry on through the other leaf. The pass mark is that no host is isolated at any point.
The A feed is switched off. Every device carries on from the B feed. The pass mark is zero reboots, with the B feed under 80% of its rating.
One storage controller is failed. Paths move to the other controller. The pass mark is no input or output errors inside any virtual machine (VM).
One node of the three node controller cluster is stopped. The cluster keeps quorum, and the pass mark is that changes can still be made.
An uplink from a spine to the super spine is cut. Traffic leaves through the other plane. The pass mark is no loss of external reachability.
Finally the whole pod is powered off and on again. Every service must return within its target time, with no manual workarounds. Single failures come first, then any double failures the design claims to survive, then the cold start.
The seven areas of the test pack
| Area | What is tested | Factory | Site |
|---|---|---|---|
| Functional | Reachability in every routing instance (VRF), the anycast gateway, dynamic host configuration protocol (DHCP) relay, live migration of a virtual machine, storage multipathing and border routing. | Full | A subset |
| Failure injection | A spine, a leaf, the A feed, a storage controller, a controller node and a super spine uplink, one at a time, then a cold start. | Full | Power and uplinks |
| Performance baseline | Throughput and latency between racks, storage input and output operations per second (IOPS) and latency, GPU collective bandwidth, and VM migration times. | Full | Spot checks |
| Security | Vulnerability scans, Center for Internet Security (CIS) benchmarks, default baseboard management controller (BMC) passwords removed, unused services off, certificates valid. | Full | Scans repeated |
| Configuration compliance | A diff against the golden configuration, controller compliance reports and automated assertions. | Full | Full |
| Operational readiness | Alerts reach the right team, logs reach the security information and event management (SIEM) platform, the configuration management database (CMDB) is populated, backups run and a runbook is rehearsed. | Partly | Full |
| Automation | The pipeline rerun with no changes, and a leaf rebuilt from zero touch provisioning. | Full | Spot check |
Pass marks in the figure are indicative. Each programme agrees its own and writes them into the test pack before the first pod is built.
Each stage leaves evidence
| Stage | Done once, for the whole pod | Evidence it leaves |
|---|---|---|
| Design | One versioned HLD and LLD for each pod type. | The approved design and its decision records |
| Deploy | Built, cabled and burned in as a whole, shipped as racks, rolled in and joined to the super spine. | Build records, serial numbers and a firmware report |
| Test | Functional, failure and performance tests on the complete pod. | Test results against their pass marks |
| Operate | Monitoring, change windows, firmware waves and capacity, all tracked per pod. | Dashboards, change records and capacity reports |
| Retire | Drained, sanitised and removed together. | Sanitisation certificates and closed asset records |
A failed server is replaced like for like at the pod's baseline, from the same golden image and firmware, and never upgraded on its own. Upgrades happen to the whole pod, in a wave.
At the integration centre
I check its throughput per week and whether it has the power and cooling to burn in dense racks. AI racks may need liquid cooling even there. I also check test automation, access to the client's tools or an isolated copy, how evidence is captured, build area security, chain of custody, staff vetting and how any keys are handled.
Shipping and roll in
A loaded compute rack can weigh around 700 kg, and an AI rack around 1.36 tonnes (indicative). Racks must be rated for shipping loads, sit on shock absorbing pallets with tilt and shock indicators, and travel sealed and tracked. I survey the route from loading bay to rack position: doors, lifts, ramps and floor ratings.
Before power on
Racks acclimatise in the hall before power on, so condensation cannot form, and are unpacked outside the data hall. A tall rack on a pallet may not clear a door. Site tests repeat the link and power checks. Across borders, customs and local electrical standards add time.
The pod model
A pod is a unit of design and of risk
On a pod programme the word pod must mean one thing, its parameters must be decided by the right owners, and its risks managed from the start. I also map every pod to the important business services (IBS) it carries.
The programme pod
The unit of scale: a set of racks with its own fabric, power envelope and out of band network, built, run and retired as one.
The ACI pod
In Cisco Application Centric Infrastructure (ACI), one leaf and spine fabric under a shared cluster of Application Policy Infrastructure Controllers (APICs). Multi-Pod joins pods through an inter pod network. Putting many programme pods under one controller cluster widens the blast radius of a controller or policy fault.
The Kubernetes pod
One or more containers scheduled together on a node. It has nothing to do with racks but shares the name, so I define the term at the start of every design.
Defining the pod with the client
| Parameter | Typical starting point | Decided by |
|---|---|---|
| Physical shape | One contained aisle of racks | Data centre facilities |
| Power envelope | kW per rack and per pod, matched to a power and cooling block | Facilities, with the platform owner |
| Fabric | Leaf and spine with virtual extensible LAN (VXLAN) and Ethernet VPN (EVPN), with its own spines | Network owner |
| Out of band | Its own management network and console access | Network owner |
| Standard profile | Server and storage profile for each pod type | Platform owner |
| Interfaces | To the super spine and shared services, at standard boundaries | Design authority |
| Lifecycle | Built, tested, run and retired as one | Design authority, with operations |
Each parameter becomes a row in the open decision matrix. I prove one type first, usually general compute, and avoid choosing server models or the AI fabric before they are needed. Pod types and their physical differences are on the data centre networks page.
Which services does each pod carry?
Swipe sideways to see the whole diagram.
One pod lost. Pod A1 fails. Payments carries on in pod B1 and the portal in pod A2, so every service stays within its impact tolerance. That is the result I want for any single pod.
A hall lost. Hall A fails and takes pods A1 and A2 with it. The portal had both copies in hall A, so it breaches its tolerance. The fix belongs in the placement policy: spread each important service across halls and sites.
Shared services lost. If the domain name system (DNS) or identity fails, every service is hit at once. That is why they get the highest resilience tier: several sites, anycast and their own scenario tests.
Top down, I trace each important business service to its processes, applications, platforms, pods and shared services, then to the hall, power, cooling and third parties. Bottom up, every component is registered with its pod, hall, site and vendors. Together they show which services are hit if a pod, a hall or a vendor fails.
Workload placement policy
| Workload | Where it may run | How it is enforced |
|---|---|---|
| Card data | Dedicated pods for the cardholder data environment, in two sites, with named flows only | Tags, placement rules and firewall policy |
| Restricted data | Production only, on dedicated clusters, with keys in the client's hardware security modules (HSMs) | The catalogue offers only valid targets |
| Important business services | Spread across pods, halls and sites, active and active or active and standby to match the tolerance | Placement rules and anti affinity |
| Non production | Masked data only, never on card data hosts | Separate pods and tags |
| AI training | Through an approved pipeline with data lineage, on an isolated back end fabric | Dedicated pods |
| Backups | The backup zone, plus an immutable vault copy | Separate identity and network |
| Internet facing | The demilitarised zone (DMZ) only | Firewall zones |
Written with data owners, cyber and the platform teams, and enforced in the platform itself: vCenter tags and placement rules, OpenShift node selectors and taints, admission policies, and a self service catalogue that offers only valid targets.
Risks of a pod model
| Risk | What it looks like | How I manage it |
|---|---|---|
| Stranded capacity | Space but no power left, or power but no ports | Size on measured power, align pods to power blocks, track it in data centre infrastructure management (DCIM) |
| Fragmentation | Every team asks for its own variant | Catalogue governance, exceptions that expire, and the number of variants as a measure |
| Over standardising | A pod type that suits nobody well | A demand led review, and a clear path to propose a new type |
| Shared service concentration | Every pod depends on the same DNS and identity | Anycast, local instances and strict change control |
| A refresh all at once | Every pod reaches end of life together | Stagger deployments and refresh dates |
The one I watch hardest is stranded power, because AI demand arrives in large, uneven steps. The capacity triggers and cost maths are on the resilience, risk and cost page.
Change and risk
Changes that are safe to approve
A good design can still fail on the night. I write every significant change so a change advisory board (CAB) can approve it with confidence, and so the engineer doing the work has a clear way back.
Swipe sideways to see the whole diagram.
Goes to plan. Pre checks record the starting state. Every step is followed by a check. At the final gate the results match the plan, so the change is closed and the records are updated.
Stopped early. If a pre check fails, for example a backup link is already down, the change does not start. Nothing has been touched, so it is simply rebooked. Stopping early is a good outcome.
Backed out. A check fails after a step. The plan says how long we may spend fixing it before we must decide. Then we back out to the recorded starting state. The back out was tested beforehand, so using it is routine.
What goes in a change
- Summary. What changes and why, starting with the business outcome, in plain words.
- Scope. The exact devices, sites and services touched, and what is left alone.
- Risk. Likelihood and impact, the blast radius if it goes wrong, and how that is limited.
- Pre checks. The state before work starts, recorded so it can be compared afterwards.
- Steps. Numbered steps, each followed by a check, with a named person doing each one.
- Validation. How we prove it worked: tests, monitoring and a user check where it matters.
- Back out. A tested way back, and the time by which we must decide to use it.
- Communications. Who is told before, during and after, including the service desk.
Operational resilience
Financial regulators now expect firms to show they can keep important services running through disruption, not only recover afterwards.
In the EU, the Digital Operational Resilience Act (DORA) has applied to financial firms since 17 January 2025. It covers risk management for information and communication technology (ICT), incident reporting, resilience testing and the risk from third party suppliers.
In the UK, the Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) operational resilience rules ask firms to identify their important business services, set impact tolerances for them, then map and test them. Firms had to be able to stay within those tolerances by 31 March 2025.
I treat these as design inputs. Every design and every change should leave evidence behind: an accurate inventory, tested recovery, change records and a clear view of suppliers.
Sources: Regulation (EU) 2022/2554 (DORA); FCA PS21/3 and PRA SS1/21 on operational resilience.
Principles
The rules I design by
These are the principles I bring to a design authority. Each one turns into a question I ask at review.
- Write the problem first. If the need cannot be stated in two sentences, it is too early to design.
- Standard first. Use an agreed pattern unless there is a recorded reason not to.
- Decide in the open. Options, criteria and scores are shared before the meeting, not during it.
- Write down the reason. Every significant decision gets a short decision record.
- Design for failure. Know the blast radius of every part, and test failover before go live.
- Design for operations. If the support team cannot run it at 3am, it is not finished.
- Evidence over opinion. Approval rests on test results and data, not on confidence.
- No change without a way back. Every change has a tested back out plan.
- Light touch. Most designs should pass first time. Review time is for the real exceptions.
- Principles must be testable. If a principle cannot be checked at review, it is a slogan.
How a principle becomes a review question
| Principle | Question at review | Evidence I ask for | Result |
|---|---|---|---|
| Design for failure | What happens when this part fails? | Failure domain map and a failover test | Met |
| Design for operations | Can the support team run it? | Runbooks, monitoring and trained staff | Partly met runbooks due before go live |
| Standard first | Does it follow an agreed pattern? | The pattern reference, or a decision record | Met |
| No change without a way back | How do we undo it? | A back out plan that has been tested | Not met test it first |
When two principles pull in different directions, such as cost against resilience, I rank them up front or take the conflict to the design authority. Quietly picking a winner is how standards drift.
Governance mechanics
Who decides, with what, and when
Good governance is mostly plain mechanics: one accountable owner per decision, a clear set of documents, a few gates with written entry criteria, and a common language for what is a rule and what is advice.
Swipe sideways to see the whole diagram.
Fabric control plane. I am responsible for the option paper, the network owner is accountable and decides, cyber and the platform teams are consulted, and finance is informed. One accountable person per decision, always.
A security exception. Cyber security is accountable and often holds a veto. I write the exception with its compensating controls and expiry date, and the network and platform owners are consulted.
The rack power envelope. Data centre facilities own power, cooling and space, so they are accountable. The platform and network teams are consulted because they set the load.
Spend over budget. Finance is accountable for money. I bring the options and the cost of each, and the platform and facilities owners are consulted.
A version inside a platform. Decisions inside a platform belong to its owner. A specialist does the analysis and I am consulted for fit. Anything that crosses domains goes up to the architecture review board.
Principles, standards, guidelines and patterns
| Term | What it is | Example |
|---|---|---|
| Principle | An enduring rule, with its reason. | Keep layer 2 inside the pod, because the pod is the failure domain. |
| Standard | Mandatory, specific and testable. | All new pod fabrics use Ethernet VPN (EVPN) over Border Gateway Protocol (BGP), to RFC 7432 and RFC 8365. |
| Guideline | Recommended practice. Teams may depart from it without an exception. | Prefer eBGP for the underlay. |
| Pattern | A reusable, approved solution to a common problem. | The standard branch site, or the standard VM pod. |
Too many standards and nobody reads them. A principle that cannot be tested at review is a slogan.
High level and low level design
| High level design (HLD) | Low level design (LLD) | |
|---|---|---|
| Purpose | What we will build and why, and how it meets the requirements | Exactly how to build it |
| Audience | Sponsors, architects, security, operations | Engineers, the integration partner, automation |
| Contents | Context, requirements, options, logical design, failure domains, zones, risks, decisions | Ports, addresses, virtual LANs (VLANs), overlay segment IDs (VNIs), routing instances (VRFs), autonomous system numbers (ASNs), configurations, cable and power schedules, test cases |
| Written by | The design authority lead | Specialists, reviewed against the HLD |
| Approved at | Design approval | LLD approval, before the bill of materials is frozen |
Gates I use for a pod type
| Gate | Decision | Entry evidence |
|---|---|---|
| G0 | Demand accepted | A pod type, size and placement agreed, with a business owner and a forecast. |
| G1 | Design approved | Signed HLD and LLD, decision records, principles compliance matrix, test plan, bill of materials. |
| G2 | Factory acceptance | Built from templates, burn in and failure tests passed, vulnerabilities closed, evidence pack signed. |
| G3 | Operational acceptance | Site acceptance passed, monitoring complete, runbooks and support model handed over. |
| G4 | Exit approved | Workloads drained, media sanitised with certificates, records closed, space and power returned. |
A pod cannot move past a gate until it passes, or until a time bound exception is recorded with an owner.
The document set for every pod type
| Artefact | Purpose | Produced by | Gate |
|---|---|---|---|
| Pod type definition | What the pod is for, its sizes, limits and shared service needs, on one page | Design authority lead | G0 |
| Reference architecture (HLD) | Logical design, failure domains, zones and resilience | Design authority lead | G1 |
| Decision records | Key decisions, the options and the reasons | Design authority lead with specialists | Ongoing |
| Principles compliance matrix | Each principle, its evidence, met or not | Design authority lead | Every gate |
| Rack elevations and floor template | Physical build, power envelope, weight and cooling type | Facilities specialist | G1 |
| Network LLD and data | Ports, addresses, VLANs, VNIs, VRFs and ASNs for automation | Network specialist | G1 |
| Zone mapping and data flows | The segmentation model and the Payment Card Industry Data Security Standard (PCI DSS) scope | Design authority lead with cyber | G1 |
| Bill of materials | Primary and qualified alternative parts, with lead times | Commercial specialist | G1 |
| Templates and source of truth data | Inputs for infrastructure as code | Automation engineers | G2 |
| Test pack | Factory, burn in, integration and failover tests | Design authority lead with the test lead | G2 |
| Runbooks and acceptance criteria | The day 2 handover | Platform owner | G3 |
| Evidence pack template | Regulatory evidence produced for every pod | Design authority lead with risk and compliance | Every gate |
| Unit cost and capacity model | Cost per unit and the trigger for the next pod | Design authority lead with finance | G1 |
| Lifecycle plan | Firmware cadence, refresh and retirement | Platform owner | G1 |
From regulation to evidence
| Obligation | Control in the design | Evidence I keep |
|---|---|---|
| DORA: information and communication technology (ICT) risk management | Asset inventory in the configuration management database (CMDB), resilience patterns, failure domains mapped | Risk register, CMDB records, failover test results |
| DORA: incident reporting | Monitoring, classification and timelines built into operations | Incident records with timestamps |
| DORA: resilience testing | Scenario tests, including threat led testing for the firms in scope | Test plans, results and fixes |
| DORA: third party risk | A register of ICT providers, exit plans, contract terms | Register of information, contracts, exit tests |
| FCA and PRA operational resilience | Important business services mapped to pods and halls, with impact tolerances | The mapping, and scenario tests within tolerance |
| PCI DSS v4.0.1 | Card data in its own zone, with firewalls at every boundary | Firewall rules and segmentation tests, yearly or every six months for service providers |
| Markets in Financial Instruments Directive (MiFID II) clock rules | Time traceable to Coordinated Universal Time (UTC), using Precision Time Protocol (PTP) where needed | Clock divergence logs within the allowed limit |
| ISO/IEC 27001 | Annex A controls built into the patterns | Statement of applicability and audit records |
The detail behind these obligations, and the availability and cost maths, is on the resilience, risk and cost page.
TOGAF, in brief
The Open Group Architecture Framework (TOGAF) is a widely used method for enterprise architecture. Its architecture development method (ADM) is a cycle of phases with requirements management at the centre.
Swipe sideways to see the whole diagram.
The preliminary phase sets up the architecture practice, its principles and its governance. Phase A agrees the scope, the stakeholders and a vision of the target, which is approved before the detail starts.
Phases B, C and D describe the current and target business, information systems and technology architectures, and the gaps between them. For infrastructure work, phase D is where most of my effort goes.
Phase E groups the gaps into projects and options. Phase F turns them into a costed, sequenced migration plan with transition architectures along the way.
Phase G is the design authority's home: compliance reviews of what is being built, dispensations where it must differ, and sign off.
Phase H watches for changes in business need or technology that should start the cycle again. Requirements management sits in the centre throughout, feeding every phase.
I use TOGAF as a vocabulary, not a ritual. Architecture building blocks describe what is needed, solution building blocks describe what is bought or built, and the repository keeps them all in one place.
Reviewing designs
How I check a specialist's design
Specialists own the depth. I own the fit: that the design traces to the principles, carries the numbers, can be tested and can be run. These are the checks I use, and how I keep the build honest afterwards.
| Area | What I check in a fabric LLD |
|---|---|
| Traceability | Every choice traces to a principle, a requirement or a decision record. |
| Capacity | Oversubscription per leaf role, behaviour with one spine down, growth and the spine port budget. |
| Routing | The underlay choice justified, the ASN plan, multipath, and bidirectional forwarding detection (BFD) as a standard. |
| Addressing | Loopbacks, point to point links, alignment with IP address management (IPAM), and summarisation at the pod edge. |
| Overlay | One numbering scheme for VLANs, VNIs and VRFs, the route target scheme, replication mode, anycast gateway and address resolution protocol (ARP) suppression the same everywhere. |
| Scale | Checked against the vendor's verified scalability guide, with route reflectors sized and redundant. |
| Security | Zones, firewall placement, management access and logging. |
| Operations and test | A test for every failure, mobility and border case, plus monitoring and runbooks. |
Keeping the build true to the design
Swipe sideways to see the whole diagram.
The approved LLD is not a document that sits on a shelf. Its data goes into the source of truth, such as NetBox, and the build is generated from it, so the documents and the network cannot drift apart.
Configuration is generated from templates and checked before it is pushed, for example with Batfish to model the routing and policy and prove the change does what the design says.
The change goes through change control, then automated checks, for example with pyATS, prove the network now matches the intent.
A weekly report compares what is running with what was approved. Drift is either fixed or accepted with a recorded reason.
A change made by hand in an emergency is allowed, but it is written back into the source of truth within an agreed number of days, or the next build would undo it.
Review playbook
| Situation | What I do |
|---|---|
| The LLD contradicts the signed HLD | Find out why. If the LLD found something the HLD missed, the HLD changes through the proper route with an updated decision record. If it drifted for convenience, I name the principle it breaks and ask for a compliant version. The record must end consistent. |
| The design is not ready, but the build slot is | Split the decision. The critical path parts, such as the rack power envelope and the fabric uplinks, go for approval with conditions. I warn the chair early and ask the accountable owner for an out of cycle decision, rather than push an incomplete design. |
| Engineers disagree with the design | Separate fact from preference: an operational problem, a skills gap, a tooling limit or a different taste. Test the point against the principles, settle it with a proof of concept or a failure test, and record both views. |
| A local team wants to deviate to hit a date | Find the real reason, such as lead times or a quirk of the site. Hold the non negotiables, such as resilience and segmentation, then fast track an exception with an expiry or offer a compliant alternative that meets the date. |
| Reviews start to feel like a tollbooth | Make the approved path the fastest: a light check for designs that follow a pattern, a full review for new patterns and exceptions, published turnaround times, open office hours and automated checks. |
| A decision needs explaining | Three layers: the decision in a sentence or two, the design view with the trade off and the number that matters, then the authority view: the risk, who signed it off and how anyone can check it. |
Vendor and technology choice
Choosing vendors on evidence
A design authority makes dozens of open decisions on a programme. I keep them visible in one decision matrix, decide each at its last responsible moment, and choose vendors through tests anyone can repeat.
| ID | Open decision | Options | Owner | Needed by |
|---|---|---|---|---|
| D01 | Fabric control plane | Cisco Application Centric Infrastructure (ACI), or NX-OS with virtual extensible LAN (VXLAN) EVPN | Network owner | Before the network LLD starts |
| D02 | Super spine speed | 400G now, with plant ready for 800G on single mode | Network owner | Bill of materials freeze |
| D03 | VM pod storage protocol | Non volatile memory express (NVMe) over TCP, or Fibre Channel | Platform owner | Start of the storage LLD, after a proof of concept |
| D04 | Graphics processing unit (GPU) pod cooling | Rear door heat exchangers, or direct liquid cooling | Facilities | Hall design freeze |
| D05 | Firmware cadence | Quarterly, or every six months | Platform owner | Before the first pod goes live |
An illustrative extract. The real matrix also records why each decision matters, the recommendation, who is consulted, what it unblocks, its status and a link to its decision record. I review it weekly and escalate anything near its date with a one page paper.
A fair proof of concept
Swipe sideways to see the whole diagram.
The plan, the criteria, the weights and the pass marks are agreed and written down before any vendor starts. Changing them afterwards needs the same approval as the decision itself.
Like for like hardware class, scale and time box for every vendor. Vendors may help build the environment, but they run on the same terms.
Our own engineers run the tests and keep the raw results: failure under load, an upgrade during traffic, and day 2 tasks such as adding a tenant or replacing a failed part. Vendors can fact check results, but cannot re run tests until everyone can.
Client engineers and architects score together, with the evidence attached to every score. Where I work for a partner with a commercial interest, I declare it and keep scorers separate from sellers.
The accountable owner decides, and the decision record keeps the options, scores and reasons, so the choice can be defended months later.
Two vendors, chosen carefully
Across pods, a second vendor reduces lock in and keeps pricing honest. Inside a pod, mixing vendors multiplies the test matrix and blurs support, so each pod type has one tested bill of materials with a qualified alternative. Pods meet at standard interfaces such as eBGP, BGP EVPN and Multi-Site gateways.
The same chips inside
Merchant silicon, such as Broadcom's Tomahawk and Jericho families, sits inside switches from many vendors. A "second vendor" can therefore share the same chip and the same defects, so I check what is really different before I count it as diversity.
Lead times shape the design
GPUs, high speed optics, some switches and electrical plant have long lead times. I keep two qualified part numbers for key components, especially optics, hold a factory buffer of long lead items against the pod forecast, and watch end of sale and end of support dates.
Suppliers and technical debt
Holding partners to the standard
Most of my programmes involve carriers, managed service providers, vendors and integrators. I make the architecture part of the contract, govern the joins between them, and keep a visible record of the debt every shortcut creates.
Swipe sideways to see the whole diagram.
The seams. With several delivery partners, the failures happen at the joins. I own the end to end target and the integration contracts centrally: crisp interfaces, responsibilities and failure modes for every boundary, reviewed in one cross supplier design forum.
A managed service design that does not meet the standard. I review it against the standard, not my taste, and say exactly where it diverges and why it matters. Often there is a constraint I did not know. I hold the non negotiables: segmentation, resilience and auditable change. Recurring gaps are fixed at source, in the standard or the templates.
Influencing a roadmap I do not control. I write needs as outcomes the supplier can sell to others, such as supportability, security by design and regulatory fit, and feed them in early. I use renewal dates to get them heard. If the roadmap cannot meet a need, I mitigate, substitute or escalate it as a conscious architecture decision.
Architecture in the contract
Design acceptance criteria and obligations go into the contract, along with transparency: asset registers, configuration baselines, visibility of changes and the design documents themselves. Gates need evidence at each milestone, and obsolescence and debt commitments are written in.
Learning flows back
Incident and problem reviews feed a backlog of pattern and standard changes. Recurring pain becomes a change to the target architecture or a new pattern, and supplier root causes become contract or design obligations.
Supplier concentration
Relying on one supplier for too much is an architecture risk as well as a commercial one. I record concentration and exit risk in the design, and prove the exit plan for anything that supports an important business service.
The technical debt register
| Item | Interest it charges | Owner | Plan | Review |
|---|---|---|---|---|
| Two core switches past end of support | No security fixes, slower repairs | Network owner | Replace in the Q3 refresh wave | Monthly |
| Firewall rules with no owner | Audit findings, unknown exposure | Security team | Hit count analysis, then remove | Quarterly |
| A stretched VLAN between halls | One shared failure domain | Design authority | Remove after the application moves | Each wave |
Illustrative entries. Every time boxed exception lands here with its expiry, so a shortcut cannot quietly become permanent.
End of life equipment is the most common entry. I find it from the devices themselves, not from old spreadsheets: show inventory and show version give each part's product ID and software, show cdp neighbors detail shows what connects to what, and the configuration backups show what each device does. I match every product ID against the vendor's end of sale and last date of support notices, which gives a list ranked by risk and date. The replacement then follows the factory and change methods above.
- Make the trade off explicit. A shortcut is allowed when its cost is written down, with an owner and a date to fix it.
- Accept risk at the right level. The person who carries the consequence signs the exception, not the person in a hurry.
- Measure maturity. Designs passing review first time, the number and age of open exceptions, and drift found in the weekly report.
- Pay it down in waves. Debt is fixed as part of the refresh plan, not in a separate project that never starts.
Engagement
How I run a design authority, from mandate to exit
A design authority is a service to delivery teams, not a gate they have to get past. I set it up the same way on every programme: agree the mandate, trace requirements, know the current estate, approve designs against patterns, check the build against the design, and keep the standards alive after handover.
Swipe sideways to see the whole diagram.
I start by agreeing what the design authority is for: which decisions it owns, who sits on it, what quorum it needs and how a decision is escalated. Without a written mandate, a design authority becomes a meeting where people present slides and nothing is decided.
I make sure every requirement has an identifier, an owner and a way to prove it. Functional requirements say what the solution does. Non functional requirements give numbers for availability, recovery, performance, security and operability. Each one is traced through the design to a test or a piece of evidence.
I collect the current designs, standards, contracts and incident history, then compare them with what is really deployed. Gaps between documents and reality become risks or technical debt. Decisions that nobody has taken yet go into an open decision log with an owner and a date.
Specialists write the detailed designs. I check they follow the agreed principles and patterns, that each choice is recorded as a decision with options and reasons, and that any exception has an owner and an expiry date. Gate G1 approves the design before anything is ordered.
During build I check what is deployed against the approved design, using generated configuration, automated checks and test evidence rather than slides. Factory acceptance closes gate G2. Operational acceptance at gate G3 needs runbooks, monitoring and trained staff in place, not just a working network.
At handover, the service owner signs operational acceptance and the design authority's standards stay published and current. I agree how suppliers and managed service providers are assured against them, and every incident review or lesson that changes a pattern comes back through the design authority.
Standards age. I review them on a cycle, track technical debt with an owner and a date to pay it down, compare vendor roadmaps with our own, and plan exits before contracts renew. Gate G4 approves retiring a platform, with data, licences and equipment all accounted for.
Functional requirements
What the design authority itself must do.
- Approve high and low level designs against the agreed principles and patterns.
- Record every significant decision with its options, reasons, owner and date.
- Grant time limited exceptions, each with a risk owner and an expiry date.
- Run gates G0 to G4 with clear entry and exit criteria.
- Keep standards, patterns and approved products published in one place.
- Assure suppliers and managed service providers against the same standards.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Timeliness
- A design review within an agreed time, for example ten working days, with a fast track for urgent changes.
- Traceability
- Every requirement traced to a design element and to a test or piece of evidence.
- Transparency
- Decisions, minutes and exceptions visible to every delivery team.
- Independence
- Reviewers do not approve their own work, and conflicts are declared.
- Quorum
- Named members for each domain, with deputies, so reviews are not cancelled.
- Evidence
- Approvals based on test results, configuration checks and records, not slides.
- Proportion
- Small changes follow a standard pattern. Only new or risky designs need a full review.
These are typical starting targets. Each organisation agrees its own, and writes them into the design authority's terms of reference.
Who I talk to
- Programme sponsor and steering group
- Enterprise and domain architects
- Security, risk and compliance
- Operations, service and support teams
- Procurement, vendors and managed service providers
How I find out
- Review of current designs, standards and decision records
- Comparison of documents with deployed configuration
- Workshops with each domain team and supplier
- Review of incident and problem history
- Review of contracts, support terms and end of life dates
Discovery tools
| Tool or source | What it tells me |
|---|---|
| Architecture repository | Current designs, patterns, standards and decision records in one place. |
| NetBox or a configuration management database (CMDB) | What is meant to be deployed, as structured data. |
| Configuration backups and Batfish | What is really deployed, and whether it matches the intent. |
| Incident and problem records | Where designs have failed in practice, and how often. |
| Vendor end of life notices | Which platforms must be replaced, and by when. |
| Contracts and service level reports | What suppliers are obliged to do, and whether they do it. |
When something fails in production, I want to know whether the requirement, the design, the build or the operation was at fault, because each needs a different fix.
My approach
- Define. What failed, what was affected, and which requirement or service level was missed?
- Contain. Support the incident team first. Governance never delays restoring service.
- Compare. Check the deployed configuration and process against the approved design.
- Classify. Requirement gap, design flaw, build deviation, operational error or supplier failure.
- Fix. Through change, with a decision record if the design itself must change.
- Learn. Update the pattern, the review checklist or the debt register, so it does not recur.
Faults I see most
- A deployed configuration that has drifted from the approved design
- An exception that outlived its expiry date
- A single point of failure missed at review
- Two teams applying different versions of a standard
- A supplier change made outside the change process
- An end of life platform still carrying critical services
Layer by layer
| Layer | What I check |
|---|---|
| Requirement | Was the need written down, with a number we could test? |
| Design | Did the approved design meet it, and was the failure case reviewed? |
| Build | Does the deployed configuration match the approved design? |
| Operation | Were runbooks, monitoring and alarms in place, and were they followed? |
| Supplier | Did the partner meet the standard and the contract? |
| Governance | Was a decision or an exception missing, late or ignored? |
My general fault finding method, with worked faults, is on the troubleshooting page.
I agree how the design authority supports delivery and operations teams before the first review, so nobody sees it as a hurdle at the end.
Service model
Published review slots, a named contact per domain and a fast track for urgent changes.
Templates
HLD, LLD, decision record and exception templates, so every design arrives in the same shape.
Patterns
Approved patterns that teams can use without a full review.
Clinics
Short sessions where teams bring a draft design early, before it is too late to change.
Supplier assurance
Regular reviews of partners and managed service providers against standards and service levels.
Reporting
Open decisions, exceptions, debt and gate status reported to the steering group.
Standards, decisions and platforms all age. I plan their review and retirement from the start.
- Standards. Each standard reviewed on a cycle, at least yearly, and when a vendor or regulation changes.
- Decisions. Decision records revisited when their assumptions change, not left to go stale.
- Exceptions. Expiry dates enforced, with each exception closed, renewed with reasons or turned into debt.
- Technical debt. A register with owners, impact and a date to pay down, reviewed with the budget cycle.
- Vendors. Roadmaps and end of life dates compared with ours, and exits planned before renewal.
- Exit. Gate G4 approves retirement, with data, licences, contracts and equipment closed out.
Projects
Where I have done this work
I have acted as technical design authority in industrial software, telecoms and consulting, from discovery through to operational handover. In banking, I delivered a network refresh under strict change governance.
Design authority for a global transformation
I set the design authority standards adopted by every regional delivery team. I led 7 engineers and architects, coordinated 5 vendors through a phased, site by site roadmap, and kept over £200M of transactional services at 99.99% uptime through data centre transitions.
Lead technical design authority
I am lead technical design authority and lead architect for clients including Dyson and Virgin Media O2. I lead network and security transformation from discovery to provisioning across Cisco, AWS, Azure and Google Cloud.
Senior network architect and design authority
I was lead architect on network, cloud and data centre programmes from discovery to operational handover, for clients including Weetabix, Dyson and Network Rail. I planned and ran remote site migrations across regulated environments with no critical incidents.
High level designs on TM Forum frameworks
I produced high level designs across the radio access network (RAN), core, transport and the operations and business support systems (OSS and BSS), and fed the architecture into the autonomous network and service orchestration roadmap.
Technical design authority
I led discovery, due diligence and architecture for network automation aligned to TM Forum and MEF standards, and shaped software defined wide area network (SD-WAN), SD-Access and Catalyst Center planning.
Architecture and delivery lead
Across three engagements I worked on cloud, software defined networking (SDN), disaster recovery and security architecture. In 2019 I directed architecture and delivery across AWS, Google Cloud, Azure, Catalyst SD-WAN and SD-Access, and led and mentored a team of 4 engineers.
Change governance in a bank
I delivered the Europe, Middle East and Africa (EMEA) network refresh, from audit through high and low level design to implementation. The estate stayed compliant with the Markets in Financial Instruments Directive (MiFID II) with no service outages, and I advised on change governance and architecture standards.
Backed by PRINCE2 Practitioner and ITIL, and by high and low level design work for enterprise customers since my time at BT in 2013. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.