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:
trends and insights
current state
short term plans
long term plans
what is in containment
- what is being stopped
Context: This framework provides decision makers with a method to plan and prioritize investments and manage technology lifecycles.
Too often enterprises have difficulty retiring technologies/services. When done, it is often difficult to do in an orderly fashion. Similarly, it is difficult to determine when in the adoption cycle to invest. Brick diagrams help stakeholders make these decisions and build them into an ordered plan.
Scope: This tool can be used at a strategic level for prioritization and investment rationalization. It can be applied at the line of business level, by service teams, technology owners, central IT to manage the technology lifecycle.
Source: This method originated at the National Institutes of Health: https://web.archive.org/web/20150404120523/https://enterprisearchitecture.nih.gov/Pages/technology-architecture.aspx
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:
Define the business areas in scope
Identify and inventory bricks (technology components) supporting each business area
Identify the specific technologies that comprise each brick
Classify the technologies according to where they are at in the lifecycle
Once the landscape is described, you need to:
define standards for managing technology components in the lifecycle
- define and govern the methodology for moving components from stage to stage
Terms:
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.
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