Dispatches¶

On Enterprise Architecture Roles and Responsibilities

The following groups are used throughout this the Enterprise Architecture concepts I present on this site. More full descriptions may be provided in an example Enterprise Architecture Charter.

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:

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.