Playing to Win for Enterprise Architects
Roger Martin and A.G. Lafley's strategy framework — Playing to Win — was designed for business leaders making market choices. Its five questions form a cascade: from a winning aspiration down through where to play, how to win, what capabilities are required, and what management systems will sustain the strategy.
Enterprise architects work at a different level of the organisation, but the cascade applies with surprising precision. EA is, at its core, a practice of making choices about what the IT estate will and will not support, and ensuring that those choices are traceable to an organisational intention. The Playing to Win hierarchy gives that practice a grammar.
The cascade, layer by layer
Winning aspiration is the top of the hierarchy. It answers the question: what does success look like, and for whom? For a business, this might be a market position — becoming the preferred supplier in a specific segment, or building a reputation for operational efficiency that competitors cannot match.
For an EA function, the winning aspiration is not technical. It is organisational. A useful formulation might be: "The IT estate reliably enables our strategic priorities with predictable cost and low friction." Or more concretely: "Within three years, every investment decision in the IT portfolio is traceable to a business capability that supports an active strategic theme." The precise formulation matters less than the act of formulating it at all. Without a clear aspiration, the EA function defaults to reactive management — responding to requests rather than shaping direction.
Where to play defines the boundaries of the strategy. In market terms, it answers: which customers, which geographies, which channels? In EA terms, it answers: which domains, which capabilities, which levels of the architecture will we actively shape, and which will we leave to teams to figure out on their own?
This is a harder question than it sounds. EA functions that try to govern everything govern nothing well. The organisations that get the most value from their EA practice are usually those that have made explicit choices about where to focus — on strategic capabilities, on cross-functional integration points, on the domains where technical decisions have the highest business consequence. Where to play is also a statement about what EA will not do. Maintaining a long tail of low-stakes governance obligations at the expense of strategic focus is a common pattern, and it is rarely a good trade.
How to win defines the distinctive move. In business strategy, this is the combination of advantages — cost, quality, relationship, network effect — that makes the chosen where-to-play tenable. For EA, how to win is about the mechanism through which architectural decisions get made and embedded in organisational behaviour.
This might be a strong architecture review process that is fast enough to actually be used. It might be a capability framework that business leaders have contributed to and therefore reference. It might be a portfolio scoring approach that gives IT leaders a credible basis for prioritisation conversations with the business. Whatever the mechanism, how to win requires that it be genuinely distinctive — not just a formal process, but one that creates value that the organisation would notice if it disappeared.
Capabilities required is where the cascade moves from the strategic to the operational. A business strategy needs marketing, product development, and customer operations to function. An EA strategy needs its own capability set.
This is where the concept of an EA capability map becomes useful in a recursive way. The EA function has capabilities of its own: the ability to translate strategy into architecture, to maintain a current and accurate view of the application landscape, to run decision-support processes that are trusted by stakeholders, to communicate architectural choices in language that non-architects can engage with. Most EA functions have strengths in some of these areas and significant gaps in others. Making the gaps explicit — rather than assuming that good architecture work will naturally produce good outcomes — is the difference between a functioning capability system and a wishful one.
Management systems is the final level. These are the structures that sustain the strategy over time: governance processes, decision rights, review cadences, feedback mechanisms. Without them, even a well-designed strategy decays. People revert to defaults, exceptions accumulate, and the aspiration at the top of the cascade becomes disconnected from the day-to-day decisions at the bottom.
For EA, management systems include the rhythms that keep the portfolio current — regular review cycles, mandatory architecture touchpoints for significant investments, a decision log that captures not just decisions but their rationale. The Architecture Decision Record (ADR) is, in Playing to Win terms, a management system artefact. It captures the "how to win" logic at the level of individual decisions, and it creates the organisational memory that allows a team to reason consistently over time.
Capability maps as the capabilities level
The Playing to Win framework treats capabilities as the layer between strategic intent and operational activity. For EA, the capability map occupies this position.
A well-constructed capability map is neither a process diagram nor an application inventory. It is a stable description of what the organisation needs to be able to do — expressed at a level that is meaningful to both business and IT leaders. Capabilities do not change every time a system is replaced or a process is redesigned. That stability is what makes them useful as a connection point between strategy and architecture.
When strategic themes are mapped to capabilities — "our growth strategy depends on customer onboarding, pricing management, and channel management capabilities" — the architecture conversation can be grounded in something that business leaders recognise. The question is no longer "should we invest in this system" but "does this investment strengthen a capability that our strategy requires?"
This framing also makes gaps visible in a way that system-level analysis does not. An organisation may have twenty applications and still have a significant gap in a strategically important capability — because the applications exist but do not connect, or because they support the capability at a low maturity level. Capability mapping surfaces these gaps. The Playing to Win framework provides the context for deciding which gaps matter most.
ADRs as management systems
Architecture Decision Records are typically described as documentation artefacts — a way to capture the rationale behind significant technical choices so that future teams can understand why things are the way they are.
In Playing to Win terms, they are more than that. They are the mechanism through which the "how to win" logic is operationalised at the level of individual decisions. Each ADR that captures a technology choice — a platform selection, an integration pattern, a data model — is also an implicit statement about what the EA strategy values and how trade-offs are resolved.
Over time, a well-maintained ADR log reveals the implicit strategy of an IT estate — the consistent pattern of choices that either cohere into a recognisable approach or fragment into contradictions. Reviewing the ADR log is one of the fastest ways to diagnose whether the management systems of the EA function are actually sustaining the strategy, or whether the strategy exists only on paper.
The ADR as a management system also has an underappreciated organisational function: it externalises architectural reasoning. When a decision and its rationale are documented, future decision-makers can engage with the logic rather than having to reconstruct it. This reduces the dependency on individual expertise and makes the EA function more resilient to turnover.
The practical implication
The Playing to Win cascade is useful not as a one-time planning exercise but as a recurring diagnostic. Once a year, or whenever strategic context shifts significantly, it is worth running through the five layers and asking: is the aspiration still accurate? Are the where-to-play choices still appropriate? Is the how-to-win logic still valid, or has the environment changed? Are the capabilities adequate? Are the management systems working?
Most EA functions that struggle do not struggle because of technical complexity. They struggle because the strategy cascade has broken down at one or more layers — the aspiration is vague, the where-to-play is too broad, the management systems are inconsistent. The framework makes those gaps visible.
Playing to Win was not designed for EA. But it fits — because EA is ultimately a strategic practice, and like all strategic practices, it needs a coherent hierarchy of choices that cascade from aspiration to execution.
Atlas provides the tooling layer for the capabilities and management systems levels of this cascade — capability maps, portfolio decisions, and ADR tracking in one view. Try Atlas →