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).
Let’s take a look at the concept of Domain Teams and Ad-Hoc Working Groups.
Enterprise Architecture domain teams are convened by the Enterprise Architecture Office to develop standards and guidelines for information systems. The work of the domain teams is consensus-based. The domain teams produce reports that include recommended principles, architecture patterns and bricks, and recommendations for action.
The Enterprise Architecture domain teams are temporary teams established to develop Enterprise Architecture artifacts within a specific domain of the Enterprise Architecture. For example, a domain team may be assembled to validate a data model, which is a specific model of the Information Architecture. Or, a domain team may be assembled to develop an architecture brick that lists approved standards for a specific technology such as enterprise level database management systems, web-servers or operating systems.
Another method for documenting Enterprise Architecture standards and best community practices is the Request for Comments (RFC) series. Any stakeholder or working group can propose a new standard or best community practice using this document series.
The process by which domain teams and working groups develop Enterprise Architecture artifacts is one based on consensus. As illustrated in the sections below, domain expert teams and working groups follow a structured process for reaching consensus.
This process ensures cross-organizatio representation, consensus, and alignment.
At a high-level the process is as follows:
Most of the time a stakeholder request (individual or governing body) leads to the identification of a need to establish or update a standard. However, there are other ways a need is identified. For example, the Enterprise Architecture Office may initiate an internal project that requires the organization-wide perspective that domain teams provide. Or, it is possible that the Requests for Comments (RFC) process is not able to produce a standard, in which case the Enterprise Architecture Office may decide to establish a domain team.
After the need is identified, the Enterprise Architects may determine that a domain team is the most appropriate standards development process to meet the need.
Once the Enterprise Architecture Office determines that a domain team will be convened, they will define the scope of the domain team. Then, a formal request is sent to technology business unit directors and/or manager and other relevant stakeholders (as determined by the Enterprise Architecture Office) to nominate members for the domain team. The Enterprise Architecture Office then selects the team members.
Because all technology business units are invited to participate in the domain team process, it is assumed the business units have delegated decision-making authority to their respective representatives. Therefore, it is assumed that the domain teams’ recommendations have been vetted by the business units.
A working group can also be convened to develop a standard or best practice. Working groups are comprised of stakeholders who may include individuals, groups, and organizations. Contributions from working groups may be unsolicited.
The domain team or working group begins its work with a formal orientation, or training, kickoff session, during which all members are informed of the work to be accomplished by the team and the plan to accomplish it. The domain team or working group then begins its work. The following are the basic steps each domain team or working group performs to develop their recommendations:
After the domain team or working group completes its analysis and finalizes its recommendations, it documents its recommendations in the form of a summary presentation, which the team will present to the Enterprise Architecture Governance Committee or other governing bodies as needed.
During this step the appropriate decision making authority(ies) review the working group’s recommendations and either approve or reject the working group’s proposed standard; or request further analysis. The RFC author then incorporates recommendations, if any, into the final RFC.
During this step the appropriate decision making authority(ies) review the domain team’s recommendations and either approve or reject the domain team’s recommendation; or request further analysis.
The IT Management Committee Enterprise Architecture Subcommittee reviews the domain team reports, develops comments and recommendations on the disposition of the domain teams’ findings, and forwards the reports with their recommendations and findings to the Enterprise Architecture Governance Committee. The Enterprise Architecture Governance Committee is the approval authority for the architecture recommendations contained in the reports. The IT Governance Committee is the final authority on disputed recommendations from the domain teams’ findings and recommendations.
The Enterprise Architecture Program publishes the approved changes online to the Enterprise Architecture Program Library and notifies all Enterprise Architecture Program stakeholders.