By Paul Preiss, of Iasa Global
Most architects treat the context view as a technical artifact. Draw the system box. Add some arrows. Label the external systems. Done.
But a context view that isn’t anchored to the business model is just a box-and-line diagram. It describes what exists, not what matters.
The BTABoK Business Model concept defines a business model as “a plan for how a company will take advantage of its unique capabilities to respond to market conditions and provide value to a set of customers.” Every word of that definition has direct implications for how you design a context view. Here’s how it plays out.
The context view answers: What interacts with this system, and how?
The business model answers: Why does this system exist, who does it serve, and what makes it competitively significant?
Without the second question you can’t answer the first one well. You end up documenting every interface with equal weight — the compliance reporting API sitting alongside the core customer transaction flow, with no signal about which one matters architecturally. The BTABoK is explicit that the business model “points out clearly which processes, capabilities, and technologies define the company’s competitive position.” That classification is exactly the lens a context view needs.
Market type shapes who your customers and suppliers are — and that drives everything in the context view
The BTABoK identifies four market types: Classical, Adaptive, Shaping, and Visionary. The reason this matters for a context view isn’t a technical pattern — it’s that market type fundamentally determines who your customers are, how you relate to them, what kind of suppliers and partners you need, and therefore what external actors and interactions actually belong in the diagram.
In a Classical market — predictable, with high barriers to entry and long planning horizons — customers are known and stable. You have established procurement relationships with suppliers, formal contracts, and well-understood regulatory bodies. The context view reflects that: named customer account systems, supplier integration through procurement and ERP channels, compliance and regulatory actors that don’t change much year to year. The interactions are formal and durable.
An Adaptive market is a different world. Customers are volatile — their preferences shift quickly, their identities may not be well established until they arrive, and you’re often learning who they are in real time. Suppliers need to be interchangeable because no single partner can be a strategic dependency in a market that reshapes constantly. The technology interactions that show up in the context view shift accordingly: market sensing systems, analytics and feedback channels, social and community signals all become first-class actors. Customer identity is lighter. Supplier connections may look more like marketplace access than fixed bilateral integrations. If your context view for an adaptive-market business shows deep, static bilateral integrations with a handful of fixed partners and a clean, stable customer actor, that’s a signal your architecture doesn’t reflect the business reality.
A Shaping market changes the cast of characters again. You’re trying to build the market, not just serve it — which means customers and partners blur. Ecosystem participants, developers building on your platform, community members who co-create value, third parties whose involvement makes your offering more valuable to everyone — these are the actors that matter. The context view for a shaping-market company needs to show those open surfaces prominently: partner onboarding systems, developer APIs, marketplace platforms, ecosystem feedback loops. The supplier relationships often don’t exist yet in any traditional sense; you’re creating them.
A Visionary market is rare, but worth understanding: small early adopter groups, often proprietary supply chains because the broader market hasn’t formed, tightly controlled partner integrations. The context view is more contained but the external actors often include R&D relationships and pilot customer systems that wouldn’t appear at all in a mature business.
Now most large organizations are not sitting cleanly in one market type. A financial services firm might have a classical market in its core lending business and an adaptive market in its digital products division. A manufacturer might have classical supplier relationships and a shaping-market customer platform running in parallel. The context view doesn’t get to pretend that complexity away. What the market type analysis gives you is the ability to look at a context view and ask: which external actors reflect which market conditions, and are we treating them appropriately? Are we applying classical-market thinking to an adaptive-market customer relationship? Are we trying to own a supply chain that a shaping-market model would suggest we should open up?
Before drawing anything, understand what market conditions are actually driving the system you’re designing — and be honest when there’s more than one.
Business focus tells you what belongs in the center
The BTABoK identifies four business focuses: Product/Service, Customer, Technology, and Production Capacity. Each one tells you where to place the emphasis in the context view.
A customer-focused business lives and dies on customer intimacy, so the context view should foreground every customer-facing system and feedback channel — CRM, experience platforms, support systems. Those aren’t peripheral; they are the competitive core. A technology-focused business derives value from a unique technical capability, so the context view should show how that core platform is exposed and consumed. The external entities consuming the platform are the central story, not an afterthought. This maps directly to what we cover in the IASA Core course when we talk about the relationship between business capabilities and solution boundaries.
The anchor competitive necessity surfaces your architectural warnings
Every business anchors on one of four competitive necessities: Cost, Quality, Speed, or Service. A speed-anchored business whose context view shows batch-file transfers to critical partners has a problem worth surfacing immediately. A quality-anchored business that buries compliance and certification bodies at the edge of the diagram has misread its own architecture. The Context View canvas in the BTABoK has a Warnings section specifically for misalignments between architectural intent and design reality — the anchor competitive necessity is one of the most useful inputs for that section.
Customer segments and channels tell you who appears as actors
The Business Model Canvas explicitly links customer segments and channels to Customer Personas, Journey Maps, and Service Blueprints. Each of those translates directly into actors and systems in the context view.
Multi-sided platform models (marketplaces, exchanges) require the context view to represent multiple distinct user groups (buyers, sellers, third-party developers) each with their own integration surface. Drawing a single “User” actor in that context is an architectural failure mode. Indirect channels (resellers, API consumers, distribution partners) mean those partner systems become first-class actors. Self-service customer relationships demand robust external-facing APIs and identity systems; personal assistance models require CRM integrations and case management. Walk the Business Model Canvas segments and channels boxes before you populate your actor list. Every segment and channel should be traceable to something in the diagram.
Key partners and revenue streams tell you which integrations are architecturally critical
Key partners in the business model are the external entities the business cannot function without. They map directly to the most architecturally significant external systems in the context view — the ones where integration failure threatens the value proposition, not just a feature. The BTABoK Ecosystem article goes deeper on how to model those partner relationships.
Revenue streams tell you where money crosses the system boundary. Those interfaces deserve heightened attention: reliability, security, auditability, and contractual SLA compliance are all in play. A subscription model means your identity, entitlement, and billing integrations are architecturally critical. A usage-based model means your metering and reporting pipeline appears prominently. If a failure in an integration would directly impact revenue, that needs to be visible in the context view, not buried in a data flow document.
The business model as a filter, not a formula
One thing worth being direct about: nothing here is a clean one-to-one mapping, and it shouldn’t be. Large organizations have multiple market types running in parallel, multiple business focuses across product lines, customer segments that don’t behave uniformly, and supplier ecosystems that have evolved over decades. And they have hundreds of applications — sometimes thousands — sitting underneath whatever system you’re trying to describe.
That’s exactly why the business model matters as a tool for the context view. Not as a formula that mechanically produces the diagram, but as a filter for what deserves to be in it. A context view that tries to represent everything across a complex enterprise application landscape is useless. The business model tells you what to elevate and what belongs in a lower-level view. It tells you which external actors are strategically significant — because they sit on revenue streams, because they define how a customer segment is served, because they are load-bearing to the value proposition — and which are infrastructure that doesn’t need to surface at this level.
This also means the judgment gets harder, not easier, as organizations grow. A system that touches hundreds of other applications in an enterprise still needs a context view that’s comprehensible. Getting there requires the architect to have actually worked through the business model and made deliberate choices about what this system is for — not just catalogued what it connects to.
Validate the diagram back against the business model: do the most prominent actors reflect the business focus? Are the revenue-critical integrations visible? Where there are competing market conditions pulling in different directions — and in large organizations there usually are — is that tension acknowledged rather than papered over with a generic actor label?
The BTABoK puts it plainly: “The goal of architecture is to optimize the outcomes from technology impacts to the business model and the value it generates for customers and shareholders.” A context view that doesn’t connect to the business model can’t do that job. One that does is a different instrument entirely.
The Context View canvas and Business Model Canvas are both available in the BTABoK at btabok.iasaglobal.org. If you’re working through the IASA Core course, this is one of the most practical places those two workstreams converge.