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.

• interview capability owners

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.

Goals:

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)

GoalsContext: 

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

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

proposals to assess

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

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)

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:  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

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