Enterprise networks are designed, not assembled. This unit walks the full top-down lifecycle. Today we are at the very start: understanding why the network exists before deciding what it should be built from.
D — Turning goals + constraints into a design brief
By the end you should be able to
Elicit and prioritise an organisation's business goals
Identify budget, staffing, scheduling, political and compliance constraints
Recognise and document conflicting requirements
Produce the "Business Goals & Constraints" section of a design report
Maps to Unit Learning Outcomes 1 (analyse requirements) and 2 (justify trade-offs).
A.1
A.1 Top-down vs bottom-up network design
Definition
Top-down design begins at the upper layers of the OSI model — the organisation, its applications and data flows — and works downward to protocols, devices and cabling. Technology choices are the last decision, not the first.
Why top-down wins for enterprises
The design is traceable to business goals — every device exists for a reason you can justify.
It anticipates growth and change, because scope and applications are understood up front.
It mirrors mature structured design (requirements → architecture → detail), the same discipline used in software engineering.
The bottom-up trap
Picking devices first ("buy three of these switches") is fast but blind — it produces networks that miss real requirements, don't scale, and get re-worked. Cost of change grows sharply the later a gap is found.
A.2
A.2 The network design lifecycle
Industry frameworks (e.g. Cisco's PPDIOO) treat a network as a living system with a repeating lifecycle. Requirements analysis lives in Prepare / Plan / Design — get it wrong here and every later phase inherits the error.
Key point
Oppenheimer's top-down method sits inside the Plan → Design band and unfolds as: analyse requirements → develop a logical design → develop a physical design → test, optimise and document. Today is step one of step one.
A.3
A.3 Why business goals come first
A network is a means, not an end
The organisation is not paying for switches and fibre — it is paying for outcomes: faster service, lower cost, new markets, safer data. A technically beautiful network that doesn't advance those outcomes has failed the customer.
Example
A retailer's "goal" is not 10 Gbps to every store. It is zero downtime during the Boxing Day sale. The bandwidth figure is a design decision that must be derived from that goal — never assumed.
Requirements almost always conflict
You will rarely get "cheap, fast, secure, and delivered next month" all at once. Naming the goals early lets you make justified trade-offs instead of accidental ones.
Cost ↔ Performance
Security ↔ Usability & cost
Time-to-deploy ↔ Completeness
Availability ↔ Budget
This is examinable thinking
Learning Outcome 2 asks you to justify choices when requirements conflict. That justification is only possible if the business goals were captured and ranked first.
Part B
Analysing Business Goals
What is the organisation trying to achieve, and how do we surface it? Scope → stakeholders → goals → applications.
B.1
B.1 Scoping the project & its stakeholders
Fix the scope before anything else
Ambiguous scope is the single biggest source of project blow-out. Pin down how much network you are designing:
Scope axis
Question to answer
Size
One segment? A building? A campus? A national WAN? The whole enterprise?
State
Greenfield (new build) or brownfield (modify a live network)?
Type
Expansion, redesign, new service, cloud migration, or merger integration?
Know who is in the room
Requirements come from people with different — sometimes competing — interests. Identify them and, critically, who signs off.
A stakeholder is anyone who affects, or is affected by, the network. The decision-maker (budget holder) is the stakeholder whose priorities break ties.
B.2
B.2 Typical business goals
Most enterprise goals cluster into a handful of recurring themes. Use this as a prompting checklist in stakeholder interviews — then rank them, because they can't all be "top priority".
Goal
What it usually implies for the network
Increase revenue & competitiveness
New digital services, faster launches, reach new markets/regions
Segmentation, monitoring, auditable controls, data residency
Improve business continuity
Redundancy, failover, backup connectivity, DR sites
Support growth
Scalable addressing & topology, headroom for new sites/users
Modernise / migrate to cloud
Hybrid connectivity, elastic capacity, integration with SaaS
Key point
A goal is only useful once it is specific and prioritised. "Better security" is a slogan; "meet APRA CPS 234 audit by June, ranked above cost" is a requirement.
B.3
B.3 Applications & business criticality
The network exists to carry applications. Inventory them early: each one imposes different demands on bandwidth, latency, availability and security that will shape the design later.
For every business application, capture:
Who uses it and from where (on-site, remote, partner)
How critical it is to the business if it stops
Growth — users and data expected over the design's life
Any special traffic profile (real-time voice/video, bulk backup, telemetry)
Example
VoIP and video conferencing tolerate almost no jitter → they will later demand QoS. Overnight backups are huge but delay-tolerant → they can be scheduled off-peak. Same network, opposite requirements.
Criticality tiers
Tier
Meaning
Mission-critical
Outage stops the business (e.g. patient records, payments)
Important
Painful but survivable for hours (e.g. email, CRM)
Tiering drives later decisions on redundancy, QoS and where to spend the budget.
A–B ✓
Knowledge Check — Sections A & B
Q1. A client says "we need 10 Gbps links between all offices." In top-down design, how should you treat this?
A bandwidth figure is a design decision, not a business goal. Top-down design derives such figures from goals (e.g. "no downtime during peak sales"). The stated number may be wrong, too much, or too little.
Q2. Why is capturing and ranking business goals a prerequisite for Learning Outcome 2 (justifying trade-offs)?
Requirements routinely conflict (cost vs security vs time). A justified trade-off is impossible unless you first know the relative priority of the goals those requirements serve.
Part C
Analysing Business Constraints
Goals tell you what to aim for. Constraints tell you what the real world will actually allow. Budget · staffing · schedule · politics · compliance.
C.1
C.1 Budget & staffing
Budget: capex vs opex
Definition
Capex — one-off capital spend on hardware, cabling, licences you own. Opex — ongoing operational spend: subscriptions, cloud usage, support, salaries, power.
Cloud and managed services deliberately shift spend from capex → opex. Which model the business prefers is itself a constraint that steers the whole architecture.
Budget sets the feasible technology tier — it quietly rules options in or out before design begins.
Staffing & skills
A design the in-house team cannot operate is a liability, not an asset. Ask:
What technologies does the current team actually know?
Is there capacity to run something more complex 24/7?
Will you need training, hiring, outsourcing, or a managed service?
Common student mistake
Proposing bleeding-edge, hard-to-manage technology for an organisation with two overstretched IT staff. Supportability is a requirement.
C.2
C.2 Scheduling & timing
Deadlines are hard constraints
Timelines are often fixed by events outside the network project:
A new office or clinic opening on a set date
A product launch or trading season
End of a lease, contract, or hardware support window
A regulatory compliance deadline
Include real-world procurement lead times — hardware, circuits and carrier provisioning can take weeks or months.
How the schedule shapes design
Example
A tight deadline may force a phased rollout (core sites first, branches later) rather than a big-bang cut-over — which in turn affects addressing, redundancy and migration strategy.
Key point
Respect the business calendar: never schedule a risky cut-over during the organisation's busiest period (e.g. a retailer in December, a university at enrolment).
C.3
C.3 Politics, policies & preferences
The most under-estimated constraints are human. A technically superior design can still be rejected for reasons that have nothing to do with engineering.
Organisational politics
Hidden agendas & turf between departments
Who really holds decision power vs the org chart
History of past project failures shaping trust
Technical biases
Vendor loyalty ("we're a single-vendor shop")
Strong on-prem vs cloud preferences
Aversion to open source, or to a specific OS
Existing policies
Approved-vendor / procurement rules
Security & acceptable-use policies
Naming, addressing & architecture standards
Design implication
Surface these early and design within them, or negotiate them explicitly. Ignoring a "no public cloud for customer data" policy will sink an otherwise sound design at sign-off.
C.4
C.4 Compliance, regulation & data sovereignty
Legal and regulatory obligations are non-negotiable constraints — and they bite hardest in the cloud era, which is exactly why this unit pairs "enterprise" with "cloud".
Regime (AU context)
Constraint it imposes
Privacy Act 1988 & APPs
How personal data is handled, stored, disclosed
Health (e.g. My Health Records)
Strict controls on patient data confidentiality
Finance (APRA CPS 234, PCI-DSS)
Auditable security controls; cardholder data isolation
Definition
Data sovereignty / residency — the requirement that certain data physically reside within a jurisdiction. Some government and health data must stay onshore, directly constraining which cloud regions you may use.
Cloud reality
A public-cloud design that stores regulated data offshore may be illegal regardless of how well it performs. Location is a first-class design constraint.
C ✓
Knowledge Check — Section C
Q1. An organisation prefers a subscription model with no large upfront hardware purchase. This preference primarily expresses a constraint about…
Avoiding large upfront capital spend in favour of ongoing subscription cost is a capex→opex preference, which steers the design toward cloud/managed-service options.
Q2. A hospital rules out a public-cloud solution for patient records. Best classification of this constraint?
The restriction stems from confidentiality obligations and data-sovereignty concerns over sensitive health data — a compliance/policy constraint, not a performance one. It must be honoured in the design.
D.1
D.1 Worked example — extracting goals & constraints
Scenario — "Northlake Medical Group"
A chain of clinics is expanding from 3 to 8 sites across several cities within 18 months. Specialist rooms will run networked monitoring devices that stream patient telemetry. Head office wants tighter cost control and faster onboarding of new clinics. The board insists patient records stay tightly controlled and will not sit in public cloud. Each clinic has only one part-time IT contact.
Read the brief once for goals (what they want) and again for constraints (what limits you).
Business goals
Support growth to 8 sites (scalable topology/addressing)
Carry medical telemetry reliably (availability + QoS later)
Reduce cost & speed up new-clinic onboarding
Business constraints
Compliance/policy: no public cloud for patient records
Schedule: 18-month, site-by-site rollout
Staffing: thin on-site IT → must be simple to operate
Notice the tension
"Reduce cost" (favours cloud) collides head-on with "no public cloud for records" — a conflict we must resolve and justify next.
D.2
D.2 Managing conflicting requirements
When goals collide, don't guess. Make the trade-off explicit, weighted and signed-off. A weighted decision matrix scores each option against prioritised criteria:
$$\text{Score} = \sum_{i=1}^{n} w_i \, s_i$$
where \(w_i\) is the agreed weight of criterion \(i\), \(s_i\) is how well the option satisfies it, and higher total wins. The weights encode the business priorities you captured in Part B.
Deliverable
Record each decision as: the conflict, the options, the weighted rationale, and who approved it. That record is your justification for Learning Outcome 2.
D.3
D.3 The business-requirements checklist
Before you leave the requirements phase, you should be able to tick every box below. This maps directly onto the "Business Goals & Constraints" section of your design report.
Goals side
Researched the organisation's industry & competitors
Documented the corporate structure & direction (growth, mergers)
Fixed the scope (size, greenfield/brownfield, type)
Captured business goals — specific and ranked
Inventoried applications with users, criticality & growth
Identified stakeholders and the decision-maker
Constraints side
Budget envelope and capex/opex preference
Staffing skills & supportability limits
Schedule, deadlines & procurement lead times
Political dynamics & technical biases
Existing policies & standards to design within
Compliance obligations & data-residency rules
Gate
Every gap here is a risk you carry into logical and physical design. Close them now, while a fix is a conversation — not a re-build.
Wrap-up
Summary & link to your assessment
What to take away
Top-down: business and applications first, technology last.
Requirements analysis sits at the front of the lifecycle — errors here are the most expensive of all.
Goals = what the organisation wants, made specific and ranked.
Conflicts are resolved by weighted, documented trade-offs — not by guesswork.
Straight into Assessment 1
Today's method produces the "Design Requirements → Business Goals and Constraints" section your written assessment requires. Practise it on the tutorial scenario this week.
Next week
Analysing Technical Goals & Tradeoffs — scalability, availability, performance, security, manageability, usability, adaptability and affordability: converting business intent into measurable technical targets.
COIT20264 Enterprise and Cloud Networking · Week 2 · Press T for contents.