Dispatches¶

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: