Skip to content

2012

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 ersponsibility 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.