How Enterprise Architects Apply the Hohpe Methodology
For Enterprise architects and solution architects at large organizations · Based on Hohpe Architect Elevator Methodology
// TL;DR
Enterprise architects often get trapped in two failure modes: the ivory tower (producing landscape maps nobody uses) and the oracle bottleneck (becoming the single approval gate for all designs). The Hohpe Architect Elevator Methodology replaces both with a purpose-driven operating system. Operate as a scout, not a cartographer—investigate what's relevant to the current decision and return with a situational map. Use Common Framing to prevent binary debates across divisions. Ride the Architect Elevator to translate engine-room realities into penthouse-level strategy. Spend political capital deliberately on the decisions that actually matter, not on scattered skirmishes across the portfolio.
Why does traditional enterprise architecture fail in modern organizations?
Traditional enterprise architecture tries to maintain a perfect, comprehensive map of all IT systems—the cartographer approach. In fast-moving organizations, this map is outdated before it's finished. Teams ignore it because it doesn't answer their specific question, and the architecture team becomes an overhead function that produces artifacts nobody reads.
The Hohpe methodology replaces the cartographer with the scout. A scout has a specific objective, investigates only what is relevant to the current decision, and returns with a timely, purpose-driven map. This means your first action is always Step 1: define the question before seeking the answer. Without a question, your architecture diagram is modern art—boxes and triangles that don't drive any decision.
How do you apply purpose-driven mapping across a large portfolio?
Stop trying to maintain a single source of truth for the entire landscape. Instead, treat each significant decision as a mapping mission:
1. Define the question (Step 1): "Should we consolidate payment processing into a shared platform, or let each business unit maintain their own?"
2. Map only what matters (Step 2): Create a Common Framing that captures the relevant dimensions—in this case, perhaps data sovereignty requirements vs. operational cost of duplication. Don't map the entire payment landscape; map the dimensions that inform this specific decision.
3. Identify inherent complexity (Step 3): Regulatory requirements across jurisdictions may make consolidation genuinely complex—this is inherent, not invented. Name it explicitly.
4. Surface hidden assumptions (Step 5): Does the consolidation proposal assume all business units have the same SLA requirements? The same transaction volumes? The same compliance regimes?
Each mission produces a decision artifact, not a landscape artifact. Over time, these decision artifacts accumulate into a richer understanding of the landscape—but the understanding is grounded in real decisions, not in abstract completeness.
How do you handle the political dynamics of cross-division architecture?
Enterprise architects face uniquely complex political dynamics: multiple business units, competing priorities, leaders who protect their budgets and headcount. The Hohpe methodology addresses this through two concepts:
The jester's trust: You can tell hard truths precisely because you have no hidden agenda. You don't own a budget, a team, or a product. Use this position deliberately. When you call out a Wily Coyote situation—a project that has run off the cliff but hasn't looked down—your credibility rests on the fact that you gain nothing from the call except organizational health.
Political capital management: Earn trust through consistent delivery, transparency, and fairness. Then spend it deliberately on the single highest-stakes decision. If you challenge every division's architecture choices, you become the grumpy auditor nobody invites to meetings. If you focus your credibility on the one cross-cutting decision that genuinely matters—say, the platform consolidation that will save $20M annually—your intervention carries weight.
How do you ride the Architect Elevator at the enterprise level?
The enterprise architect's version of the Architect Elevator ride is particularly challenging because the distance between the engine room and the penthouse is greater. You might be translating a Kubernetes cluster topology decision into a board-level risk discussion.
Apply Step 7 rigorously: construct a named model ("The Integration Maturity Ladder," "The Platform Consolidation Quadrant") that tells the story in one glance. Ensure you can defend every element technically when a CTO probes. Prepare for executive questions that test your thought process, not your technical acumen: "What alternatives did you consider? What does success look like in 18 months? Could we defer this decision by six months without material risk?"
The catchy visual and the technical foundation must live in one head. If you hand the model to a graphic designer and keep the logic in a separate document, the presentation will crack under probing.
What's your next step?
Pick one active decision in your portfolio where teams are stuck or where you've been asked for a 'landscape view.' Reframe it as a scout mission: define the specific question, map only the relevant dimensions, and produce a purpose-driven decision artifact instead of a comprehensive landscape diagram. Notice how much faster the decision moves when the map is built for a purpose.
// FREQUENTLY ASKED QUESTIONS
How do I stop being an ivory-tower enterprise architect?
Switch from cartographer mode to scout mode. Stop maintaining comprehensive landscape maps and start defining specific questions before each investigation. Produce decision artifacts, not landscape artifacts. Spend time in the engine room with teams, using the Phantom Sketch Artist technique to understand their actual systems rather than relying on documentation that's already outdated. Your value comes from purpose-driven, timely insight—not from completeness.
How do I handle architecture governance without becoming a bottleneck?
Replace approval gates with Common Framing sessions. Instead of reviewing every design after the fact, equip teams with shared decision frameworks—2×2 matrices, named trade-off dimensions, explicit statements of inherent complexity—so they can make suitable decisions independently. Reserve your direct involvement for high-stakes, cross-cutting decisions where political capital and elevator rides are needed. The goal is team capability, not architect dependency.
How do I measure the impact of enterprise architecture work?
Measure decisions, not artifacts. Track how many stalled debates you resolved, how many conscious trade-offs teams documented, and how many executive decisions were informed by your Architect Elevator pitches. The rubber ducky signal is also a metric: if teams increasingly seek you as a sounding board and solve their own problems after brief conversations, your amplifier model is working. Avoid measuring diagram count or review throughput—those incentivize the cartographer anti-pattern.