Methods are a “toolbox” of common ways to do architectural analysis, known to help groups work on architectural goals. Architectural methods focus on high level themes, helping people get a big picture view of what they are planning or designing. Any group can get started with a method, even without a dedicated architect.
Architecture methods should be applied with group participation, ideally in a workshop setting. Usually the greatest value a method provides is in the shared understanding that results from working together, not the final document. And the more we use similar methods, the more easily we can communicate across groups at the UW.
Choosing Methods
For examples of applying architecture methods to different contexts see:
Featured Methods
These methods are most commonly used by the EA team and recommended for most types of initiatives:
Strategy on a Page
Often the starting point for thinking about a program or service, this one-pager is a fast way for people to align on their drivers, intended outcomes, and possible steps to take.
Business Process Mapping
Frequently the best way to build understanding of the current state, this method focuses participants on how value is delivered, across all participants and regardless of what technologies are in use.
Sources: UW-IT EA | BACoP | Itana
Capability Mapping
Capabilities describe what the organization needs to be able to do to succeed, regardless of how the capability is delivered. This helps groups agree on where to prioritize their effort.
Conceptual Data Modeling
Description: Conceptual data modeling is a method for teams to share understanding and work on what information an organization needs. Common uses are to clarify and communicate how information is currently stored in existing systems; identify gaps or constraints in how information is stored; or compare with how data is stored in potential future solutions.
Sources: UW-IT EA | BACoP | Itana
Additional Methods
These methods are also part of an architect’s toolbox for different situations:
Brick Diagram
A “Brick” is a method used to plan and communicate the life cycles of products, services, and technologies; it describes phases from “emerging” to “retirement.”
Examples:
Business Model Canvases
A business model canvas is a tool for facilitating discussion of how an organization works – who it serves, and how it does that. It’s useful when imagining or defining a new program or service, or for clarifying an existing one.
Sources: BACoP
Sequence Diagrams (or Interaction Diagrams)
A sequence diagram visualizes the interactive behavior of a system.
Sources: UW-IT EA
MESA
The MESA visually expresses both the architectural approval (whether it is recommended) and the lifecycle of a thing in a given environment. 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.
Sources: Itana
Pace Layers
Pace-Layered Application Strategy is a methodology for categorizing, selecting, managing and governing applications to support business change, differentiation and innovation, [based on the rate of change of the application]” (Gartner). Pace-layering differentiates the rate of change into three categories – Systems of Record (slow change), Systems of Differentiation (medium change), and Systems of Innovation (high change).
Sources: Itana
Roadmaps
A Roadmap shows a path from current state to a desired future state. The roadmap method builds consensus on vision, goals, milestones, and deliverables. The roadmap can be used to rally a community around a plan for action as well as manage expectations for outcomes over time.
Sources: Itana
Stakeholder Engagement
Stakeholder engagement is an essential foundation of most architecture work. Most change that an architect seeks to bring about – whether it is a change to a technology, business process, or policy – depends on the participation, agreement, and buy-in of stakeholders.
Sources: UW-IT EA
Systems Diagrams
This method provides systems context for a change – at a high level, what systems are involved and how do they interact?
Sources: BACoP
User Experience Mapping
The user experience is an important part of most solutions, whether the solution includes an application, business process, or both. Solutions that are designed for a great user experience are more likely to be fully adopted and deliver the most value.
Sources: UW-IT EA
Additional Sources of Methods
These sites feature additional methods teams use as they progress to more detailed planning and analysis:
- Architecture Methods from Itana
- Business Analysis Methods from the Business Analysis Community of Practice
- Project Documents from the UW-IT PMO
- User Experience Design Guides (UW)