On Standards. Revising, Retiring, Obsolete and the Exceptions

Obviously, there comes times when an organization's standards need to be revised, retired and make obsolete. And, there's always going o be that case (or many) when there needs to be an exception. Always.

Revising a Standard

A new version of an established Enterprise Architecture Program standard must progress through the full Enterprise Architecture Program standardization process as if it were a completely new specification. Once the new version receives the appropriate approvals, it will usually replace the previous version, which will be moved to historical status. The new version will retain the RFC number of the previous version.

However, in some cases, at the discretion of the Enterprise Architecture Office, both versions may remain as Enterprise Architecture Program standards to honor the requirements of an installed base. In this situation, the relationship between the previous and the new versions must be explicitly stated in the text of the new version.

Retiring and Standard

As technology changes and matures, it is possible for a new standard or specification to be so clearly superior technically that one or more existing standards or specifications for the same function should be retired. In this case or when it is felt for some other reason that an existing standard or specification should be retired, the Enterprise Architecture Governance Committee shall approve a change of status of the old specification(s) to “Obsolete.” The Enterprise Architecture Program will allow a set time after notification to stakeholders before classifying retired standards as “Obsolete.” A request to retire an existing standard can originate from a domain team, an ad hoc working group, or another stakeholder.

Obsolete Standards and RFCs

A specification that has been superseded by a more recent specification or is for any other reason considered obsolete is classified as “Obsolete.” Any stakeholder may recommend that an RFC or standard be classified as obsolete.

The Enterprise Architecture Office will maintain an archive of obsolete RFCs indefinitely. This repository is the authoritative source for obsolete RFCs. However, a record of the obsolete RFC will remain on the Enterprise Architecture Program website with the classification of “Obsolete.” The Enterprise Architecture Office will annotate the obsolete RFC with the reason it is obsolete and a citation for the mechanism, such as a new RFC, that obsoletes it.

The decision authority for classifying a Best Community Practice or Informational RFC as obsolete is that of the Enterprise Architect, whose decision consensus may be appealed to the Enterprise Architecture Governance Committee for final disposition. The decision authority for RFCs in the Standards and Governance Sub-series is the Enterprise Architecture Governance Committee, whose decisions may be appealed to the IT Governance Committee. The final disposition of an obsolete RFC should be communicated to the Enterprise Architecture Program community and to the RFC author.

Exceptions to the Architecture

Furthermore, business requirements and innovation sometime necessitate a temporary exception to the Enterprise Architecture. In these situations, a stakeholder must submit an Enterprise Architecture Program Exception Request to the Enterprise Architecture Program in accordance with the process specified in “Enterprise Architecture Program Exception Process.” In this way non-standard technologies may be procured and implemented in the information technology environment on a temporary and limited basis or until such time the procured technology can be incorporated as a standard, if the organization so chooses.