Introduction

More, and up-to-date, detail on MESAs can be found on the Michigan MESA page.

Description: The “mesa” visually expresses both the architectural approval (whether it is recommended) and the lifecycle of a thing in a given environment. The architectural approval is currently expressed by icons that indicate “YES” or “NO”. The life-cycle is indicated by the position of the icon on a curve shaped like a “mesa” with a plateau in the middle. Things typically enter the environment and travel up the left slope of the mesa and exit the environment on the right slope of the mesa. The thing that is described with a “mesa” may be a technology, service, or other.  X axis=life cycle.  Y=Either maturity or usage.  You choose the units for your y axis depending on what you are trying to convey.

Strategic objectives and standards measured/viewed on a lifecycle.

• Understand capabilities

• interview capability owners

• catalog capabilities/services that are on the horizon

• understand not well used technologies that are incurring lots of technical debt

• Annual reviews are needed to understand expected patterns in the lifecycle

• If something is stuck somewhere on the “mesa” what is being done to manage or deprecate the technology?

• the “mesa” can be used to see if there are replacements for capabilities and if none exist then existing (less effective) technologies can not be deprecated

Compared to Brick Diagrams, the MESA captures much of the same data but also provides a visual lifecycle view. Bricks do not have a concept of cadence. Bricks have defined stages that are absent from the MESA (containment, strategic)

Goals: 

• Useful life of technologies/capabilities/services

• A real look at all technologies used at the enterprise, or a visual view of a service catalog

• Risk for Users (should I adopt/use this technology/service)

• A very high-level roadmap

• Highlights technology and service use decisions

• This could potentially be used to assess why a decision was made or when decisions are changed

Context:

• Use it when there is a need for investment proposals to assess the “mesa” to ensure they are making the correct investment decisions.
• Use it to create a sunset action plan.
• Use it to map/understand changes that are expected to happen within services/technology groups.
• Use it to help map user risk (should I use this service/technology or not)
• Use it (in conjunction with an annual review) to identify services/technologies that are not following the expected pattern.
• Don’t use it for stable/static environments.  The MESA is mostly about mapping and managing change.

Source: Chris Eagle, University of Michigan

Scenarios

• Communicate the lifecycle of technologies to consumers. For instance, should we encourage students to use Dropbox? What are the alternatives that look more promising? What are alternatives moving into the environment. (alternative to brick)

• Communicate the lifecycle of services. (alternative to brick)

• Communicate the maturity of capabilities (alternative to heat-mapped capability map)

Method

Roles: Architect, SMEs, Service/Technology owner.

Steps: 

• Phase I: define scope.  What are the capabilities/technologies that should be put on the MESA? This will generally be a superset of currently implemented items. This phase can mostly be done with architects and SMEs
• Phase II: Place items from phase I on the mesa.  This phase will introduce Owners to the process.
• Phase III:  Make the roadmap/recommendations for changes to the mesa.  This phase introduces customer/high-level IT either as inputs or to validate the proposed roadmap.
• Phase IV: Annual Review.  The MESA is really dependent on periodic reviews to achieve the desired outcomes.  The annual review is used to ensure the MESA is “evolving” as described in the roadmap section and also to assess common patterns for exceptions (items stuck on either of the slopes, items nearing end of life without a replacement technology coming on to the mesa, redundant technologies, technologies in high-use but not on the mesa, etc)

Terms: Terms have yet to be identified. In time terms will emerge for the various positions on the curve.

Templates: MESA Document is the planned outcome and artifact

Tools:

• Service and technology catalogs

• Technology owners

• Service owners

• Others in the organization that may own/support technologies and services

Communication

The mesas themselves are a visualization.  They can be presented individually, for a deep dive into a particular area.  Multiple mesas can be combined on a single page for a visual overview of a larger area.  Portions of multiple mesas can be combined for a view on specific aspects of the lifecycle (what are all the technologies that are on the up-slope?  what are all the technologies nearing end-of-life?)

Examples

The following example describes a technology lifecycle for application integration:

• https://docs.google.com/document/d/1VJkt3H-yvJDlG8q-dTubPNivEqBlx6R2IS7LL5sz8i8/edit

An anti-pattern is using this tool to describe things that are more static in nature e.g. a business capability. The tool is better used to communicate change and trends.

Related Methods

Other tools that are related to the MESA include:

Brick Diagrams: There is much overlap with Bricks and Patterns - there is text above the describes some of the differences.  The MESA document provides a temporal dimension that is missing from the Brick diagram.

Capability Maps: For business level MESAs (such as services), capabilities are expected to be listed on the mesas.  However, the MESA is about tracking and managing change, (i.e. maturity of capabilities) and is not a replacement for a fully thought out Capability Map. A MESA can be an input to a Capability Map and vice versa.

Roadmaps: The MESA isn’t really time-based like a roadmap, but it does give a general expectation for changes to be made to the items on the mesa.

TIME Models: While not currently fleshed out, the MESA is somewhat dependent on a Time-Model-like mechanism in order to provide some objectivity for placing items on the mesa. Without this, the mesa is purely subjective (which is still probably better than the status quo, but not ideal).