Business Strategy Design
What this lens evaluates
Whether the design serves the business - its priorities, risk appetite, economics, and obligations - before any technology is chosen. The Practical brief leads with business intent; this lens is how you convert that intent into requirements and constraints that bound every later decision.
The questions it forces
- What business priorities (growth, cost reduction, time-to-market, compliance, M&A) drive this, and how do they become network requirements?
- What is the business-continuity need - RPO/RTO, DR posture, acceptable downtime?
- What is the budget shape - CapEx vs OpEx, buy vs rent?
- Any mergers / acquisitions / divestitures? (overlapping addressing, policy reconciliation, integration timeline)
- Which regulatory / governance / sovereignty rules are hard constraints?
Core considerations
Business continuity & resiliency (realised in Network Design); M&A integration - overlapping addressing handled with Generic routing and addressing - PBR, NAT, RIB-FIB and Route aggregation and summarization, plus policy reconciliation and phased Reference models and migration considerations; compliance/governance as non-negotiables (Security Design); and cost/ROI/TCO. The exam rewards traceability - every major decision tied back to a business driver.
On the divest side the test is completeness per survivor: after the split, each resulting architecture must independently deliver every service its business needs - walk the shared-service inventory (route reflectors, ASNs, route targets and distinguishers, QoS policy, TE tunnels, DNS/NTP/AAA) and assign or duplicate each one, because anything left behind in the other half is an outage on day one.
The AI/ML angle (Exam Topics 1.4)
AI brings specific business concerns: data sovereignty, security, assurance & integrity, AI's storage/traffic impact, auto-scalability, and cost & ROI (GPUs dominate TCO). See Service placement - on-prem, cloud, hybrid, distributed, Data sovereignty and data gravity, Regulations, governance, and AI security policy, and Cost, ROI, and scalability of AI infrastructure.
Requirements, constraints, and "Why?"
Translate intent into the three constraint categories the exam uses - functional, technical, and application - and surface the unstated requirements (availability, security, and manageability are almost always assumed but rarely written down). The fastest way to expose a real requirement is to keep asking "Why?" until you reach the business driver behind a stated ask, then design to that driver rather than the surface request. And when goals conflict - availability vs cost, security vs usability, scalability vs stability - force an explicit weighting from the stakeholder (classic technique: distribute 100 points across the goals); the ranking, not the wish-list, is what a defensible answer cites when it knowingly sacrifices one goal for another.
Project management methodologies
The blueprint expects you to factor the customer's delivery methodology into the design and its rollout. The trade is structure/predictability versus adaptability:
| Aspect | Waterfall | Agile / Scrum | Kanban |
|---|---|---|---|
| Structure & docs | Highly structured, documented per phase | Loosely structured, light docs | Structured, flow-based, WIP-limited |
| Requirements | Fixed up front; end state defined early | Emerge throughout; end state evolves | Emerge throughout |
| Change | Change-adverse | Welcomed each iteration | Easy to slot in |
| Delivery & schedule | Delivered late; completion easy to schedule | Faster, iterative; completion hard to predict | Fastest flow; time not tracked |
Design implication: Waterfall suits stable, compliance-heavy, fully-specified builds (a large migration with a fixed cutover); Agile/Scrum/Kanban suit evolving requirements and phased rollouts (incremental fabric build-out, automation pipelines). Match the design's delivery plan to the methodology the customer actually runs.
Alongside these, Lean (born as the Toyota Production System) contributes the triad the others inherit: eliminate waste (anything not adding value to the deliverable goes), just-in-time (do not build ahead of need), and continuous improvement - and its historical line runs straight into Agile. In a design engagement, Lean is the vocabulary for stripping process waste out of a rollout plan: fewer handoffs, no speculative pre-builds, a feedback loop after each phase.
Characterizing requirements: existing network and traffic
Requirements analysis is not only interviews - you must characterise what already exists before designing on top of it. For a brownfield network, build a performance baseline (utilisation, errors, response time, availability) and run it against a network-health check, so you know normal behaviour, can later prove the new design improved it, and can rule options out early when a link or segment is already near saturation. You also characterise the traffic: estimate load and classify each application by flow type - terminal/host (asymmetric, thin-client-like), client/server (the common case - small requests, larger responses, e.g. HTTP/SMB/NFS), peer-to-peer (roughly symmetric, no central server), server/server (replication, backup, directory sync), and distributed-computing (compute nodes plus a manager - the pattern an AI/ML cluster's collectives push to the extreme, see Parallelism strategies and collective traffic patterns). Each flow's direction and symmetry drive capacity and QoS, so characterising flows is what turns a vague "we need more bandwidth" into a sized, justifiable design.
How it shows up in a scenario
The opening pages set context ("expanding to a new region under residency law", "merging two networks", "cut opex"). Extract drivers and constraints first - they often pre-decide options (sovereignty -> on-prem/in-region; opex pressure -> cloud/rent).
Tip: Scenario reflex
Prefer the least-disruptive option that meets the requirement - the CCDE-correct answer is often the minimum change, not the strongest technology (e.g., "absorb the price uplift and research alternatives in parallel" can beat a rip-and-replace). Weigh risk/reward and the customer's appetite for change; maintaining the status quo is a legitimate recommendation when nothing in the brief forces a change.
Spaced repetition
Why is the strongest technical option often the wrong CCDE answer?
The exam rewards the least-disruptive option that still meets the requirement - weigh risk/reward and the customer's appetite for change; status quo can be the optimal recommendation.
What does the Business Strategy lens require of every design decision?
Traceability back to a business driver (priority, risk, cost, compliance, M&A) - business intent precedes technology.
The classic network problems in an M&A scenario are [...].
The classic network problems in an M&A scenario are overlapping addressing (NAT/renumber), policy reconciliation, and phased integration/migration.
The AI/ML business-strategy concerns (Exam Topics 1.4) include [...].
The AI/ML business-strategy concerns (Exam Topics 1.4) include data sovereignty, security/assurance/integrity, AI traffic & storage impact, auto-scalability, and cost & ROI/governance.
The three CCDE constraint categories are [...]; the usually-unstated ones are [...].
The three CCDE constraint categories are functional, technical, and application; the usually-unstated ones are availability, security, and manageability.
Waterfall vs Agile/Scrum/Kanban - when does each fit a design rollout?
Waterfall for stable, fully-specified, compliance-heavy builds with a fixed cutover; Agile/Scrum/Kanban for evolving requirements and phased/incremental rollouts.
Why characterise the existing network and its traffic before designing?
To baseline normal performance (utilisation/errors/response time) so you can prove the new design improved it and rule out options early (e.g. a saturated link), and to size capacity/QoS from real load rather than guesswork.
Name the five traffic-flow types used to characterise applications.
Terminal/host (asymmetric), client/server (small request, larger response), peer-to-peer (symmetric, no server), server/server (replication/backup/sync), and distributed-computing (compute nodes + manager - the AI/ML collective pattern). Each flow's direction and symmetry drive capacity and QoS.
When stated goals conflict, a defensible design answer cites an explicit [...] of the goals (e.g., 100 points distributed) - not the unranked wish-list - as the basis for what it sacrifices.
When stated goals conflict, a defensible design answer cites an explicit stakeholder weighting of the goals (e.g., 100 points distributed) - not the unranked wish-list - as the basis for what it sacrifices.
Lean's triad - [...] - fed directly into Agile; invoke it to strip process waste from a rollout plan.
Lean's triad - eliminate waste, just-in-time, continuous improvement - fed directly into Agile; invoke it to strip process waste from a rollout plan.
Sources
- Z. Zsiga, Non-Technical Guide to the CCDE Practical v1.4 (Zigbits, 2020) - divest completeness rule; full pass 2026-07-26.
- Cisco Press, CCNA DevNet Associate DEVASC 200-901 OCG - Lean (Toyota Production System) and the Lean -> Agile lineage.
- Cisco CCDE v3.1 Unified Exam Topics (Domain 1).
- Cisco Press, Top-Down Network Design (Oppenheimer).