Introduction

Description: A brick diagram organizes technology services and components, so an organization can describe and enforce standards, services, and capabilities for a given technology domain. The diagram also describes the lifecycle of technology components -  each component will be in one or more of the following: tactical, strategic, retirement, containment, baseline, or emerging. A brick can comprise one or more solutions/implementations in which an enterprise invests to support its capabilities.

The “bricks” are technology components, which are contextualized by technology domains. See the NIH example here.

Bricks also have their own lifecycle. They should be maintained with regular review and, when no longer needed, retired.

Goals: From this overview deck by Jim Phelps, a brick diagram provides:

Scenarios

For the scenarios listed below, the technology team creates and owns, communicates with portfolio managers. Scenarios include:

• A technology team wants to rationalize where its applications are in their lifecycle

• A portfolio review board and/or sponsors want to understand the investment strategy as it relates to technology  lifecycles

• a service manager wants to know what processes and support are available for technologies in a certain part of a lifecycle, and what the criteria are for moving a technology component from stage to stage

• service managers and technology owners want to understand the standards for investing in a component within a brick (ie, we are investing in x right now, is it the right investment?)

• service managers communicate to users what technologies are recommended and not recommended - and which technologies are entering the environment and which are leaving.  This allows users to plan when to adopt and when to replace technologies.

• Architects can uses bricks to help encourage/enforce architectural alignment.  New projects may be reviewed against the bricks to ensure they’re using the preferred technical solutions.

• The effort of classifying technologies into bricks can be a planning effort itself. The designation of something as “containment” inevitably forces the conversation about what criteria should be used for that designation.

Method

Roles: All of these roles are needed. All participate at some level as both producers and consumers, but from an ownership perspective:

• To create: Service Managers, Technology Owners, Architects

• To leverage as a decision making tool: Portfolio managers, Sponsors

• To govern what is in which stage of the lifecycle:  Architects

• To facilitate the methodology: Architects

Steps: To get the initial diagram:

1. Define the business areas in scope

2. Identify and inventory bricks (technology components) supporting each business area

3. Identify the specific technologies that comprise each brick

4. Classify the technologies according to where they are at in the lifecycle

Once the landscape is described, you need to:

1. define standards for managing technology components in the lifecycle

2. define and govern the methodology for moving components from stage to stage

Terms:

• The nomenclature of bricks

• Define the granularity for technology areas and technology components (bricks) for your organization.

Templates: NIH Template is here (now accessed through the Internet Archive).

Communication

Given a common understanding of the brick diagram the tool is useful in communicating the strategy or plans for specific technologies. This is useful to create a common understanding amongst stakeholders in classifying the technology and having dialogue as to where the technology should be classified and next steps for the technology.

Examples

In addition to the NIH examples linked above, Wisconsin has an example here: https://wiki.doit.wisc.edu/confluence/display/ARCH/Database+Services

Columbia definitions and web server brick example

University of Washington IAM Brick reference

Risks

Many organizations conflate service teams with specific tech solutions.  It can be difficult to conduct a review that maintains these as distinct or that brings people to restructure their service definitions.  

The risk can be mitigated by using the brick diagram (per NIH standard) to describe tech landscape and then using that as an input for strategic discussions on service management and portfolio management.

Bricks must be maintained and up-to-date or they become useless as a reference.  For example, the NIH site itself does not appear to be updated for some time, and many of the bricks are not really useful for choosing solutions.

Related Methods

• Principles: In order to categorize a technology within a brick, criteria are used. Those criteria may be expressed in principles.

• Roadmaps: helps to manage lifecycle transitions. Bricks can work with roadmaps but do not take the place of.

• Capability Maps: defines business capabilities that are supported by the bricks.

• Investment Value Matrix: provides a different lense for assessing lifecycle of a technology within a brick