Home Assistant Enterprise Architecture klingt erstmal nach einer etwas konstruierten Überschrift. Ist es aber für mich gar nicht. Ich habe durch Home Assistant, PV-Überschuss, Pooltechnik, UniFi und ein paar eher pragmatische Integrationen tatsächlich nochmal anders über Architektur nachgedacht.
Am Anfang geht es bei Home Assistant meistens recht harmlos los. Man will irgendetwas schalten. Licht, Steckdose, Heizung, PV-Anzeige, was auch immer. Dann kommt das erste Dashboard. Dann die erste Automation. Dann merkt man, dass ein Wert aus System A eigentlich in System B gebraucht wird und der Hersteller natürlich wieder irgendetwas Eigenes macht.
Irgendwann sitzt man dann da und baut sich mit ESPHome, MQTT, Modbus, REST, Templates, Shelly, UniFi, Wechselrichter, Wärmepumpe, Pooltechnik und ein paar Hilfskonstrukten ein System zusammen, das nicht hübsch aus einem Guss ist, aber genau das macht, was man eigentlich wollte.
Bei mir ist das inzwischen mehr als „ich schalte eine Lampe per App“. Es geht um PV-Überschuss, Wärmepumpe, Poolpumpe, Verbrauchswerte, Batteriespeicher, Netzwerk, lokale Steuerung, Fallbacks und Dinge, die der Hersteller so nicht vorgesehen hat.
Und ja, manchmal auch darum, dass bei RS485 irgendwo A und B vertauscht sind und man erstmal nicht versteht, warum nichts antwortet. Kommt einem aus Enterprise-Umgebungen irgendwie bekannt vor.
Home Assistant Enterprise Architecture: die Ausgangslage
Der eigentliche Punkt an Home Assistant ist für mich nicht, dass man alles irgendwie smart machen kann. Das ist nett, aber dafür würde ich den Aufwand nicht treiben.
Interessant wird es erst, wenn mehrere Systeme miteinander sprechen und daraus etwas entsteht, was vorher nicht möglich war. Eine Poolpumpe nur per App einzuschalten bringt mir erstmal nicht viel. Das kann der Hersteller vielleicht auch. Oder eine Zeitschaltuhr.
Spannend wird es, wenn Home Assistant weiß, ob gerade PV-Überschuss vorhanden ist, ob die Wärmepumpe läuft, welche Drehzahl sinnvoll ist, wie laut es nachts sein darf, ob nach einem langen Badetag mehr umgewälzt werden muss und ob die Pumpe gerade sparsam laufen oder bewusst mehr Durchfluss liefern soll.
Dann ist das keine Fernbedienung mehr. Dann ist es Orchestrierung. Genau an dieser Stelle beginnt für mich Home Assistant Enterprise Architecture im Kleinen.
Genau da wird Home Assistant Enterprise Architecture für mich interessant. Nicht, weil mein Technikraum dieselbe Größenordnung hat wie ein Konzernnetz. Natürlich nicht. Aber die Denkweise ist erstaunlich ähnlich.
Im Enterprise-Umfeld heißen die Komponenten dann nicht Poolpumpe, Wechselrichter oder Shelly. Dort heißen sie SD-WAN, SASE, Firewall, Cloud, IAM, Monitoring, ITSM, Compliance, Plattform, Underlay, Overlay oder irgendein Service, der historisch gewachsen ist und den natürlich niemand einfach mal eben austauscht.
Das Problem ist selten die einzelne Komponente
Bei meinem Smart Home ist nicht jedes Gerät perfekt. Manche Integrationen sind sauber. Manche liefern nur einen Teil der Werte. Manche sprechen Modbus TCP, andere RS485, andere irgendein XML über HTTP und manche wollen am liebsten nur über ihre eigene Cloud-App reden.
Und trotzdem muss am Ende ein sinnvolles Gesamtsystem entstehen.
Genau das gleiche sehe ich in Unternehmen. Wir diskutieren oft sehr lange über einzelne Produkte. Welcher Hersteller kann Feature X besser? Welche Firewall hat dort mehr Durchsatz? Welcher SD-WAN-Controller ist schöner? Welche SASE-Plattform hatte welches Feature zuerst?
Das ist alles nicht unwichtig. Aber aus meiner Sicht ist es nicht der Kern der Architekturfrage.
Die eigentliche Frage ist: Wie passt das alles zusammen? Wie betreibt man es? Wie sieht Monitoring aus? Wer versteht die Abhängigkeiten? Was passiert bei Fehlern? Wie wird geändert, ohne dass alles auseinanderfällt?
Und wer ist am Ende eigentlich verantwortlich, wenn drei Systeme jeweils grün anzeigen, der Nutzer aber trotzdem nicht arbeiten kann?
Home Assistant ist manchmal ehrlicher als Enterprise IT
Was ich an Home Assistant mag: Es versteckt die Realität nicht komplett. Wenn etwas nicht geht, sieht man es oft recht schnell.
- Ein Sensor liefert keine Werte.
- Eine Automation läuft nicht.
- Ein Gerät antwortet nicht.
- mDNS löst nicht sauber auf.
- Eine API ändert sich.
- Oder die eigene Lösung funktioniert, ist aber noch nicht wirklich schön.
Im Enterprise-Umfeld sind die gleichen Probleme oft nur besser verpackt. Da gibt es dann Dashboards, PowerPoints, Servicebeschreibungen, Betriebsmodelle und Eskalationspfade.
Das Problem bleibt aber oft gleich: Viele einzelne Komponenten müssen gemeinsam funktionieren. Und häufig ist nicht die Technik allein schwierig, sondern das Zusammenspiel aus Technik, Betrieb, Prozessen, Verantwortlichkeiten und den Grenzen der jeweiligen Plattform.
Da hilft dann auch kein weiteres Buzzword. Nicht alles wird besser, nur weil man AI, Zero Trust, Cloud-native oder Intent-based davor schreibt. Manchmal muss man einfach wissen, welcher Wert woher kommt, warum er falsch ist und an welcher Stelle man ihn sauber korrigiert.
Architektur ist nicht die Suche nach dem perfekten Bauteil
Eine Sache habe ich durch diese privaten Projekte nochmal anders verstanden: Gute Architektur entsteht nicht dadurch, dass jede Komponente für sich perfekt ist.
Sie entsteht dadurch, dass man die Grenzen der Komponenten kennt und trotzdem ein stabiles Gesamtsystem baut.
Bei Home Assistant heißt das dann vielleicht: Der Wechselrichter liefert nicht alle Werte so, wie ich sie brauche. Also rechne ich sie mir anders zusammen. Der Frequenzumrichter kann lokal nichts mit Home Assistant anfangen. Also schaue ich, ob ich ihn per ESP32 und RS485 sauber eingebunden bekomme. Die Waschmaschine soll nicht einfach irgendwann laufen. Also lasse ich sie starten, wenn PV, Akku und Hausverbrauch halbwegs sinnvoll zusammenpassen.
Ein paar Beispiele dazu habe ich hier schon aufgeschrieben: den AquaForte iSaver-X mit ESP32, RS485 und ESPHome, die Waschmaschine bei PV-Überschuss und die Kostal-Integration in Home Assistant.
Im Unternehmen ist das Prinzip ähnlich. Nicht jedes System bringt die perfekte Schnittstelle mit. Nicht jeder Hersteller denkt an den späteren Betrieb. Nicht jede Lösung passt sauber in bestehende Prozesse. Und trotzdem muss am Ende etwas entstehen, das für Kunden funktioniert. Nicht auf dem Architekturdiagramm. Sondern im echten Betrieb.
Was ich daraus für Enterprise Architecture mitnehme
Für mich ist Home Assistant inzwischen so eine Art kleines Labor geworden. Nicht wegen der Größe, sondern wegen der Denkweise. Home Assistant Enterprise Architecture ist für mich deshalb kein Vergleich von Eins-zu-eins-Systemen, sondern ein Vergleich von Mustern.
- Integration ist wichtiger als Featurelisten.
- Lokale Kontrolle ist manchmal mehr wert als die schönste Cloud-App.
- Monitoring ist nicht optional.
- Automatisierung ist nur dann gut, wenn man sie auch versteht.
- Workarounds können technische Schuld werden.
- Dokumentation hilft, auch wenn man sie nur für sich selbst schreibt.
- Systeme werden nicht stabiler, nur weil man sie komplizierter macht.
Gerade letzteres ist für mich wichtig. Wir bauen in der IT gerne komplexe Dinge. Manchmal weil es notwendig ist. Manchmal aber auch, weil wir Komplexität mit Qualität verwechseln.
Mein Smart Home erinnert mich regelmäßig daran, dass die beste Lösung oft die ist, die man nach drei Monaten noch versteht. Auch dann, wenn man nicht mehr genau weiß, was man sich an dem Abend gedacht hat, als man diese Automation gebaut hat.
Der Transfer ins Business
Beruflich beschäftige ich mich viel mit Enterprise Networking, SD-WAN, SASE, Security, Portfolio und Architektur. Und je länger ich darüber nachdenke, desto weniger glaube ich, dass Kunden am Ende wirklich ein Netzwerk kaufen.
Sie kaufen erreichbare Anwendungen. Sichere Standorte. Stabile Cloud-Anbindungen. Nachvollziehbaren Betrieb. Klare Verantwortlichkeiten. Und möglichst wenig Überraschungen.
Das klingt erstmal weniger technisch. Ist es aber nicht. Im Gegenteil. Um das sauber hinzubekommen, muss man Technik sehr gut verstehen. Man muss aber auch wissen, wann die Technik in den Hintergrund treten sollte.
Kein Nutzer interessiert sich für das Overlay, wenn Teams nicht funktioniert. Kein Fachbereich fragt nach Routing-Protokollen, wenn die Anwendung langsam ist. Und kein Kunde möchte drei Hersteller einzeln debuggen, wenn er eigentlich einen funktionierenden Service bestellt hat.
Genau deshalb glaube ich, dass Enterprise Architecture künftig noch stärker als Systemdenken verstanden werden muss. Nicht als Sammlung einzelner Produkte. Nicht als Vendor-Vergleich. Nicht als Folie mit möglichst vielen Logos.
Sondern als Antwort auf die Frage: Wie bauen wir aus vielen Einzelteilen etwas, das zuverlässig, sicher und betreibbar ist?
Vielleicht lernt man manche Dinge nicht im Rechenzentrum
Ich hätte vor ein paar Jahren wahrscheinlich nicht gedacht, dass ich ausgerechnet durch Pooltechnik, PV-Überschuss und Home Assistant nochmal so viel über Architektur nachdenke.
Aber am Ende ist es genau das: ein System aus vielen Komponenten. Mit Schnittstellen. Mit Einschränkungen. Mit Fehlerbildern. Mit Abhängigkeiten. Mit Workarounds. Mit Betrieb. Und mit dem Ziel, dass es am Ende einfach funktioniert.
Nicht perfekt. Aber nachvollziehbar. Wartbar. Erweiterbar. Und im besten Fall so, dass man nicht jeden Samstag wieder mit dem Laptop im Technikraum steht.
Wobei, ganz ehrlich: manchmal macht genau das ja auch Spaß.