Most High-Level Designs are not born from a blank sheet of paper. They are the product of a templated design — an architecture refined through repeated delivery, adapted for a new client.
Done well, this is efficient and effective. Done without scrutiny, the template becomes a substitute for thinking. The integrator takes a design from a previous engagement, swaps out the client name, updates the logo on the cover page, and presents it as a bespoke solution built around your business needs. The template stops being a starting point and becomes the answer — regardless of whether it fits the question.
I have reviewed HLDs from different organisations, different sectors, different programme sizes, where the architecture, the vendor stack and the diagram topology were functionally identical. The only thing that had changed was the client name. After 21 years of independent design review, I have stopped being surprised by this. I have started asking why it keeps happening.
The integrator's business model is not your enemy — but it is not your friend either
Integrators provide genuine value — in scale, in implementation capacity, in programme delivery. None of what follows is a criticism of what they do well. But we should be honest about how the economics work.
A high-volume delivery business makes money through repeatability. If an integrator can sell you a standard architecture that their engineers have deployed twenty times before, they eliminate training cost, reduce technical risk, and protect their margin. The more standardised the solution, the more profitable the engagement.
Your specific requirements — your legacy integrations, your regulatory constraints, your growth plans for the next 18 months — are not assets in this model. They are variables that increase complexity and cost. The temptation, conscious or not, is to treat them as edge cases to be accommodated rather than requirements to be solved.
When an integrator reviews their own design, they are not asking whether this is the most valuable solution for your business. They are asking whether this is the most deliverable solution for their team. Those are different questions and they rarely produce the same answer.
What this looks like in practice: Cisco ACI
Cisco ACI is a capable data centre fabric platform. In the right environment — large-scale, complex, with the operational maturity and team depth to justify it — it earns its place. This is not an article about whether Cisco ACI or Cisco VXLAN-based fabric is the better choice. It is an article about when ACI gets recommended regardless of whether it is the right choice.
If you are an enterprise refreshing your existing data centre network or deploying a greenfield environment, and you have selected Cisco as your vendor for sound commercial reasons, you actually have two choices today. You can deploy Cisco ACI — the proprietary, controller-driven fabric. Or you can deploy a Cisco VXLAN-based fabric using Nexus Dashboard Fabric Controller or a third-party controller — an open-standards approach that leverages the same underlying hardware with significantly less proprietary dependency.
In my experience, you will almost always be recommended ACI.
The reasons are not hard to find. ACI generates substantially more margin for both the vendor and the integrator. The licensing model is more complex and more lucrative. ACI requires dedicated APIC controllers — hardware you would not need in a VXLAN fabric deployment. Telemetry and visibility at any meaningful level pushes you toward Nexus Dashboard hardware as well — optional in theory, strongly recommended in practice, and another line on the bill of materials. Beyond the initial deployment, ACI's complexity creates ongoing consultancy dependency. Changes, upgrades, troubleshooting — these regularly require specialist engagement that a well-designed VXLAN fabric simply does not.
And then there is the most practical reason of all: the integrator already has the HLD, the LLD and the runbooks. They have deployed this design before. Their engineers know it. The find and replace operation I described at the start of this article is not a metaphor — it is a workflow.
What is almost never considered in these recommendations: your actual business requirements, your team's capability to operate and maintain what is being deployed, or Cisco's own product direction — which has shifted meaningfully toward VXLAN fabric investment over recent years. The roadmap tells you where the engineering energy is going. It is worth reading before you commit to a platform for the next decade.
Ask yourself: whose problem does ACI actually solve here?
Why this keeps happening
The integrator recommending ACI in an environment that does not need it is not necessarily acting in bad faith. They are almost certainly recommending what their engineers are trained to deploy, what their vendor relationship incentivises them to sell, and what reduces their own delivery risk.
That is precisely the problem.
A solution sized for enterprise scale, recommended to an environment that does not need it, deployed by a team whose commercial interests align with the vendor — this is not an edge case. It is a predictable outcome of a procurement process that lacks independent technical scrutiny at the design stage.
What you need is someone to read your requirements honestly, assess what your infrastructure actually demands, and recommend accordingly. That is not what a delivery partner is positioned to provide. Their incentive is to deliver. An independent reviewer's incentive is to be right.
The doctor analogy
If a doctor received a commission from a pharmaceutical company for every prescription they wrote for a specific brand of medication, you would not just take the pill. You would seek a second opinion. Infrastructure architecture is no different.
When the organisation recommending your solution also profits from delivering it, and when delivery is easier with a familiar standard design than a bespoke one, you have a structural conflict of interest. It does not mean the recommendation is wrong. It means you should not accept it without independent scrutiny.
What independent design review actually does
A design assurance review does not make the integrator's life harder. Done correctly, it makes the programme better — because it moves the conversation away from what is comfortable for the delivery team and back toward what is right for the business.
It forces the integrator to justify vendor and product selection on technical and commercial merit. To explain how this specific design addresses your specific requirements — not how it has worked in broadly similar situations for other clients.
Before you sign off on any HLD, ask one question:
Was this design built around my requirements — or around their convenience?
If your integrator cannot answer that with specifics, you already have your answer.
- Were you shown the full range of options? If your integrator presented one solution without comparing it against alternatives — including lower-complexity, lower-cost approaches using the same vendor — that is not a design recommendation. It is a product placement.
- Does the solution match the scale of your actual requirement? Enterprise-grade platforms exist for enterprise-grade problems. If your environment does not have those problems, you should not be paying to solve them.
- Was your team's ability to operate this considered? A design your internal team cannot maintain without ongoing specialist support is not a solution — it is a dependency. Understand what you are signing up for before you sign.
- Did anyone read the vendor's roadmap? Product direction is public information. If a vendor's own investment has shifted away from the platform being recommended, that is a material fact in your procurement decision.
- Who reviewed this design independently? The delivery partner reviewing their own recommendation is not independent review. The only scrutiny that counts is scrutiny with no commercial interest in the outcome.