Is an application defined network necessarily a separate physical network?

No. It may use logical separation or software-controlled policies over shared physical infrastructure.

Does it always use AI?

No. Rules, policies and ordinary optimization can connect application requirements to network controls. AI is an optional implementation choice, not part of the term's definition.

Does ADN mean application delivery network?

It can in other material. That phrase commonly concerns delivering applications to users. Confirm the expansion and intended architecture before comparing claims.

AI Glossary / Data engineering and architecture / Intermediate

Application Defined Network

Definition

An application defined network is a networking approach in which application requirements help determine connectivity, traffic handling and related controls. The term has been used for application-oriented logical networks and for systems that adapt network behavior through software interfaces.

What it means

A traditional network discussion might begin with devices, ports and routes. An application-oriented discussion starts with which services need to communicate and what their traffic requires. A live conversation, a database synchronization and a bulk training-data transfer may have different priorities.

The phrase needs qualification. Research and vendor descriptions have used it with different emphases, including network programmability, performance management and logical segmentation. An implementation should therefore state what applications can request, which mechanisms enforce those requests and what remains under administrator control.

It is related to software-defined networking, which makes network control programmable, but the emphasis here is on connecting that capability to application needs. The acronym ADN can also mean application delivery network in other contexts, so expanding the abbreviation matters.

How it works

An application or its management layer describes relevant requirements, such as permitted service connections, traffic priorities or performance objectives. A control system translates those requirements into supported network configurations.

The system may use logical networks, access policies, path selection or resource allocation. Monitoring then compares observed behavior with the objective. Depending on the design and authority granted, the control system can suggest a change or make a bounded adjustment.

Conflicts must be resolved. Two applications cannot both receive more guaranteed capacity than the available infrastructure can supply. An application also should not gain permission to bypass access restrictions merely because it requests a faster connection. Performance goals and access rules need a defined precedence.

The feedback loop requires testing: changing a route may affect other traffic, and repeated reactions to noisy measurements can create instability. The phrase “application defined” does not specify a universal controller, protocol, security package or automatic optimization algorithm.

Three practical examples

A company describes an application as front-end, API and database components, then derives only the network connections required between those components.
A collaboration service requests priority handling for delay-sensitive traffic while bulk transfers use remaining capacity under an agreed policy.
An AI platform monitors communication between data storage and training workers and proposes a supported network or placement change when a bottleneck is identified.

Think of it this way

Think of a venue assigning rooms and passageways according to an event's needs. A quiet interview and a large delivery require different arrangements, and the venue manager reconciles conflicts.

The analogy explains requirements influencing infrastructure. It does not mean each event can ignore building capacity or access rules. Likewise, an application-facing interface can express a request without guaranteeing that the network can satisfy it under every condition.

Worked example

Reconciling competing capacity requests

Consider an invented shared link with 100 megabits per second of usable capacity for a simplified planning exercise. A live service requests 20, a transactional service requests 30 and a background transfer requests 80.

The total request is 130 megabits per second, exceeding capacity by 30. A policy that protects the first two allocations can leave at most 50 for the transfer: 100 − 20 − 30 = 50. The transfer's requested rate is not a resource that the controller can create simply by accepting it.

If the background task must move 500 megabytes, that is 4,000 megabits using decimal units. At a sustained 50 megabits per second, the ideal transfer time is 80 seconds. At its requested 80, the ideal would be 50 seconds, but that allocation would conflict with the stated protected demands.

Real systems add overhead, changing demand and other bottlenecks. This example illustrates policy arbitration, not a protocol guarantee. An application-defined approach makes the requirements explicit; an implementation still needs a feasible allocation and measured results.

Illustrative case study

A fictional design company introduces an application-oriented network controller for its cloud services. It declares which services may communicate and which interactive sessions take priority over large asset transfers.

During a pilot, the controller detects slow responses and proposes a route change. Testing shows that the database's processing queue, rather than the network path, causes most of the delay. The team avoids treating every application slowdown as a networking problem.

It also verifies that a performance adjustment cannot broaden access to the database. This fictional case illustrates diagnosis and preservation of access boundaries.

Common misconceptions and mistakes

The label does not identify one universally standardized product architecture.
Application requirements cannot override physical capacity limits.
Network segmentation is not a guarantee that every possible security failure is prevented.
Software-defined networking and application-oriented policy are related but describe different emphases.
Better network metrics do not necessarily resolve an application bottleneck elsewhere.

Business use

When evaluating a proposal, translate the label into concrete capabilities. Identify the requirements language or interface, the controls it can change and the evidence that those changes improve the actual service.

Use a pilot with competing applications, changing load and an unavailable requested resource. Observe how the system handles conflicts and whether an operator can understand and reverse a decision. For distributed AI, distinguish network transfer time from accelerator utilization, storage throughput and compute time.

Check your understanding

Two applications each request a guaranteed 70 megabits per second over a shared 100-megabit usable link. Can a controller satisfy both simultaneously without changing the assumptions?

Answer: No. Their combined guarantee would require 140 megabits per second. The system must reject, renegotiate, schedule or otherwise change the resource arrangement.

Related terms

Segmentation
Orchestration
software-defined networking
network virtualisation
quality of service
network policy
application performance monitoring

Learn next

Describe one application's allowed connections and performance objectives separately. For each objective, identify an enforcement mechanism and a measurement, then specify what happens when two applications make incompatible requests.

Sources

Sources: NetIDE research paper, application-driven network control discussion: https://dejankostic.com/documents/publications/netide-ewsdn13.pdf . Technical disclosure describing application defined networking: https://patents.google.com/patent/US20140215077A1 . Relevant architecture passages were reviewed; the patent is evidence of terminology and a proposed design, not proof of achieved performance. Scope note: usage varies, so this entry explains the shared application-oriented concept rather than asserting a universal feature set.

Previous: Appearance model Next: Application firewall