MANAGEMENT / OPEN INFRASTRUCTURE

Open Standards Add Options. Long-Term Support Still Needs Investment.

Andrew Yuan · Management perspective · Draft

Official technical sources, management interpretation and a hypothetical platform are distinguished below; no personal project outcomes are claimed.

A second supplier may improve supply flexibility or provide another path for a product. Another decision follows: which hardware and firmware configurations will become part of the product’s support commitment?

That choice creates ongoing engineering work. Before planning the investment, identify which validation can be reused, what work remains, and how long the organization intends to support these configurations.

Start with the need for another option

Supply flexibility, an alternative source, or a customer requirement may justify another supplier. Establish the need first, then decide which configurations are worth supporting.

Successful initial integration is an important step. A second supplier adds an option, but it does not add an extra day to the engineering team’s week.

Updates, diagnostics, and maintenance also need owners. Securing another procurement option should not silently commit engineering to supporting every combination.

Standards compliance still needs a support scope

DMTF’s Redfish Interoperability Profiles provide a concrete example. Redfish schemas allow implementation flexibility; a profile defines feature requirements for a particular class of product or service. DMTF also provides the Redfish Interop Validator to check an implementation against a profile. [1]

Simply saying “supports Redfish” therefore does not fully describe the features an implementation provides.

That conformance check has a defined scope. Two implementations meeting the same profile are not, on that evidence alone, interchangeable suppliers. Nor does profile conformance establish that the complete product’s behavior has been validated.

The specification does not estimate maintenance costs. What follows is my management interpretation: what ongoing investment is needed to sustain the support scope a product promises?

Identify reuse before estimating the remaining work

Consider a hypothetical platform with two hardware revisions and two firmware branches, now evaluating another supplier. This example explains the reasoning; it is not an account of my project experience.

Not every possible combination needs to be tested again. Start with the configurations that will actually be delivered, then distinguish three situations:

• Covered by existing validation: confirm that the original conditions and scope apply, then reuse the results.
• Needs additional validation: identify differences that could change behavior and obtain relevant evidence.
• Outside the support commitment: exclude the configuration explicitly rather than allowing an implied promise.

“We tested it before” does not establish that the results apply to a new configuration. Adopting the same standard cannot replace that assessment.

Where existing validation results and tools remain applicable, the same work need not be funded again. Checking applicability and addressing the differences still require an estimate of the time involved. Make clear which work existing capability removes and which work remains.

Decide support scope and resources together

Does the value of another configuration justify the remaining validation and maintenance effort? Which existing work would be delayed? When an issue crosses team or supplier boundaries, who will drive its resolution?

The CC list can grow, but someone still needs to lead the effort to resolve the issue.

Technical teams identify differences, validation needs, and reusable results. Product and supply-chain colleagues explain the need and value. The people authorized to adjust scope and resources jointly establish which configurations are supported, which are excluded, and who owns the ongoing work.

If the organization cannot sustain the required investment, narrow the support scope or reconsider the timing. Adding an option need not create every possible support commitment. Conversely, if existing capability covers most of the work, recognize that reuse rather than overstating the additional burden.

Plan for updates and the end of support

Initial validation addresses the configuration at that time. Firmware updates, hardware changes, or changes in supplier support may make the original evidence insufficient.

Which changes require revalidation? Who tracks them? When should the organization migrate or end support? Support can have an end date. Deployed devices do not disappear when it arrives. The plan needs to address what happens to them next. These conditions should be agreed in the context of product needs and risk, rather than imposed through a universal threshold.

An integration budget should reflect the configurations the product promises to support and the engineering effort, validation, and coordination needed to maintain them. The decision is which configurations merit that commitment—and which capabilities the organization is prepared to sustain.