From reference architecture to as-built: the configuration handoff

A reference architecture gives a project a documented starting point. But the installation also needs a clear record of which design version was selected, what the supplier quoted and what was actually installed. Without that connection, support teams may have several possible configurations to investigate without knowing exactly what changed.

Before placing the order, create a record that compares three things: the reference requirements, the approved supplier quote and the installed configuration. Give each item a unique row ID so you can track servers, network adapters, software dependencies and site requirements through any revisions.

For example, Lenovo's CAE reference architecture includes different configurations for entry-level and scale-out systems. Its revision history also documents changes to benchmark methodology. Keep the exact document revision and relevant sections used for the project. A document title or benchmark screenshot alone isn't enough to identify the configuration being purchased.

Keep passwords, license keys and sensitive network details in your approved internal system. The handoff document can reference where they're stored without exposing them to suppliers or other unauthorized users.

Be specific about what each document proves. A server compatibility matrix may confirm that two hardware components are supported together. An operating-system matrix may show support for a particular release. A reference architecture describes the intended design, while a site test shows how the installed system performed. These records support different decisions, and one doesn't replace the others.

Lenovo's OS Interoperability Guide identifies different support levels and explains why installed components must also be checked when evaluating operating-system compatibility. Save the relevant results and notes rather than simply recording that the server model appears in the database. For network adapters, include the exact part number and applicable driver and firmware information.

NVIDIA's certification documentation distinguishes different testing scopes and points to separate software and infrastructure support references. Record the exact certification or design claim that applies to your configuration. Don't assume a certified server automatically means every connected storage system, application or facility setup is certified. Ask the responsible supplier to clarify any uncertainty in writing.

Give every proposed substitution its own exception ID. Record the original requirement, suggested replacement, reason for the change, affected connections and evidence needed for approval. A different network adapter may require changes to drivers, firmware, cables or slot placement. A different memory arrangement can also change the system configuration even if total capacity stays the same.

Keep commercial approval separate from technical approval. A buyer might accept a new price or delivery date, but the technical owner still needs to confirm compatibility and support. Ask the OEM or responsible integrator whether the substitution remains within the approved design and support requirements. Not every change automatically invalidates certification or support; it depends on the specific configuration and program.

Close the exception only after the responsible reviewers approve the evidence and the required tests pass. If a proposed replacement is rejected, keep the decision in the order history. This prevents the same unsupported option from being suggested again during future purchasing or warranty replacements.

Imagine an engineering team orders an eight-node compute cluster based on a specific OEM reference design. Before assembly, the quoted network adapter becomes unavailable. The supplier suggests another adapter with the same advertised link speed. This fictional example shows how to document a substitution; it doesn't mean the two adapters are necessarily interchangeable.

The team creates exception EX-07. The record includes both part numbers, the affected nodes, slot and riser placement, cable connections, firmware, drivers and software image. The architecture owner requests compatibility evidence and confirmation of support coverage. The revised price is recorded separately. Until technical approval is complete, the eight affected configuration rows remain open.

Suppose the alternate is approved but requires a different driver bundle and updated cable records. The team revises the quote, installs the approved configuration and captures inventory details for all eight nodes. It then repeats the agreed network checks and representative application test, recording the dataset, node count and software version. The final handoff links the approval, updated software image, cable records and test results to EX-07.

The completed record explains what changed and why the installed configuration was accepted. It doesn't claim the system will reproduce every OEM benchmark. If the application test fails to meet the project's agreed target, the exception remains open even if the adapter is listed as compatible.

A factory test report should identify the tested equipment, configuration, software and test procedure. When the equipment arrives, confirm asset identities and document any shipping or installation changes. After connecting the site network, identity services and storage, repeat the checks agreed for those dependencies. Clearly identify which results came from factory testing and which came from the actual operating environment.

Define the application test before using it for final acceptance. Record the workload and version, dataset, number of users or nodes, test duration, expected output and performance target. Keep the actual results, including failures. If recovery or failover testing is required, use an approved maintenance window and documented procedure. A successful power-on test or individual component benchmark doesn't prove that the complete system meets its operational requirements.

If the team accepts a temporary exception, record its limitations, owner, due date and required retest. Keep it visible in the handoff so the operations team understands what has been verified and what still needs attention.

Before final acceptance, reconcile every required configuration record. Give the completed handoff a revision number and capture date, and identify the inventory export or other evidence supporting it. Include the exception register, acceptance results, operating documentation and support contacts. The receiving technical owner should confirm that the records accurately describe the installed system.

Use the same record for future changes. Firmware updates, software image replacements, additional nodes or replacement parts should create a new revision with the reason for the change and any required checks. Keep the previous approved version and recovery procedure where applicable. An accurate, maintained record makes troubleshooting, support requests and future purchasing much easier.

Use the configuration ledger throughout deployment to keep the approved design, delivered components and installed system aligned. For earlier supplier selection, the integrator checklist can help evaluate responsibilities, proposal documentation and operational handoff requirements.