Skip to content

2012

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.