Software-defined data center interconnect exposes physical DCI through a programmable control and service layer. Authorized teams can create, modify, monitor and retire connections through a portal, API or infrastructure-as-code workflow, but ports, optics, fiber, cross-connects and facilities still determine what can actually be delivered.
Buyers often confuse a portal with automation or treat SDN, EVPN/VXLAN and Network as a Service as interchangeable terms. This guide separates those concepts with a six-layer operating model, a provider map and a proof-of-concept scorecard.
What is software-defined data center interconnect?
Software-defined data center interconnect is a DCI service or architecture in which software controls a meaningful part of qualification, provisioning, modification, monitoring and retirement. The interface may be a portal, API or infrastructure-as-code tool. The service still depends on installed ports, cross-connects, optical paths, transport equipment and data-center access.
Executive summary
Software controls the lifecycle
For programmable interconnection, the meaningful test is whether software can quote, create, change, observe and delete a service without hiding routine tickets.
The underlay remains physical
Facility access, ports, optics, fiber routes, cross-connects and off-net extensions can still control lead time and resilience.
Provider categories are not equal
A network fabric, facility fabric, carrier service and customer-operated overlay solve different parts of the problem.
A proof of concept must create friction
Test failure, rollback, billing, support and deletion—not only a successful portal order.
Who this guide is for
Network and cloud architects
Use the six-layer model to separate portal controls from ports, fiber, cross-connects, routing and physical delivery.
Data center and infrastructure leaders
Compare programmable fabrics, facility ecosystems, carrier services and customer-operated overlays without treating them as the same product.
Security and operations teams
Test roles, APIs, telemetry, rollback, encryption, incident ownership and the state shown across every operating system.
Procurement and finance
Map ports, equipment, cross-connects, transport, platform fees, support, cloud charges and exit costs before comparing quotes.
How the control plane and physical network fit together
The control plane holds service intent, inventory, topology and policy. The forwarding plane carries traffic. Beneath both sits the physical underlay: buildings, meet-me rooms, equipment, fiber entrances, cross-connects and transport paths. A programmable DCI design must keep those physical dependencies visible in inventory and operating records.
Software can reduce repetitive work and expose network state, but it cannot make an unavailable path appear. As interconnection expert Hunter Newby puts it, “Interconnection starts with a physical process that happens in a specific, geographic location.”
The Percepture Six-Layer Programmable DCI Stack
The Percepture Six-Layer Programmable DCI Stack evaluates software-defined DCI from the facility floor through governance. A platform is useful only when the buyer can map what is delivered, what is automated and who owns failures at every layer.
| Layer | What belongs here | Buyer test | Common failure |
|---|---|---|---|
| 1. Physical access | Facilities, entrances, ports, optics, cross-connects and on-net status | Identify installed segments, owners and lead times | A missing cross-connect, optic or local loop blocks activation |
| 2. Transport and forwarding | Dark fiber, wavelengths, Ethernet, IP/MPLS or optical transport | Confirm service layer, MTU, protection and path expectations | A polished interface hides a shared or unsuitable underlay |
| 3. Control and orchestration | Controller, inventory, topology, policy and device orchestration | Determine whether the controller configures resources or submits a request | Partial orders, drift and incompatible changes |
| 4. Service abstraction | Ports, virtual circuits, endpoints, bandwidth, term and topology | Match objects across portal, API, telemetry and invoice | The commercial object does not match the operating object |
| 5. Automation and consumption | Portal, API, Terraform, templates, RBAC and approvals | Create, change, renew, disable and delete a service | The API opens a ticket instead of completing the lifecycle |
| 6. Assurance and governance | Telemetry, alarms, audit logs, billing, support and rollback | Prove state, performance, ownership and cost | Fast changes create unclear failures or billing disputes |
A physical-first view of programmable interconnection
How does software-defined DCI work?
A programmable interconnection order usually moves through seven operational steps. Physical work can occur before, during or after the software workflow, depending on the locations and service requested.
- Qualify the endpoints. Confirm source, destination, facility access and whether usable ports already exist.
- Select the service. Choose interfaces, endpoint types, bandwidth and the required Layer 2 or Layer 3 behavior.
- Submit intent. Request the term, topology, capacity and policy through a portal, API or infrastructure-as-code workflow.
- Validate resources. The controller checks inventory, permissions, compatibility and policy.
- Configure the service. The orchestrator applies validated changes to network systems and service objects.
- Expose operating state. The platform reports status, telemetry, usage and billing information.
- Manage the lifecycle. Authorized users modify, renew, disable or delete the programmable DCI connection.
Letters of authorization, connecting-facility assignments, building access, cross-connects, optics, construction, local loops and provider acceptance may remain manual. The buyer should document those dependencies before treating an activation estimate as an operating commitment.
What makes data center interconnect truly software-defined?
A portal is an interface. Software-defined is an operating model. software-defined DCI should place a meaningful share of the service lifecycle under consistent, documented and auditable software control.
The True Software-Defined DCI Test
Use this evidence set to distinguish programmable interconnection from a portal layered over manual fulfillment.
| Capability | Evidence to request | Failure signal |
|---|---|---|
| Digital qualification and quote | Endpoint availability, prerequisites and itemized charges | The quote ignores physical delivery |
| Portal and documented API | Current workflows, authentication and object definitions | The API only submits requests |
| Feature parity | A portal-to-API capability map | Important changes require a separate process |
| Create, change and delete | Completed programmable DCI lifecycle tests | Deletion or rollback requires manual escalation |
| Reusable service objects | Stable ports, circuits, endpoints and policy objects | Objects differ across tools and invoices |
| Telemetry and state | Status, timestamps, alerts and performance fields | The portal displays stale or ambiguous state |
| RBAC and approvals | Role tests, approval paths and audit records | Automation bypasses change controls |
| Billing traceability | Quote-to-order-to-invoice reconciliation | Usage and service changes cannot be matched |
| Failure and rollback | Error handling, idempotency and recovery tests | Partial orders leave uncertain network state |
| Physical disclosure | Ports, cross-connects, routes and third-party dependencies | “On demand” is presented as software-only delivery |
These tests keep software-defined DCI tied to observable lifecycle control rather than interface design. Hunter Newby summarizes the operating risk plainly: “A portal on top of a manual process is just a nicer way to wait.”
Proof-of-concept tool
Test the platform, not the demo
Use the Software-Defined DCI POC Scorecard to test whether programmable interconnection covers physical delivery, portal/API parity, automation, telemetry, resilience, billing, support and exit before committing.
Software-defined data center interconnect vs traditional DCI
Traditional DCI is not obsolete. A fixed wavelength or dark-fiber design may fit stable, high-volume and long-term requirements. software-defined DCI is generally more relevant when locations, capacity, clouds, project terms or topologies change often. The comparison should therefore test whether programmable interconnection flexibility offsets any added platform, integration or operating requirements.
| Decision area | Traditional DCI | Software-defined DCI |
|---|---|---|
| Ordering | Sales and engineering workflow | Portal, API or code workflow where supported |
| Qualification | Manual review is common | Digital qualification may expose available resources |
| Provisioning | Designed around a circuit delivery process | Existing fabric resources may be orchestrated through software |
| Changes | Formal change request | Authorized changes may be self-service |
| Term | Often aligned to stable infrastructure needs | May support more flexible service consumption |
| Topology | Engineered as part of the circuit design | Represented as reusable service objects where supported |
| Telemetry | Varies by carrier and managed-service scope | Often exposed through the platform interface |
| API | Not central to the operating model | Central when the programmable DCI lifecycle is genuinely programmable |
| Billing | Contract and circuit records | Should map service objects and changes to charges |
| Failure handling | NOC, ticket and runbook driven | May add automated detection, policy and rollback |
| Physical dependencies | Explicit parts of delivery | Still present and must be disclosed |
| Best fit | Stable routes and specialized transport requirements | Changing sites, clouds, capacity or project requirements |
Software-defined DCI vs SDN, EVPN/VXLAN, NaaS and SD-WAN
Software-defined networking is a broader architectural idea that separates or abstracts control from forwarding. VXLAN, defined in RFC 7348, is an overlay technology. Neither term alone proves that a commercial DCI lifecycle can be quoted, delivered, monitored and retired through software. software-defined DCI describes that lifecycle scope rather than one protocol or overlay.
| Term | What it is | What it controls | What it does not prove |
|---|---|---|---|
| Physical DCI | A transport path between facilities | Traffic movement over fiber-based infrastructure | Lifecycle automation |
| Virtual interconnection | A logical service over an installed fabric | Virtual circuits and logical endpoints | That ports and cross-connects are unnecessary |
| SDN | A programmable networking architecture | Control, policy and forwarding behavior | A complete commercial DCI service |
| programmable interconnection | DCI with meaningful software control of the service lifecycle | Qualification, service objects, changes, visibility and retirement where supported | Physical availability or encryption |
| EVPN/VXLAN | Control-plane and overlay technologies | Reachability and encapsulated traffic behavior | A physical or commercial path by itself |
| NaaS | A network consumption and operating model | Service acquisition and operation through a platform | One specific architecture or transport type |
| SD-WAN/SASE | Application, branch, routing and security policy systems | Traffic selection and policy | Optical or Ethernet transport between data centers |
What can programmable DCI automate?
programmable DCI can automate lifecycle work only where the platform has supported resources, permissions and service objects.
Often suitable for automation
- On-net endpoint qualification
- Pricing and service selection
- Virtual-circuit creation
- Bandwidth and term changes
- Topology and endpoint changes
- Monitoring, usage and alerts
- Renewal, disable and deletion workflows
- API and Terraform-based operations
May still require people or field work
- New port delivery
- Building access and cross-connects
- LOA/CFA coordination
- Optic installation
- Off-net extensions and local loops
- Construction
- Physical route validation
- Emergency repair and contract exceptions
A buyer-fit review should separate the software-defined DCI tasks that can complete digitally from the field work and exceptions that retain manual ownership.
Which providers offer programmable interconnection?
Providers offering programmable DCI fall into several categories. There is no useful universal ranking because physical reach, service type, API depth, topology, support and operating responsibility vary by workload and location. A software-defined DCI shortlist should therefore begin with endpoint qualification and responsibility mapping.
| Representative provider | Category | Software scope to evaluate | Physical dependency | Buyer fit | Verify before selection |
|---|---|---|---|---|---|
| PacketFabric | Independent programmable network fabric | programmable interconnection portal, API, service objects and lifecycle operations | Supported facilities, ports, cross-connects and routes | Buyers seeking programmable data-center and cloud connectivity | On-net status, API scope, diversity, SLA, security and billing |
| Megaport | Independent programmable network fabric | Fabric and virtual connectivity workflows | Available locations and physical access | Buyers comparing fabric-based connectivity | Endpoint coverage, service scope, operations and cost |
| Console Connect | Independent programmable network fabric | Platform-based connectivity workflows | Network reach and installed access | Buyers comparing global fabric options | Locations, APIs, service types and support |
| Equinix Fabric | Facility-centered interconnection fabric | Virtual connections within a facility ecosystem | Facility presence and required ports | Buyers already operating in supported facilities | Facility access, endpoints, limits and complete cost |
| Digital Realty ServiceFabric | Facility-centered interconnection fabric | Platform-based interconnection services | Facility and partner availability | Buyers using the relevant data-center ecosystem | Coverage, service ownership and physical prerequisites |
| Carrier on-demand services | Carrier-backed programmable network | Service ordering and changes within carrier scope | Carrier network and access availability | Buyers wanting one carrier relationship | API depth, reach, terms and support boundaries |
| Customer-operated SDN | Controller or overlay platform | Customer policy, overlays and orchestration | Transport must be sourced and operated | Teams with strong network engineering capacity | Underlay ownership, integration and operational staffing |
How PacketFabric fits a programmable DCI evaluation
PacketFabric is a partner option in this guide and should be evaluated on fit rather than treated as a universal winner. Its Agile DCI materials present portal- and API-oriented connectivity across supported locations. Buyers should test whether the actual portal, documented API, service types, telemetry, support and physical delivery meet their programmable DCI requirements.
For software-defined DCI, the practical questions are direct: Are both sites supported? Which ports and cross-connects are required? Can the same operation be completed through the portal and API? How are route diversity, protection, encryption, billing and off-net dependencies documented?
- Evaluate: portal, API, infrastructure-as-code support, service objects, visibility and support.
- Map: facilities, ports, cross-connects, routes and third-party extensions.
- Test: quote, create, change, observe, fail, roll back, bill and delete.
- Confirm: SLA boundaries, security controls, diversity and complete cost.
Partner option
Explore programmable DCI with PacketFabric
Review PacketFabric’s Agile DCI platform and current programmable interconnection service options. Confirm physical availability, route diversity, SLA boundaries, security requirements and complete cost for your sites.
What is the architecture of software-defined DCI?
A practical programmable DCI architecture follows a chain of responsibility: customer interface, identity and approvals, service catalog, orchestration, inventory and path logic, network devices, physical transport, then telemetry and billing.
- Intent and authorization: A portal, API or Terraform workflow submits a request. Identity, role-based access control and approval rules determine whether it may proceed.
- Validation and execution: The software-defined DCI service catalog translates the request into network objects. Inventory and topology systems validate resources before an orchestrator applies changes.
- Assurance and recordkeeping: Telemetry, alarms, audit logs, SLA records and billing show what exists, what changed and who owns the next action.
A northbound API exposes service functions to customer tools. Southbound control communicates with network systems. A reliable source of truth prevents the portal, controller, device state and invoice from describing different networks.
How do Layer 2, Layer 3, EVPN and VXLAN fit?
programmable interconnection can offer Layer 2 or Layer 3 services. The application requirement—not the phrase “software-defined”—should determine the choice. Layer 3 usually creates clearer fault boundaries, while Layer 2 should serve a documented application or migration need.
EVPN and VXLAN can support multi-tenant overlays and mixed connectivity designs, but operating them requires routing and control-plane skill. A commercial DCI platform and an overlay may work together while remaining separate responsibilities.
Is software-defined DCI secure?
programmable DCI automation can improve consistency, approvals and visibility, but it also creates API and control-plane attack surfaces. Private connectivity does not automatically mean encrypted connectivity.
- Use least-privilege roles and separate administrative duties.
- Require MFA or SSO where the platform supports it.
- Store API secrets outside scripts and rotate credentials.
- Apply approval workflows to high-risk changes.
- Retain audit logs that connect users, requests and network objects.
- Define encryption requirements separately from private-path requirements.
- Validate segmentation, route policy and configuration before deployment.
- Test rollback, emergency access and credential revocation.
- Review provider security and compliance evidence against the buyer’s controls.
- Document the shared-responsibility boundary.
How should resilient programmable DCI be designed?
Software can automate detection and failover, but it cannot create physical diversity that was never built. Two logical services may share an entrance, conduit, fiber route, device, power domain or upstream provider. Resilient software-defined DCI therefore requires documented physical failure domains as well as control-plane recovery.
- Require two physically diverse paths where the workload justifies them.
- Confirm separate building entrances when needed.
- Separate ports, devices and power domains.
- Map provider and transport failure domains.
- Document protection at the correct network layer.
- Use independent routing sessions and policies.
- Set measurable convergence targets.
- Design controller and orchestrator redundancy.
- Maintain out-of-band operations and emergency access.
- Monitor loss, latency, errors, utilization and service state.
- Test failover and rollback under load.
- Keep runbooks, escalation paths and ownership current.
“Two connections on the same fiber path is not redundancy. It’s a shared failure point with a backup invoice.” — Hunter Newby
How much does software-defined data center interconnect cost?
programmable DCI has no responsible universal price range. Total cost depends on locations, physical access, service type, capacity, distance, term, protection, endpoints, support and changes over the service lifecycle. A complete software-defined DCI estimate must include both platform-controlled services and physical delivery costs.
| Cost component | What to capture | Question for the supplier |
|---|---|---|
| Port and interface | Port type, speed and recurring charge | Is an existing compatible port available? |
| Equipment and optics | Required hardware, ownership and replacement | Who supplies and supports each optic? |
| Cross-connect and LOA/CFA | Facility fees and coordination | Which party orders and pays? |
| Transport | Metro or long-haul path and protection | What physical route is included? |
| Virtual circuit | Service object and recurring charge | How does it map to the invoice? |
| Bandwidth and usage | Committed capacity, usage or burst rules | How are changes and overages calculated? |
| Term | Minimum commitment and renewal | What changes at renewal? |
| Cloud, IX or SaaS endpoint | Endpoint and provider-side charges | Are third-party fees separate? |
| Off-net extension | Local loop, construction and third-party access | Who owns delays and repair? |
| Resilience | Second ports, paths, devices and facilities | Is diversity physical and documented? |
| Operations | Support, monitoring, integration and security | What is included versus separately managed? |
| Exit | Migration, deletion and stranded access | What remains billable after service deletion? |
Price transparency is not the same as low price. A programmable interconnection platform may make quotes and changes easier to understand, while physical delivery and third-party dependencies still drive the economics.
When should a company use programmable DCI?
programmable DCI is a stronger candidate when connection requirements change frequently enough to justify programmable lifecycle control.
Stronger fit
- Data-center migration or consolidation
- Disaster recovery
- Hybrid or multi-cloud connectivity
- Changing bandwidth requirements
- Temporary projects
- Mergers and acquisitions
- Multi-site applications
- Partner, exchange or site-to-cloud connectivity
Weaker fit
- One stable route where dedicated transport better fits the economics
- Locations outside the available fabric
- Specialized optical requirements
- Teams without safe automation practices
- Buyers requiring fully managed operations
The final buyer-fit decision should compare software-defined DCI with dedicated transport using the workload, available locations, operating skills and complete cost.
What should a software-defined DCI proof of concept test?
A proof of concept for programmable interconnection should test normal operations, physical dependencies and failure behavior. “A demo is a carefully choreographed dance. A proof of concept is a stress test,” Hunter Newby advises.
| # | POC test | Record as |
|---|---|---|
| 1 | Confirm endpoints and on-net status | Pass, partial/manual, fail or not applicable |
| 2 | Identify every physical prerequisite and lead time | Pass, partial/manual, fail or not applicable |
| 3 | Generate a quote and reconcile all fees | Pass, partial/manual, fail or not applicable |
| 4 | Create a programmable DCI service in the portal | Pass, partial/manual, fail or not applicable |
| 5 | Create the same service through the API | Pass, partial/manual, fail or not applicable |
| 6 | Build the workflow through infrastructure as code | Pass, partial/manual, fail or not applicable |
| 7 | Compare portal and API capabilities | Pass, partial/manual, fail or not applicable |
| 8 | Modify bandwidth and term | Pass, partial/manual, fail or not applicable |
| 9 | Change an endpoint or topology | Pass, partial/manual, fail or not applicable |
| 10 | Test idempotency and duplicate-order protection | Pass, partial/manual, fail or not applicable |
| 11 | Test roles, approvals and audit records | Pass, partial/manual, fail or not applicable |
| 12 | Measure telemetry and alert freshness | Pass, partial/manual, fail or not applicable |
| 13 | Reconcile usage and service changes with billing | Pass, partial/manual, fail or not applicable |
| 14 | Simulate failure and measure convergence | Pass, partial/manual, fail or not applicable |
| 15 | Roll back and delete the service | Pass, partial/manual, fail or not applicable |
| 16 | Open a support case and test escalation | Pass, partial/manual, fail or not applicable |
| 17 | Review SLA boundaries and exclusions | Pass, partial/manual, fail or not applicable |
| 18 | Document migration and exit | Pass, partial/manual, fail or not applicable |
Common programmable DCI mistakes
Most software-defined DCI mistakes come from assuming that a digital interface proves complete automation, physical readiness or operational resilience.
- Buying a portal instead of lifecycle automation.
- Treating “on demand” as proof that no physical work remains.
- Comparing unlike provider categories.
- Ignoring API limits, versions and feature parity.
- Automating before defining a source of truth.
- Extending Layer 2 without an application requirement.
- Assuming private connectivity is encrypted.
- Counting logical circuits as physical route diversity.
- Ignoring controller and orchestration failure.
- Testing only successful provisioning.
- Comparing monthly circuit charges instead of total cost.
- Failing to test deletion, rollback and exit.
How technical authority becomes qualified demand
Complex infrastructure providers also need buyers and search systems to understand what programmable interconnection does, where it fits and what proof matters. Percepture connects technical education with telecom marketing expertise, technical content strategy and enterprise SEO services.
Teams preparing content for AI retrieval can pair that foundation with generative engine optimization services. Launch and amplification can then use digital PR services, while B2B lead generation services support the path from technical interest to qualified conversations.
Technical-market proof
See how authority becomes qualified demand
Review the Broadstaff Global case study to see how Percepture connected technical-industry expertise, stronger search visibility and qualified lead generation.
Read the Broadstaff case studySoftware-defined DCI FAQs
What is software-defined data center interconnect?
Software-defined data center interconnect is DCI in which software controls a meaningful part of qualification, provisioning, modification, monitoring and retirement. It may use a portal, API or infrastructure-as-code workflow. Physical ports, optics, fiber, cross-connects, transport systems and data-center facilities remain part of delivery.
How does software-defined DCI work?
In programmable interconnection, a user submits service intent through a portal, API or code workflow. Identity and policy systems authorize the request. Inventory and topology systems validate resources, and an orchestrator applies approved changes. The platform should then expose state, telemetry, audit records and billing for ongoing operation.
Does software-defined DCI still use physical fiber?
Yes. programmable DCI controls service functions but does not replace fiber, ports, optics, cross-connects or facilities. A virtual connection can be activated quickly only when the required physical access and network capacity already exist. Missing construction or access work can still control delivery time.
Is software-defined DCI the same as SDN?
No. SDN is a broader networking architecture that abstracts or separates control from forwarding. Software-defined DCI applies programmable control to the DCI service lifecycle. An SDN controller can be part of the architecture without providing a complete commercial interconnection service.
Is EVPN/VXLAN software-defined DCI?
Not by itself. EVPN and VXLAN can provide control-plane and overlay functions for data-center connectivity. They do not independently provide facility access, optical or Ethernet transport, commercial service delivery, billing or support. They may operate inside a broader programmable DCI design.
Which providers offer programmable DCI?
Representative software-defined DCI categories include independent network fabrics, facility-centered fabrics, carrier-backed on-demand networks and customer-operated SDN platforms. PacketFabric, Megaport, Console Connect, Equinix Fabric and Digital Realty ServiceFabric are examples buyers may evaluate. Selection should depend on reach, service type, API depth, operations and physical delivery.
Is private DCI automatically encrypted?
No. A private path limits how connectivity is presented or shared, but that does not prove traffic encryption. Buyers should state encryption requirements explicitly, identify the network layer where encryption is applied and confirm key management, performance impact and operational ownership.
How should a buyer test a programmable DCI platform?
Test programmable interconnection qualification, physical prerequisites, quoting, portal/API parity, infrastructure as code, changes, roles, telemetry, billing, failure, rollback, deletion, support and exit. Record each result as pass, partial/manual, fail or not applicable so hidden tickets and physical delays remain visible.
Telecom and data-center visibility
Own the infrastructure questions buyers ask next
Percepture helps telecom, data-center, cloud and network companies explain programmable DCI and other complex services through search strategy, technical content, digital PR and AI-search visibility. A visibility review can identify where software-defined DCI positioning, evidence and buyer guidance need greater clarity.
For software-defined data center interconnect, verify the physical path, map all six operating layers, test the full lifecycle, prove resilience and billing, then choose the provider that fits the workload.
About Bob Generale
Bob Generale is President of Percepture, a digital marketing and public relations agency founded in 2004. His work connects executive strategy, technical content, SEO, GEO, digital PR and conversion planning for organizations selling complex B2B, telecom, network and data-center services.
Bob focuses on making difficult infrastructure topics clear enough for buyers, search engines and AI answer systems to understand without stripping away the physical and operational details that make the answer credible.
