Analyse

Deutschland

Digitale Nachhaltigkeit

NADIKI im DCIM-Markt: Ergänzen statt ersetzen

NADIKI im DCIM-Markt: Ergänzen statt ersetzen

DCIM-Werkzeuge wissen, welche Hardware existiert und wie viel Strom sie verbraucht. Sie können aber nicht beantworten, was die gesamte Umweltwirkung eines Workloads auf dieser Hardware ist. Der NADIKI Registrar schließt diese Lücke — nicht als Konkurrenzprodukt, sondern als Integrationsschicht, die Asset-Daten, operative Telemetrie und Lebenszyklusdaten zu einer Umweltwirkungsbilanz pro Workload verbindet.

## Excerpt

DCIM-Werkzeuge wissen, welche Hardware existiert und wie viel Strom sie verbraucht. Sie können aber nicht beantworten, was die gesamte Umweltwirkung eines Workloads auf dieser Hardware ist. Der NADIKI Registrar schließt diese Lücke — nicht als Konkurrenzprodukt, sondern als Integrationsschicht, die Asset-Daten, operative Telemetrie und Lebenszyklusdaten zu einer Umweltwirkungsbilanz pro Workload verbindet.

## Content

Unsere Analyse des DCIM-Marktes zeigt eine strukturelle Lücke: Kein verfügbares Werkzeug — weder kommerziell noch Open Source — liefert tatsächliche Umweltwirkungsdaten pro Workload. PUE, CUE und WUE beschreiben die Effizienz eines Gebäudes, nicht die Wirkung einer Anwendung. Für das NADIKI-Projekt stellte sich damit eine Designfrage: Bauen wir ein eigenes DCIM-System — oder setzen wir auf dem auf, was bereits existiert?

Die Strategie: Ergänzen statt ersetzen

Rechenzentren betreiben bereits DCIM- und CMDB-Systeme. Ein neues Werkzeug, das dieselben Daten nochmals erfasst, erzeugt Redundanz und scheitert an der Akzeptanz. Deshalb positionieren wir den NADIKI Registrar als Schicht, die auf bestehenden Systemen aufsetzt und deren Daten für die Umweltwirkungsberechnung nutzt.

Konkret verbindet der Registrar vier Datenquellen, die heute isoliert existieren:

  • Asset-Identität aus NetBox, Device42, Nlyte oder jeder CMDB mit REST-API — der Registrar übernimmt das Hardware-Inventar, statt es selbst zu pflegen.

  • Operative Telemetrie aus DCIM-Monitoring (Sunbird Power IQ, EcoStruxure, Hyperview) oder direkt via SNMP/Modbus/Redfish/IPMI — Echtzeit-Daten zu Stromverbrauch und Kühlung.

  • LCA- und Embodied-Carbon-Daten aus der Boavizta-API oder Hersteller-EPD-Datenbanken — der Registrar reichert Asset-Datensätze mit Lebenszyklus-Wirkungsdaten an.

  • Netzemissionsfaktoren aus der Electricity Maps API — standort- und zeitabhängige CO₂-Intensität des Strommixes.

Mehrwehrt des NADIKI Registrar für das DCIM Ökosystem

Aus diesen vier Quellen berechnet der Registrar Umweltwirkungsindikatoren als Zeitreihen — pro Server, pro Rack, pro Rechenzentrum, pro Workload. Die Ergebnisse stehen über eine REST-API bereit und können für CSRD/ESG-Reporting, Beschaffungsentscheidungen oder Reporting-Dashboards abgerufen werden.

Die sechs Indikatoren orientieren sich an bestehenden LCA-Methoden und regulatorischen Anforderungen:

  • Primärenergieverbrauch (kWh) — erneuerbar und nicht-erneuerbar, getrennt ausgewiesen

  • Wiederverwendete Energie (kWh) — z.B. Abwärmenutzung

  • Wasserverbrauch (m³) — auf Rechenzentrumsebene

  • Treibhauspotenzial (CO₂-Äq.) — operative und graue Emissionen kombiniert

  • Abiotischer Ressourcenverbrauch (kg Sb-Äq.) — mineralische Ressourcen aus der Hardware-Herstellung

Der entscheidende Unterschied zu DCIM-Kennzahlen: Diese Indikatoren beschreiben nicht die Effizienz eines Gebäudes, sondern die tatsächliche Umweltwirkung einer spezifischen Nutzung — inklusive grauer Emissionen aus Herstellung und Entsorgung.

Warum diese Strategie funktioniert

Die Integrationsstrategie nutzt drei Eigenschaften des aktuellen DCIM-Marktes:

  • API-Reife der besten Quellen: NetBox (REST + GraphQL), Device42 und Hyperview bieten ausgereifte, dokumentierte APIs. Die Werkzeuge, die am wahrscheinlichsten als Datenquellen dienen, ermöglichen automatisierte Datenübernahme.

  • Kein Vendor-Lock-in: Der Registrar ist quellenagnostisch. Ob ein Rechenzentrum Sunbird, Nlyte oder eine selbst gebaute CMDB betreibt — solange eine API Inventar- und Messdaten bereitstellt, kann der Registrar sie verarbeiten.

  • Bestehende Investitionen bleiben erhalten: Rechenzentren müssen weder ihr DCIM noch ihre Monitoring-Infrastruktur austauschen. Der Registrar ergänzt, was fehlt — die Umweltwirkungsberechnung —, ohne bestehende Workflows zu stören.

Die vollständige technische Architektur beschreiben wir in der Publikation zur Observer-Architektur. Die Open-Source-Implementierung steht als NADIKI Registrar auf GitHub bereit.

Verwandte Publikationen:

- [[IDED/Communication/Website/Publikationen/Live/nadiki-observer-architektur-umweltwirkung]]

- [[IDED/Communication/Website/Publikationen/Live/nadiki-registrar-implementierung-open-source]]

- [[IDED/Communication/Website/Publikationen/Live/nadiki-api-umweltwirkung-rechenzentrum-ki]]

- [[IDED/Communication/Website/Publikationen/Drafts/nadiki-dcim-marktanalyse-umweltwirkung]]