Skip to content

Dispatches

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.

  1. Domain Teams and Ad-Hoc Working Groups
  2. 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.

On Standards. Disputes, Process Failure, and Issues

Disputes are possible at various stages during the standards process in an Enterprise Architecture Community. To achieve the goals of openness and fairness, such conflicts should be resolved by a process of open review and discussion.

This article discuses some high-level procedures that I've employed in an Enterprise Architecture Program to address disputes that cannot be resolved through the normal processes whereby domain teams and ad hoc working groups and other process participants ordinarily reach consensus.

On Standards. Request for Comments

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.

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.

On Standards. Alignment, Process, and Community

In a prior post I discussed "10 Standards Selection Decision Criteria". In this post I discuss how a standard can be defined and the need for a community process.

Organizations are evolving. They realize that there is a vital responsibility for information technology to maximize the benefits of providing the best possible product or service through improved business alignment. Enterprise Architecture is a key element in creating a business environment that is both effective and efficient.

Organizations that are driving towards a mature Enterprise Architecture must have a standards process(es). The practices should be concerned with all consensus-driven standards that are developed as part of as Enterprise Architecture Program. In the case of standards developed by other organization, the standards process normally applies to the application of the protocol or procedure in the organization's context, not to the standard itself.

On Enterprise Architecture Principals

As discussed previously, principles are high level statements of the fundamental values that guide business and technology decision-making and activities and are the foundation for architecture, standards, and policy development. Principles are stable enough to withstand technological and process changes but timely enough to maintain a clear relevancy with markets, policy, program, and management changes.

Principles consist of the principle statement, rationale, and implications. Though the wording for principles should remain consistent, the rational and implications will evolve over time, as an organization responds to factors such as the current IT environment, internal initiatives, external forces and markets, and changes in mission, vision, and strategic plan.

In my prior role as an Enterprise architect, I used the following 16 Principles for the foundation of the Enterprise Architecture. Even with the changes that have rocked the industry in the past 3 years - public, private and hybrid cloud computing, dev-ops, etc - these principles have been steadfast.

On Bricks

A Lifecycle Model

A brick specifies adopted technical standards and protocols or technologies and products. They define current and future standards. They also define products or standards in the current environment that are to be retired or contained.

Visually, a brick is formulated as:

DESCRIPTION
Description of the Brick Model
BASELINE
(Today)		 TACTICAL
(0-2 Years)		 STRATEGIC
(0-2 Years
Products or technologies currently in use. Mainstream products or technologies recommended for use. Mainstream products or technologies recommended for use.
RETIREMENT
(To be eliminated.)		 CONTAINMENT
(No new development.)		 EMERGING
(To track.)
Products or technologies slated for retirement. Products or technologies recommended for containment with limited investment or committment. Products or technologies to be evaluated.
COMMENTS
Additional comments about the products or technologies withing the brick moduel.
APPROVED ON NEXT REVIEW ON
Date approved. Date for next review.

Keep in mind that there is a much better way to manage these brick models that creating each individually like the above. For example, working with one of my past teams we developed an bespoke application based on The Essential Project Meta-Model to input all technology reference models components and capabilities so that the visual representation.

Each brick categorizes the specified technologies by lifecycle designations that accommodate the organization’s diversity and the architects' recommendations:

On Principals

Laying the Foundation

Principles are high level statements of the fundamental values that guide business and technology decision-making and activities and are the foundation for architecture, standards, and policy development.

They are stable enough to withstand technological and process changes but timely enough to maintain a clear relevancy with markets, policy, program, and management changes.

On Standards

When an individual, group or pulls the "It's a Standard" card, what's your reaction? Do you take it for face value or do you question the "standard" and how it achieved this status?

I often find that these "standards" are defined without a clear path. Many are "de-facto standards" that have "always been that way" and others an individual or group labeled as a standard because it was confortable.

For example, I had a customer's application delivery teams select the infrastructure and management platform for a desktop virtualization solution while dismissing the organizations investment, expertise and success with technologies that run > 90% of enterprise application workloads. All based on their perceived comfort from the brand name of the vendor.

I'm of the opinion that organizations should adopt a set of baseline decision criteria that are used for the purpose and process of selecting and gaining consensus on architecture standards. This baseline should represent the minimum set of decision criteria needed, and this baseline can be used as the basis of a business case analysis.

When the someone or some group (e.g., domain team, ad hoc working group, or other body/individual) of a proposed standard applies these criteria, they can then prioritize the relative importance of each criterion by assigning weights as applicable given the technical domain for which these criteria are being considered.

Prioritizing, weighting, and applying these decision criteria ensures the same level of analysis in considering standards that a project and product manager exercises when developing a project proposal for a potential investment.