The goals of an Enterprise Architecture Program standards process should be:
To that end, organizations should create procedures that are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Enterprise Architecture standards. At each stage of the standardization process, a specification should repeatedly discussed and its merits debated in open meetings and via community discussion in an Enterprise Architecture Program Community.
There are two, primary development processes and documentation sources for Enterprise Architecture Program standards that I recommend.
I. Domain Teams & Ad-Hoc Working Groups II. Requests for Comments (RFC).
In a prior post I discussed the Domain Teams & Ad-Hoc Working Groups. In this post, let’s take a look at the concept of Requests for Comments.
The Request for Comments (“RFC”) document series is the official publication channel for standards documents, which are produced outside of the domain team process, and other architecture-related documents.
These documents are published in Enterprise Architecture Program website and is the authoritative source for this document series.
There are four sub-series in the main RFC series:
Some RFCs document organization standards. These RFCs form the standard sub-series of the RFC series and will receive a ‘Standard’ category label, in addition to a RFC number.
A specification that is intended to be documented in standards sub-series RFC must be posted in the Enterprise Architecture Program community. An RFC author must submit it in the format and method as prescribed in Enterprise Architecture Program RFC. The method and RFC template are available on the Enterprise Architecture Program community.
The document must clearly identify the purpose and expected outcome of the standard before the document enters the review and approval process.
The RFC shall be subject to review by the community for no less than ten business days. RFC authors are required to respond to each discussion comment on the community to ensure that all stakeholders’ concerns can be incorporated into the document to the extent possible. After this time period has elapsed, the Enterprise Architecture Office will initiate one of the following actions: [infobox]
If the RFC requires review by a domain team or ad-hoc working group, the respective team must make a recommendation to the Enterprise Architecture Governance Committee on the disposition of the RFC.
Regardless of the duration of the review period for the RFC, the Enterprise Architecture Office shall provide a five business day advance notice of the expiration of the review period. As an example, a document is posted to the community, and Enterprise Architecture Office announces the beginning of the review period. Five business days later, the Enterprise Architecture Office announces that there are five days remaining in the review period. At the conclusion of the minimum ten business days, the Enterprise Architecture Office may close the review period, and the RFC author may incorporate recommendations into the final RFC. Thereafter, the RFC author or the Enterprise Architecture Office may request the IT Management Committee Enterprise Architecture Subcommittee and the Enterprise Architecture Governance Committee consider the RFC for adoption as a standard. The IT Management Committee Enterprise Architecture Subcommittee may make a recommendation to the Enterprise Architecture Governance Committee. However, the Enterprise Architecture Governance Committee is the decision authority for a standard or specification.
The IT Management Committee Enterprise Architecture Subcommittee and the Enterprise Architecture Governance Committee may consider all pending standards sub-series RFCs during the regular course of business as outlined in these bodies’ governing charters.
The RFC author or a delegated representative shall be prepared to brief the Enterprise Architecture Governance Committee or other architecture governing bodies that are considering a proposed standard. Briefing topics might include but are not limited to the justification of a proposed standard, supporting decision analysis, and any unresolved conflicts. Regardless of whether or not the governing body requires the author to brief, a document supplement must be included describing any applicable decision analysis and the status of unresolved conflicts.
If a standards action is approved, notification is sent to the Enterprise Architecture Office and copied to the Enterprise Architecture Governance Committee and IT Management Committee Enterprise Architecture Subcommittee with instructions to publish the specification as an RFC.
The Enterprise Architecture Office will maintain a status describing the disposition of pending and approved RFCs.
The Enterprise Architecture Program website is the authoritative source for approved RFCs.
Some RFCs are statements of principle or an agreed upon approach to completing a process, operation, or architectural function. These RFCs form the Best Community Practice (“BCP”) Sub-series and are assigned a “Best Community Practice” category label, in addition to a RFC number.
The Best Community Practice Sub-series of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as is a standards document and thus is a vehicle by which stakeholders can define and ratify the community’s best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or architecture process function.
Historically architecture standards have generally been concerned with the technical specifications for hardware, data, and software required for interoperation within the community. However, since the architecture is composed of systems operated by a variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the information services follow some common guidelines for policies and operations. While these guidelines are generally different in scope and style from architecture standards, their establishment needs a similar process for consensus building.
Business units have a role to play in the Enterprise Architecture process, independent of domain teams and ad hoc working groups. As leaders in the technical community, the business units should have an outlet to propose ideas to stimulate work in a particular area, to raise the community’s sensitivity to a certain issue, to make a statement of architecture principle, or to communicate their thoughts on other matters. This Best Community Practice Sub-series creates a smoothly structured way for the business units to insert proposals into the consensus-building machinery of the architecture while gauging the community’s view of that issue.
A business unit or other stakeholder may submit Best Community Practice to Enterprise Architecture Program for review. After a ten business day waiting period, and after Enterprise Architecture Office has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the Enterprise Architects.
Because Best Community Practices are meant to express community consensus but are arrived at more quickly than standards, Best Community Practices require particular care. Specifically, Best Community Practices should not be viewed simply as stronger informational RFCs but rather should be viewed as documents suitable for content different from informational RFCs.
An “informational” specification is published for the general information of the Enterprise Architecture Program community and does not represent community consensus or recommendation.
The “informational“ designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources and the Enterprise Architecture Office’s consent for publication. The Enterprise Architecture Office members must validate and reach consensus that the document is applicable to the Enterprise Architecture Program community and does not place the organization at risk.
Unless they are the result of architecture domain team action, informational documents should be submitted directly to Enterprise Architecture Program. The Enterprise Architecture Office will publish any such documents on the Enterprise Architecture Program community The Enterprise Architecture Office will wait ten business days after this publication for comments before proceeding further. The Enterprise Architecture Office is expected to exercise good judgment concerning the editorial suitability of an informational RFC and may refuse to publish a document that, in the expert opinion of the Enterprise Architects, is unrelated to architecture activity or falls below the technical and/or editorial standard for RFCs. After the minimum ten business days have expired and no other further action is initiated by a stakeholder, the Enterprise Architecture Office may publish the RFC to the authoritative source for Enterprise Architecture standards. Generally RFCs in this sub-series do not require Enterprise Architecture Governance Committee approval.
However, the Enterprise Architecture Office will ensure that informational designations are not misused to circumvent the standards processes. As such, the Enterprise Architecture Office will refer to the Enterprise Architecture Governance Committee any document submitted for informational publication, which, in the opinion of the Enterprise Architecture Office, may be related to work being done, or expected to be done, within the Enterprise Architecture Program community. The Enterprise Architecture Governance Committee shall review such a referred document within a reasonable period of time, and recommend either that it be published as originally submitted or referred to the Enterprise Architecture Program as a contribution to the Enterprise Architecture Standards Process.
If the Enterprise Architecture Governance Committee recommends that the document be brought within the standards sub-series but the author declines to do so, or if the Enterprise Architecture Governance Committee considers that the document proposes something that conflicts with, or is actually inimical to, an established architectural effort, then the document may still be published as an informational RFC. In these cases, however, the Enterprise Architecture Office may insert an appropriate disclaimer into the RFC either in or immediately following the “Abstract” section in order inform stakeholders about the circumstances of its publication.
Some RFCs document Enterprise Architecture Program processes that govern the creation and application of the Enterprise Architecture. These RFCs form the Governance sub-series and are assigned a “Governance” category label, in addition to a RFC number.
The Governance Sub-series documents the processes that govern the operation of the Enterprise Architecture Program itself. A governance document is subject to the same basic set of review and approval procedures as is a standards document and thus is a vehicle by which stakeholders can define and ratify the community’s best current thinking on what is believed to be the best way to perform an Enterprise Architecture Program process function.
During the development of a specification or a standard, draft versions of the RFC document are available for review and comment on the Enterprise Architecture Program community. Recommended changes and comments must be submitted in the discussion area to ensure an open, collaborative approach to standards specification. RFC authors are required to respond to each discussion comment on the Enterprise Architecture Program community to ensure that all stakeholders’ concerns can be incorporated into the document to the extent possible.
A draft, proposed, or revised RFC will be moved to an archived status, if it has not been approved within six (6) months of its submission to the Enterprise Architecture Program in order to reduce overhead in the administration of the process and confusion concerning the status of unapproved documents. In the case of a revision that has not been approved, the previous version will remain the authoritative source until it is classified as obsolete or retired. Subsequent to a document being deleted, stakeholders may resubmit a newly revised version of the document at a later date.
The RFC author is the only authorized editor for substantive changes to an RFC unless the RFC author has appointed a delegate. An RFC author must submit it in the format and method as prescribed in Enterprise Architecture Program RFC.
The Enterprise Architecture Program will appoint an RFC editor to proofread the document for grammar, consistency, and readability. In the case of a minimal number of minor errors of these types, the RFC editor may make the change to the document but must document and notify the author of the changes.
Standards Sub-series RFCs should include the rationale, justification, or decision criteria and analysis that supports the proposed standard.
A draft RFC in the Standard or Governance Sub-series may not become a standard without the approval of the Enterprise Architecture Governance Committee. However, a draft RFC in the Best Community Practice or Informational sub-Series may be published after a minimum ten business-days review period on the Enterprise Architecture Program community
All draft RFCs will contain a “Draft” watermark. The RFC Editor will assign the RFC number and appropriate category label when the document is ready for review by the community. However, it will not lose its draft designation and watermark until it is approved by the designated decision authority.