Connect. Secure. Manage.
Network High-Level Design
Document the proposed network architecture, major technology choices, dependencies and risks so business and technical stakeholders can approve the approach.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
A network high-level design explains the architecture before the implementation detail takes over. MCI produces high-level designs for Cisco and Meraki environments that set out the intended topology, major technology choices, security boundaries and dependencies. The document gives technical and business stakeholders a common basis for deciding whether the proposed direction is right.
It should be detailed enough to expose important assumptions without becoming a collection of interface settings and configuration commands. Those belong in the low-level design. The high-level design answers the earlier questions: what are we building, why does it meet the requirement and what must be true for it to work?
A clear requirement
Turn the business need into a practical network scope with visible dependencies.
A controlled delivery
Plan implementation, testing and rollback before production changes begin.
A supportable result
Leave useful records, ownership and escalation routes behind.
Establish the requirements the design must satisfy
A useful design begins with an agreed problem statement. That may involve a new site, an estate-wide refresh, improved resilience or connectivity to a new application environment. The requirements should distinguish essential outcomes from preferences and future possibilities.
We record constraints that influence the architecture, including retained equipment, provider services, physical locations and the way the network will be managed. Where a requirement is unresolved, it remains visible rather than being silently answered by the designer.
This makes review more productive. Stakeholders can assess whether the architecture meets the stated need instead of debating technologies without a shared definition of success.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Describe the important components and their relationships
The high-level design shows the major network areas and the connections between them. Depending on the project, that can include office access, campus distribution, WAN connectivity, data-centre networks, cloud connections and external organisations.
The diagrams are supported by an explanation of the intended traffic paths and control points. A line between two boxes should have enough meaning to identify the service, boundary or dependency it represents. Otherwise, a visually tidy diagram can conceal decisions that will only emerge during implementation.
For Cisco and Meraki deployments, we explain the proposed role of each platform and the management arrangement. The design should not rely on a brand name to imply a particular feature set, resilience model or operational capability.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Make the architectural decisions reviewable
We record significant choices and their reasoning. Why is a routing boundary placed here? Why is this site pattern different from the others? Why is a particular management approach appropriate for the team that will operate it?
Alternatives do not need equal space when they are clearly unsuitable, but material trade-offs should be visible. Retaining an existing component may reduce immediate disruption while preserving a limitation. Introducing a new architecture may improve consistency but require additional skills and migration work.
Where the decision depends on uncertain behaviour, a proof of concept can provide evidence before the design is accepted. The high-level design should identify that dependency rather than presenting an untested assumption as a settled fact.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Include resilience, security and management at the right level
The document describes the failure scenarios the architecture is intended to accommodate and the broad behaviour expected when they occur. It also identifies shared dependencies that could affect apparently separate paths.
Security coverage includes the principal trust boundaries, management access and the intended placement of policy enforcement. This does not replace detailed rule design, but it establishes where those rules will operate and which relationships they need to control.
Management and support are part of the architecture. We identify the systems and access paths needed to administer the network, together with the division of responsibility between internal teams, MCI and third parties.
Connect the target design to delivery
A high-level design should acknowledge how the organisation can reach the target state. We outline major migration dependencies, likely phases and points where business or supplier participation is needed. A target diagram that assumes a clean start may be unsuitable for a live environment that must remain in service.
The deliverable also identifies what the next design stage must resolve. Low-level design translates the accepted architecture into implementable addressing, interfaces, policies and configuration standards.
Acceptance criteria are established at the service level. They provide the basis for later test plans without claiming that a design review is equivalent to testing the finished network.
High-level design questions
Is a high-level design necessary for a small project?
The size and form can be proportionate. A focused change may need a concise design note rather than a large document. The important point is that the architecture, assumptions and responsibilities are understood before implementation starts.
Can the document be used for procurement?
It can inform procurement by establishing platform roles, capacity requirements and dependencies. Detailed equipment quantities and exact configuration requirements may still need further design work. We make the intended use of the document clear in the scope.
Who should review it?
The network owner, relevant technical teams and the people responsible for business requirements should participate. Security, application and service-provider stakeholders may also need to confirm assumptions that the network team cannot validate alone.
Can you produce a design from an existing proposal?
Yes. We can develop the proposal into a reviewable architecture while identifying gaps or assumptions that need attention. Commission a network high-level design with a summary of the project and the decisions the document needs to support.
Talk to a specialist
What does your network need next?
Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.