Why the distinction is worth money
An organisation that misreads an architecture failure as a product limitation replaces the product, inherits the same failure on the new one, and has spent a year and a budget to arrive back where it started. One that misreads a product limitation as an architecture failure redesigns around a defect the would have fixed, and carries the complexity for the life of the design. Both mistakes are common, both are expensive, and both are made for the same reason: the first explanation that arrives is the one with a name attached, and the product always has a name.
Three categories, not two
The honest taxonomy has three cases, and the middle one is where most disputes live.
A product limitation. The product cannot do what was asked under any configuration: a documented maximum, a feature that does not exist, a defect that reproduces on a clean system. Evidence: the vendor's documentation says so, or the behaviour reproduces outside your environment.
An architecture failure. The design asked the product to do something it was never specified to do, placed it where its assumptions do not hold, or combined it with something whose behaviour conflicts with its own. The product is working as documented; the design is wrong. Evidence: the product behaves as its documentation says it will, and the documentation was available when the design was made.
A configuration or operational gap. The product can do it, the design is sound, and the specific instance was configured, sized or operated outside the envelope. Evidence: a second instance, configured as documented, does not fail.
The Practice article not a bug explains why "working as designed" is almost always true and almost never the end of the question. The question is whose design.
The method: remove your network from the argument
The vendor will say it is the architecture. The architect will say it is the product. Both are interested parties, and the way to settle it is the same discipline the Practice describes for proving the vendor wrong: build evidence that survives a sceptical reader who was not there.
- State the behaviour as an observation, with the evidence attached: the capture, the log, the counter, the timestamp. Not "the firewall drops traffic under load"; "at 09:14, with N sessions and M new sessions per second, the device logged X and the capture shows Y". The escalation article sets out the form.
- Find the documented envelope. What does the vendor's documentation say the product does under exactly these conditions? Read the current version, with the date. If the documentation says the behaviour is expected, you are in the second or third category; if it says the opposite, you are in the first; if it says nothing, you have a question for the vendor, not an answer.
- Reproduce it in isolation. The same product, configured as documented, without the rest of your design around it. If it fails, product. If it does not, the design or the configuration added something, and the next step is to add your design back one element at a time until it fails again. The fault hypothesis builder is a structured way to run that bisection.
- Check the design's own assumptions. What did the design assume about this component: capacity, state, independence, ordering, the behaviour of the thing next to it? The assumptions guide lists where they hide. A failed assumption is an architecture finding even when the product is also at fault.
- Write down which category, and why, with the evidence that would change your mind. A categorisation that cannot say what would falsify it is an opinion.
Patterns that point each way
Toward the product: the failure reproduces on a clean system; the vendor has a knowledge-base article or a known-issue entry; the behaviour contradicts the documentation; it appeared with a software version and disappears when the version is reverted.
Toward the architecture: the product behaves as documented; the failure occurs only in combination with a second component; it coincides with a condition the design never considered (asymmetric return paths, a shared failure domain, a peak the design did not size for); the same product runs the same function elsewhere without the failure; the fix the team proposes is a workaround that moves the problem rather than removing it.
Toward configuration or operation: a second instance does not fail; the failure started after a change; the documentation describes a setting the instance does not have; the capacity being hit is the one that was configured, not the one the product supports.
Why both can be true at once
The hardest cases, and the common ones in serious incidents, are those in which a product limitation and an architecture failure coincide: a device has a defect, and the design placed that device where its failure takes everything with it. The review has to say both, because the fix is also both, and because fixing only the defect leaves the design waiting for the next defect. The post-incident review has a place for exactly this: the trigger, and the conditions.
What to do with the answer
A product limitation goes to the vendor as a case with evidence attached, and to the risk register as a dependency on their roadmap; if the limitation is a maximum you have reached, it goes to the capacity and refresh conversation. An architecture failure goes to a design change, with the assumption that failed written into the register so that the next architecture review starts from it. A configuration gap goes to the runbook, and to the question of why the runbook let it happen. Buying a new product is the right answer only in the first case, and only after the second has been ruled out with evidence.
If an argument of this kind is running in your organisation, between a team and a vendor or between two teams, settling it with evidence rather than opinion is work I do professionally: independent technical advisory.