More detail on MESAs can be found on the Michigan MESA page.

Note: Michigan has migrated towards "MESA Lites" which consist of only a MESA diagram and a "scope, goals, and initiative" page. This format is similar to a Strategy on a Page, only with a graphical component. Here is a "How to Build" document for a MESA lite.

Description: Michigan Enterprise Strategic Assessments (MESAs) are strategic planning tools that allow the university community to see what IT services, products, technologies, and capabilities are being used today, what their future might be, and what new items on the horizon.  

In short, MESAs:

  • Describe the strategy for an IT service, product, technology, or capability area for the next three years.

  • Visually express the current and desired future state of that area.

  • Help make service plans visible to service users, other IT teams, and unit leaders who need to plan for the future.

  • Are reviewed annually by the teams that create them.

  • Provide a consistent format for communicating strategic plans across the organization.


The conversations and thought processes that occur during the creation of MESAs are opportunities for focused, strategic discussions—ones that often don’t happen because of hectic schedules and day-to-day duties. These discussions are every bit as valuable as the resulting MESA artifacts.

MESAs describe the area’s strategy by listing goals to provide value to customers and by stating the concrete initiatives for making progress toward those goals. MESAs include a current assessment of services, products, technologies, and capabilities, and give a view into where they are headed. This provides input to IT initiatives and helps ensure these initiatives are aligned with the university’s IT strategy.

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)


MESAs are used and can be used by anyone at the university who needs to make decisions based on the strategic direction of IT services.

  • Within an IT organization, MESAs are used by leadership and management for strategic planning or to make investment decisions. Technology developers and business analysts use MESAs to determine the best products or technologies to use when building a new service or capability.

  • Customer relations analysts use MESAs to help those outside the IT organization plan initiatives that depend on IT services.

MESAs aid service and product owners in strategic planning; therefore, they write and own the MESAs for their areas. Enterprise architects facilitate the creation of the MESAs, assist in annual reviews, provide the MESA repository, and employ the MESAs as tools for strategic planning and alignment.

  • Use it when there is a need for investment. Consult 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.


  • 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)


Roles: Architect, SMEs, Service/Technology owner.


Before building a MESA for a particular area, it is important to identify the key stakeholders for the area’s strategy and have them involved in the process. This may include, for example, service owners, service managers, product managers, technical managers, and solution architects. When the service is provided by multiple IT units, representatives from all the service providers should be involved, in order to create a coordinated strategy. You should also include important customers or people who can speak to customers’ needs. Since enterprise architects facilitate the process of building MESAs, another critical step is to contact an enterprise architect for assistance.

Creating a MESA usually takes 2-3 meetings with a member from enterprise architecture to review the MESA process, identify scope for the MESA, and work through the steps in defining the goals and initiatives. The enterprise architect can assist in mapping out the components of the MESA onto the various diagrams. It typically takes 1-3 hours offline to finish filling out the MESA document, depending on how mature the area's strategy is.

Since the MESA format is a Google Presentation, each portion of the MESA document has a limit of one slide. This ensures that the MESA is succinct and easy to read; it also means that it should be a straightforward task to complete. To read more about the process of building a MESA, read the How to Build a MESA document.

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.  The Google Presentation Template is here: Template


  • Service and technology catalogs

  • Technology owners

  • Service owners

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


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?)


The following example describes a technology lifecycle for Storage Services:

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).


Want to help with this page? Please see the Method Contributor Guide.

Stewards for this page:

  • Chris Eagle, University of Michigan

Other contributors:

  • Dan Kiskis, University of Michigan
  • Luke Tracy, University of Michigan

  • Bob Guthrie, Washington University - St. Louis

  • Jason Myers, University of Washington

  • Rupert Berk, University of Washington

  • Dana Miller, Miami University of Ohio
  • Leo Fernig, University of British Columbia