Talon.One Enterprise System Context Diagram

Hello. In the previous lesson, you established RetailCo’s scope, ownership boundaries, assumptions, and quality attributes for a Talon.One implementation. That baseline now becomes a visual architectural artifact: a system-context diagram.

This lesson produces the highest-level C4 view for the capstone. It will show Talon.One, the RetailCo commerce capability, people, and every enterprise system that exchanges information or triggers a required lifecycle action. The aim is not a technical wiring diagram; it is a reviewable statement of scope, responsibility, and integration intent.

---

Set the level of abstraction

A system-context diagram answers a deceptively small set of questions:

• What system or capability is this diagram about?
• What is inside its boundary?
• Which people and external software systems interact with it?
• What does each relationship mean in business and data terms?

It does not show endpoints, queues, databases, SDKs, deployment zones, credentials, or a step-by-step checkout sequence. Those belong in the deployment and sequence diagrams that follow.

For this capstone, the system of interest is:

RetailCo Digital Commerce and Promotion Capability
The business capability through which customers shop, receive promotion decisions, redeem benefits, and complete orders.

Talon.One is external to that boundary because it is a SaaS platform operated separately from RetailCo’s commerce estate. This is the appropriate focal point for an architecture review concerned with RetailCo’s responsibilities: which data RetailCo sends, which returned effects it applies, and how it manages order reversals.

A vendor-oriented diagram could instead place Talon.One at the center and treat RetailCo as an external system. That would answer a different question. Do not combine both perspectives in one diagram.

A context diagram is deliberately a “zoomed-out map.” If RetailCo later changes an internal microservice or relocates an adapter, the context diagram should normally remain valid. The business capability and its system dependencies have not changed.

---

Treat Talon.One as one external software system

At this level, represent Talon.One as a single software system, not as separate boxes for the Rule Engine, Campaign Manager, coupon service, loyalty service, or APIs. Those are Talon.One capabilities, not separate enterprise systems RetailCo operates.

Its box should describe what it provides:

Talon.One
SaaS promotion and loyalty platform that evaluates campaign rules and manages Talon.One-owned campaign, coupon, referral, giveaway, and loyalty state.

The important interaction has two complementary meanings:

1. RetailCo submits the current customer, session, cart, and event information required to evaluate the applicable rules.
2. Talon.One returns effects, such as discounts, coupon status, loyalty changes, notifications, and fulfillment-relevant instructions, which RetailCo must process according to its effect-handling policy.

This is the core decisioning boundary: RetailCo supplies attributes and transaction context; Talon.One evaluates campaign configuration through its Rule Engine and returns effects. RetailCo should not couple its runtime integration to individual campaign names or reproduce campaign eligibility logic in its own services.

The other Talon.One interaction is administrative rather than checkout-critical. Campaign configuration, custom attributes, catalog data, and governed configuration promotion belong on a management path. They must not be confused with the high-load decisioning path.

That distinction should be visible in the context diagram through relationship labels:

Interaction path	RetailCo source	Talon.One capability	Appropriate purpose
Runtime decisioning	Digital Commerce and Promotion Capability	Integration API and Rule Engine	Cart evaluation, coupon application, loyalty redemption, checkout, cancellation, partial return
Campaign authoring	Promotion Operations	Campaign Manager	Campaign design, review, testing, and approval
Governed automation	Configuration Release Pipeline	Management API	Promotion of approved configuration, catalog synchronization, controlled administration

The diagram does not need to show authentication mechanics. It is enough to show that the runtime and management paths are distinct. Environment-specific credentials, outbound network controls, and secret rotation belong in the next deployment-level diagram.

---

Build the relationship inventory before drawing

The most reliable way to avoid an incomplete context diagram is to create a relationship inventory first. Each row represents a real information exchange or required business trigger, not merely a system that exists somewhere in the enterprise.

For RetailCo, the inventory follows directly from the scope baseline.

Person or system	Why it appears	What it exchanges with the capability	System-of-record implication
Customer	Initiates commerce journeys	Cart changes, promotion codes, loyalty redemption choices, order activity	The customer does not call Talon.One directly.
Customer Identity and CRM	Supplies trusted identity and permitted customer attributes	Stable profile identity, consent status, approved segmentation data	Identity and consent remain enterprise-owned.
Product Information Management	Supplies product facts used by commerce and promotions	Product identifiers, sellable-item attributes, catalog classification	Product catalog ownership remains enterprise-owned.
Talon.One	Makes promotion decisions and manages Talon.One state	Session context and events in; effects and status in response	Talon.One owns campaign evaluation and configured promotion state.
Promotion Operations	Authors and approves campaign behavior	Campaign definitions and operational review through Campaign Manager	Campaign governance has a named human owner.
Configuration Release Pipeline	Applies controlled configuration changes	Approved configuration and catalog synchronization through Management API	Production change control is automated and auditable.
Order Management System	Owns the durable order lifecycle	Confirmed orders, applied benefit records, cancellation and return events	The order remains RetailCo’s record of commercial truth.
Fulfillment and Entitlement Services	Delivers physical, digital, or service benefits	Fulfillment instructions derived from eligible Talon.One effects	Talon.One can decide a benefit; it does not fulfill it.
Customer Notification Service	Sends customer communications	Message requests derived from accepted, rejected, or notification effects	Notification delivery is owned outside Talon.One.

Two systems are intentionally not shown as direct Talon.One integrations in this reference architecture:

• Payment services influence the order lifecycle, but RetailCo’s Order Management System communicates the resulting payment failure, cancellation, or confirmation to the commerce capability.
• Inventory services affect whether items can be sold, but they are not a Talon.One decisioning dependency unless RetailCo explicitly sends inventory-derived attributes for a campaign requirement.

This is an important rule: “all interacting systems” does not mean “every system in the enterprise.” Include a system when it directly exchanges information with the system of interest, or when it emits or receives an event essential to an in-scope promotion, loyalty, order, or fulfillment lifecycle.

---

Produce the RetailCo system-context diagram

The following is the completed capstone context view. The central boundary contains only the business capability under review. It does not expose an internal promotion adapter, API gateway, database, or individual microservice.

Read the relationship labels carefully. They are the most important part of the diagram.

For example, the Commerce–Talon.One relationship does not say “uses Talon.One API.” That label is too weak for architecture review. The diagram states the major classes of information exchanged:

• RetailCo sends the current transaction context and lifecycle changes.
• Talon.One returns effects and state relevant to RetailCo’s next action.
• RetailCo remains responsible for safely applying, storing, fulfilling, notifying on, or reconciling those effects.

Likewise, the Order Management System does not call Talon.One directly in this design. It communicates lifecycle outcomes to the commerce capability, which is responsible for issuing the corresponding Talon.One session update. This preserves a clear integration boundary and prevents multiple enterprise systems from independently mutating the same Talon.One session.

---

Defend the boundary choices

A principal-level context diagram must survive the question, “Why is this box here, and why is that one absent?”

Why the adapter is not visible

The previous module introduced a promotion adapter that mediates between commerce services and Talon.One. It is intentionally not shown as a separate box here because it is an internal implementation element of RetailCo’s central capability.

Showing it at context level would tempt reviewers into questions that belong at a lower zoom level:

• Is it a standalone service, a library, or part of checkout?
• Does it use an SDK or direct HTTP?
• Does it persist applied effects?
• Where do retries, circuit breakers, and idempotency state live?

Those are essential questions, but they are container and deployment concerns. The next lesson will make the adapter visible in an environment-specific deployment-level integration diagram.

Why Campaign Manager is not a separate system

Campaign Manager is part of Talon.One. Promotion Operations is the distinct person or role interacting with it. The diagram therefore shows:

• a human actor, Promotion Operations;
• one external software system, Talon.One;
• a relationship explaining campaign authoring, testing, and approval.

Separating Campaign Manager and Rule Engine into external boxes would imply RetailCo has independent integration contracts with separately operated systems. That is not the intended architectural boundary.

Why the catalog has two relationships

Product Information Management serves two distinct purposes:

1. It supplies commerce with product data needed to sell and price cart items.
2. It supplies Talon.One with catalog and collection information needed for product targeting, bundles, or strikethrough pricing.

These are different contracts, often different synchronization schedules, and may be owned by different implementation teams. Showing both relationships makes the catalog dependency explicit without implying that Talon.One owns product data.

Why fulfillment and notification are separate

A Talon.One effect can authorize a commercial outcome, but it does not necessarily make that outcome happen. For example:

• A discount effect changes the commerce price calculation.
• A coupon effect produces an acceptance or rejection state for the customer interface.
• A loyalty effect changes a balance that Commerce displays.
• A fulfillment-relevant effect may require a warehouse, entitlement service, or customer-notification process.

Keeping fulfillment and notification visible prevents a common project failure: successfully evaluating a reward but never delivering it.

---

Review checklist for the artifact

Before presenting the diagram, verify these criteria.

Scope and correctness

• The title names the system of interest and its boundary.
• Talon.One is present as one external SaaS software system.
• Every in-scope enterprise dependency from the scope baseline is visible.
• Every relationship has a meaningful label describing exchanged information, an action, or a lifecycle trigger.
• The runtime Integration API path is distinct from the management and configuration path.
• Customers do not connect directly to Talon.One or receive Talon.One credentials.

Ownership and lifecycle

• Customer identity, consent, catalog, orders, and fulfillment remain assigned to their enterprise owners.
• Talon.One’s role is stated as campaign decisioning and Talon.One-managed promotional or loyalty state.
• Payment failure, cancellation, and partial return have a visible route back to the commerce capability.
• Fulfillment and communication effects have a receiving enterprise owner.

Appropriate abstraction

• No endpoints, HTTP methods, payload fields, database schemas, queues, cloud regions, or service classes appear.
• The internal promotion adapter is omitted from this context view.
• Unrelated enterprise systems are omitted, with their exclusion explainable from the scope baseline.
• The diagram is understandable to marketing, commerce, operations, and engineering stakeholders without a separate technical narrative.

---

Conclusion

A system-context diagram is the architectural contract for who participates in the Talon.One implementation and why. For RetailCo, the essential model is:

• Customers interact with the RetailCo commerce capability, never with Talon.One directly.
• Commerce submits complete transaction context to Talon.One through the Integration API and applies returned effects.
• Promotion Operations and the configuration release pipeline use Talon.One’s campaign-management capabilities on a distinct administrative path.
• Identity, product, order, fulfillment, and notification systems each retain their enterprise responsibility.
• Order failures, cancellations, and returns re-enter the promotion lifecycle through the commerce capability.

The next lesson will zoom in from this stable context view to a deployment-level integration diagram for sandbox and live environments, including the adapter, environment-specific Talon.One connectivity, secret management, and operational boundaries.