Skip to content

Dispatches

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.

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.