On Standards. Domain Teams, and Working Groups
The goals of an Enterprise Architecture Program standards process should be:
- Technical excellence,
- Adoption of proven technology in the environment,
- Clear, concise, and easily understood documentation,
- Openness and fairness,
- Timeliness and
- Organization-wide distribution and use.
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.
- Domain Teams and Ad-Hoc Working Groups
- Requests for Comments (RFC).
Let's take a look at the concept of Domain Teams and Ad-Hoc Working Groups.
Enterprise Architecture 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:
1. Identify the Need for a New or Revised Standard, or Best Practice
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.
Exit Criteria:
- The Enterprise Architects determines a domain team should be established.
- Stakeholders or Enterprise Architects determine a working group should be established.
2. Establish the Team
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.
Exit Criteria
- Scope of the domain team or working group is defined.
- Formal request is sent to business unit directors and/or manager relevant stakeholders for nominations.
- Domain team members are selected.
- Invitations are sent to domain team members, meetings are scheduled and rooms secured.
3. Conduct the Team
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:
- Understand the current state for the team’s technology area of focus. (For teams that are selecting technology standards this will be defining the current baseline for the specific technology area [i.e., technical domain]).
- Establish or validate guiding principles.
- Finalize the decision criteria the team will use to make its decisions.
- As appropriate, conduct market research to ensure a complete scan of all available products and technologies within the technical domain, and understand the strengths and weaknesses of each vis-à-vis the decision criteria.
- As appropriate, write and issue a Request for Information (RFI) so that all vendors have an opportunity to be included in the evaluation process.
- Deliberate to achieve consensus based on analysis of available information (i.e., current baseline, market research).
- Develop recommendations.
- Compile the team’s next steps and final recommendations.
Exit Criteria
- Meetings are conducted.
- Proposed artifacts are either updated or created (e.g., principles, bricks and patterns.)
- Draft executive briefing is created.
- Domain team checklist is updated.
4. Produce Team Products
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.
Exit Criteria
- Final executive briefing is created (domain team and working group.)
- Draft RFC completed (working group only).
5.a Execute the Approval Process for Working Groups
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.
Exit Criteria
- A finalized standard or best practice.
- An approved standard or best practice.
5.b Execute the Approval Process for Domain Teams
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.
Exit Criteria
- A finalized standard or best practice.
- An approved standard or best practice.
6. Publicize the Approved Results
The Enterprise Architecture Program publishes the approved changes online to the Enterprise Architecture Program Library and notifies all Enterprise Architecture Program stakeholders.
Exit Criteria
- Update to the Enterprise Architecture Program website with the results and artifacts of the domain team (e.g., principles, bricks and patterns, et al.)
- Communicate to stakeholders about changes.
- Participants recognized.