Parent folderOpen Confluence

RWS Architecture article

NNNV

NNNV is the product-neutral architecture building block for network-to-network interconnection and controlled external connectivity. It states what DC 3.0 needs from this capabilit

  1. Typeabb
  2. Statuscandidate
  3. Domainnetwork
On this page
  1. ABB NNNV
  2. Summary
  3. Capabilities
  4. Constraints
  5. Service Description
  6. Roadmaps
  7. Landing Zones
  8. Interfaces
  9. Dependencies
  10. EIRA Alignment
  11. Available SBB's

ABB NNNV

Summary

NNNV is the product-neutral architecture building block for network-to-network interconnection and controlled external connectivity. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.

Capabilities

  • Provides network-to-network interconnection and controlled external connectivity.
  • Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
  • Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
  • Enables traceability from architecture intent to implementation, operational evidence, and consuming services.

Constraints

  • The resulting SBB must fit the networks ownership model and document the support, lifecycle, and service-management boundary.
  • Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
  • Interconnection must preserve segmentation, routing ownership, inspection requirements, and auditability.
  • SBBs must not create implicit trust between connected networks.

Service Description

This ABB offers an NNNV connectivity service for linking DC 3.0 network domains to approved external or government network environments. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.

The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.

Roadmaps

  • Baseline: confirm scope, service ownership, constraints, and acceptance criteria for NNNV.
  • MVP: identify candidate SBBs and connect them to the service, support, and lifecycle model.
  • Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.

Landing Zones

  • External cloud or external connectivity zone where services are intentionally published or interconnected.
  • Private cloud and central DC 3.0 landing zone for core infrastructure and platform services.
  • Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.

Interfaces

  • Routing, VPN, firewall, and interconnect interfaces as approved.
  • DNS, certificate, and monitoring integrations.
  • Change and evidence interfaces for network governance.

Dependencies

  • Depends on dc-network-structure for a supporting capability or integration boundary.
  • Depends on dns-dhcp-ipam for a supporting capability or integration boundary.
  • Depends on external-load-balancing for a supporting capability or integration boundary.
  • No implementing SBB is mapped yet; candidate SBB selection is a dependency for further elaboration.
  • Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.

EIRA Alignment

Available SBB's

  • No SBB is available yet. Candidate selection must be completed before this ABB can be promoted beyond capability intent.