Scoping a business service and mapping dependencies

Business protection begins by defining what must continue or remain trustworthy. A system label such as “order platform” is insufficient because the service can span the customer site, identity provider, price file, inventory, warehouse, payment, messaging and customer support. A specialist therefore defines a business service as an outcome delivered to a beneficiary under stated time and quality conditions. For example: accept a valid order, reserve the correct stock, pass a fulfilment instruction and notify the customer. This differs from a device inventory because it explains why an asset matters and how it contributes to the result.

Start with a seven-field scope card: service name and outcome, beneficiaries, transaction start and end, service owner, sensitive periods, acceptable interruption or error, and explicit inclusions and exclusions. The service owner must be able to explain priority and accept or escalate disruption impact, not merely know the application. If departments dispute ownership, record and escalate the conflict to the sponsor. Do not select a nominal owner merely to complete a field.

Map the value path next. List the steps that convert a beneficiary request into a result: receive, validate, decide, perform, record and notify. For each step ask: what data enters, which system or person processes it, what output is produced, what precedes and follows it, and what visible sign indicates failure? These questions reveal assets absent from technical inventories, such as a manually maintained price table, a service account or a supplier exchange file delivered at a fixed time.

Use six dependency categories so one type does not dominate: people and roles; data and records; applications and services; infrastructure and devices; identities, secrets and interfaces; and suppliers or external facilities. Give every dependency an owner, evidence source and relationship type. A relationship may mean “stops without,” “sends to,” “validates against,” or “temporary substitute.” Arrows matter because two entries in a list do not prove that failure of one interrupts the other.

State dependency direction. The order platform may depend on identity, while identity serves many other applications. That difference changes incident impact and recovery sequencing. Identify concentration points as well: one integration account, one cloud region, one person who knows a procedure, one messaging supplier or one copy of a cryptographic key. Concentration is not automatically a proven weakness; it is a high-priority test question.

Do not use confidentiality, integrity and availability as slogans. Test each dimension against the service outcome. Loss of confidentiality may expose customer information; loss of integrity may change a price or delivery address; loss of availability may stop order acceptance. Add authenticity and accountability when the business must know who acted, and add privacy or physical safety when the context requires them. The test identifies impact type; it does not invent a legal or financial value without competent ownership and evidence.

Describe disruption over time. In five minutes, orders may accumulate in a queue. In two hours, warehouses may miss a cut-off. In a day, revenue may be delayed and support contacts may rise. This curve is more useful than the word “critical.” Include seasonality: one hour during a quiet period differs from one hour during closing or a sales campaign. Record the timing assumption so a seasonal priority does not become a permanent ranking.

Validate the map in three ways. First, trace a successful transaction from start to finish and compare records with the arrows. Second, remove one dependency in a tabletop exercise: which step stops, what alternative exists and who performs it? Third, start from an incorrect output and trace backward to inputs that could cause it. Do not change a live system merely to test a diagram; use existing logs, an authorized environment or a tabletop exercise with process owners.

Distinguish evidence from assertion. “We have a backup” is an assertion. Design evidence shows where the backup is and how it should operate. Operating evidence shows that it was used or tested during a known period. If the last test predates an architecture change, the evidence is historical rather than current. Record date, scope and result for every check, and write “unverified” when material is insufficient instead of converting personal confidence into fact.

Map data through its lifecycle rather than one storage location. Show creation, transfer, use, sharing, retention and deletion. An order number may pass from sales to the warehouse and then the messaging supplier, while that supplier does not need the billing address. The map reveals data-minimization opportunities and responsibility boundaries. Include temporary copies, manual exports, test environments and support logs because they may carry the same data outside the official path.

Treat interfaces as first-class dependencies. Record interface name, both parties, authentication method, transferred data, timeout, retry behavior and failure detection. If the warehouse returns the same response twice, could two shipments be created? If the connection breaks after execution but before confirmation, how is duplicate execution prevented? These are business-security and resilience questions, not isolated programming details.

Map the manual operating path too. When automation fails, a team may use a spreadsheet, email or telephone. The manual alternative has capacity, error and authorization limits. State transactions per hour, approver, duplicate-prevention method and governing record. Do not call it a continuity plan until it has been exercised at representative volume and given a safe stop condition.

Review the map from four perspectives. The service owner confirms outcome and priority; the operator confirms steps and exceptions; technology confirms systems and interfaces; and supplier or contract evidence confirms external boundaries. Agreement does not guarantee completeness, but it reduces blindness from one viewpoint. Record an open disagreement, its decision owner and due date; a map that hides disagreement is visually cleaner and operationally weaker.

Version the map. Its header includes creation date, evidence period, reviewers and dependency state: confirmed, assumed or unverified. A new supplier, payment route or cloud-region move triggers a focused review of affected dependencies. Do not redraw everything without cause, and do not keep using an obsolete map because it is attractive and easy to present.

A reviewable output has an input and output for every step; a type, direction and owner for every dependency; a source for every assertion; a test or referral for every concentration point; and a reason for every exclusion, with linked dependencies where relevant. It also states the next decision, such as approving a messaging alternative or funding a recovery exercise. If the map changes no test, priority or responsibility, it remains descriptive documentation rather than completed specialist work.

Apply a completeness test to each dependency edge, not only each node. For every arrow, state the condition that makes the relationship true, the signal that reveals interruption, the available fallback, and who confirms that the relationship has recovered. If fulfilment orders are sent to a warehouse every five minutes, success in a test interface does not prove that the production batch arrived or was processed in sequence. Check batch identifier, record count, receipt time and rejection state, then reconcile a sample at both ends. Classify the dependency as synchronous, where the transaction stops immediately; asynchronous, where work accumulates; human, where response depends on recall time; or contractual, where organizational action is constrained. The class changes the decision window and fallback design. Also define the return point from manual to automated operation and the reconciliation that prevents duplicate or missing orders. A strong map therefore does more than draw arrows: it demonstrates how the team would notice each broken relationship, maintain the intended outcome for a bounded period, and restore normal operation without creating a second integrity problem. Record the evidence owner and review trigger beside the edge so a diagram cannot outlive the facts that made it valid.

A service-dependency workshop should produce more than agreement around a diagram. Prepare it from observable transactions. Select a normal request, a rejected request, a request crossing an external boundary, and one completed through fallback. Walk each from initiation to beneficiary-visible completion. At every hand-off, capture the message or record name, expected acknowledgement, timeout behaviour, retry ownership and reconciliation rule. This exposes silent dependencies that interviews miss: scheduled jobs, certificate renewal, address reference data, queue capacity, time synchronization and a person who releases held work. Mark whether the relationship carries data, trust, availability or decision authority. A data dependency can corrupt an outcome while all components remain available; a trust dependency can admit the wrong actor while processing continues.

Turn the map into a verification sheet. For every critical edge, nominate a non-destructive observation that proves ordinary operation, a symptom that signals failure, and a question that bounds impact. If the warehouse accepts batches, compare sent, accepted, rejected and pending totals for one controlled period. If a price file is authoritative, confirm version, effective time, checksum and consumer acknowledgement rather than merely its presence. If customer notification is delayed, decide whether fulfilment can continue and who owns reconciliation. These details let responders distinguish a stopped service from a degraded one and a data-integrity fault from a capacity fault.

Review the map at three levels. The service owner validates beneficiary result and tolerable degradation. Process owners validate sequence, cutoff and manual work. Technical owners validate interfaces, credentials and monitoring. Conflicts are not edited away: record the competing statements, evidence needed and authorized decision owner. Finish by simulating one dependency loss on paper. The team should identify the first visible symptom, accumulated work, safe duration, fallback entry, return-to-normal criteria and records needed to prevent duplicates. A map passes when another team can use it to ask and answer these operational questions without relying on the original author's memory.

Define the unit of analysis before drawing dependencies. A business service is a repeatable beneficiary outcome with a start, end and quality condition, not an application or department. For ordering, the unit begins with a valid request and ends with acceptance or a reasoned rejection. Exclude inventory browsing, management reporting and supplier testing unless they change that outcome. Assign the outcome owner, step owners and the person authorized to decide tolerable disruption. The technology owner may operate the platform without owning the decision to continue sales manually.

Map a value journey as events: receive the request, validate price, reserve stock, send fulfilment and notify the customer. For each event record input, output, actor, maximum elapsed time, success signal and rejection signal. This exposes dependencies missed by system lists, including a manually maintained price table, clock source, interface certificate, service identity, queue, fraud approval and warehouse link. Give the map a version and observation date so a once-correct picture does not silently become current truth.

Classify relationships as data, control, time or capacity dependencies. Data edges require integrity and reconciliation; control edges make allow-or-deny decisions and require identity and authority; time edges impose sequence or cutoff; capacity edges supply throughput or human knowledge. Two services may use the same application through different relationships. A reporting failure may not stop order entry, while a corrupt price can create wrong orders although every component is available. Record direction and type before assigning criticality.

Model disruption over time. Five minutes may create a replayable queue; two hours may miss warehouse cutoff; one day may create reconciliation conflict and customer demand. Use volumes provided by the process owner rather than invented loss values. State fallback capacity: a manual path might carry fifteen priority orders, not ordinary demand. That delays consequence rather than eliminating it. Include the return from fallback and the control preventing duplicate order entry.

Examine concentration and transitive dependency. A concentration point can be one supplier, cloud region, credential, reconciliation expert or cryptographic key. A supplier may itself rely on an unseen subprovider. Turn concentration into test questions: is there an alternative, when was it tested, how long does switching take, and does it share the same failure cause? Two instances in one region do not provide regional independence, and two accounts using one key do not remove a trust concentration.

Keep an unknowns register beside the map. State why each unknown matters, who can resolve it, due time and interim decision. Unknown queue retention must not appear as a confirmed two-hour value. Label facts with evidence, assumptions awaiting test, inferences bounded by facts, and decisions owned by authorized roles. Validate the map by combining interviews, records and documents: each reveals gaps the others miss. Trace an approved historical or synthetic transaction across interfaces; do not create production failure merely to prove an edge.

Close the scope card with inclusions, exclusions, environment, period, population, dependencies, owners, unknowns and review triggers. Interface release, supplier change, region move, incident discovery and material volume change each reopen it. The business owner validates outcome and consequence; technical owners validate relationship and evidence. A disagreement is recorded and escalated rather than silently decided by the specialist. The output passes when another team can interpret failure and sequence recovery without hidden oral knowledge.

Applied lab — a fictional disbursement service begins with an approved payment file and ends with success or a reasoned rejection. The team listed upload gateway, signature check, beneficiary file, rules engine, dual approval, bank interface and messaging. The specialist added a time source governing signature expiry and a service identity sending the batch. The bank interface was synchronous, messaging asynchronous, approval a control edge, and reconciliation expertise a human-capacity dependency. During bank outage, batches accumulate and cannot be resent before identifier reconciliation; the manual path supports only ten urgent batches. Unknown bank retention and key-owner recall time remained labelled as unknowns. A synthetic transaction reconciled identifier, time and rejection at both ends. A paper simulation showed messaging failure degraded notification without stopping disbursement. The service owner prioritized payment integrity over message speed and set map review triggers for certificate, bank and close-window change. The case shows that availability is not binary: the outcome can operate with degradation, stop, or complete incorrectly, and each state needs a different decision.

Guided case — a digital subscription service initially appears to be only the payment site. Tracing the outcome reveals catalog price, promotion, external payment, activation queue, messaging supplier and a service identity granting entitlement. The outcome is: a customer pays a valid request and receives the correct entitlement once with understandable notice. A prior delayed response caused duplicate payment, so transaction identity and idempotency are integrity dependencies. A synthetic request is reconciled across site, provider, queue and account. Delayed email is degradation because entitlement remains correct; failed activation is more severe because payment completes without access. Manual handling covers twenty cases against a peak of two hundred, so it delays rather than removes consequence. Queue retention and approval for bulk replay remain explicit unknowns. The business owner decides notification is a quality component but not the activation completion point, with review if it becomes contractual evidence.

A practical reading rule: start at the beneficiary outcome and walk backward through each edge. If you cannot name failure symptom, fallback or decision owner, the edge is only a label. A professional map explains its limits and update triggers.