1) Request
Ein Benutzer oder ein System sendet einen Request über Web oder REST API. Parameter definieren den konkreten Job-Lauf.
Infrastruktur
So arbeitet addy in deiner IT-Landschaft
Die Architektur ist bewusst überschaubar: addy als Plattform, ein POD im Kundennetz und deine Endpoints. Keine Blackbox, keine unnötige Komplexität.
automate IT tasks easily and efficiently
Empower others to get things done
Keep it simple and smart
Infrastrukturdiagramm
Die folgende Darstellung zeigt den Standardfluss von Requests bis zur Ausführung auf deinen Zielsystemen.
Bausteine der Architektur
2) addy
addy verwaltet mandantenfähig Catalog, Jobs und Requests. Freigaben und Regeln stellen sicher, dass Ausführung kontrolliert bleibt.
3) POD
Der POD läuft als Windows-Runner im Kundennetz und führt deine PowerShell-Automatisierungen aus.
4) Endpoints
Endpoints sind Zielsysteme wie AD, vCenter, Citrix, DNS/DHCP oder CA. Ansteuerung erfolgt z. B. via SSH, REST, PowerShell oder WinRM.
Request-Flow in 4 Schritten
Request auslösen
Ein Benutzer oder ein externes System startet einen definierten Job aus dem Catalog.
Regeln prüfen
addy prüft Berechtigungen, Parameter und den technischen Ausführungskontext.
POD ausführen lassen
Der POD übernimmt den Job-Lauf im internen Netzwerk und verarbeitet das Ergebnis.
Ergebnis nachvollziehen
Status, Output und Requests bleiben dokumentiert und reproduzierbar.
Transparenz statt Appliance-Magie
Du entscheidest, welche Jobs im Catalog bereitstehen, welche Parameter erlaubt sind und welche Endpoints angesprochen werden. Der POD führt nur aus, was du technisch definiert hast.
Du kannst alles nachvollziehen. Du hast die Macht.