Product
What it is: a tangible component — a hardware appliance, software package, tool, standard or reference implementation — packaged by a vendor or developed in-house to provide the technological foundation for executing security mechanisms and sub-mechanisms, translating conceptual and logical designs into procurable solution artefacts.
What you need to do:
- Select or build the product only after the physical system, mechanism and sub-mechanism it needs to deliver are already defined. The product is the last link in the chain, not the first.
- Identify the product specifically — name, version, vendor — so its feature set, supported protocols and constraints are unambiguous.
- Confirm the product conforms to the industry standards, regulatory requirements and enterprise policy the domain has already set.
- Govern the product through its full lifecycle: procurement, deployment, patching, upgrade and retirement, not just the initial selection decision.
- Keep the product's interface specification, constraints and support agreements documented so the organisation isn't dependent on one person's memory of how it was chosen.
Inputs: the physical systems and mechanisms it must deliver, enterprise technology standards, vendor and market options.
Outputs: a procured or built product, governed through its lifecycle, delivering the physical systems the architecture specified.
Watch for: choosing the product first and reverse-engineering the logical and physical layers to justify it. This is exactly backwards, and it's how architecture becomes vendor-shaped instead of business-shaped.