Einfach Komplex – Der Software- und IT-Podcast

Zu Gast ist Yannick Reinke, IT-Freelancer aus dem Allgäu mit eigener IT-Beratung und Schwerpunkt auf Microsoft-Technologie. Es geht um eine Sortierung des Portfolios entlang von drei Blöcken: Power Platform, Fabric samt Power BI sowie Copilot. Microsoft deckt gefühlt alles ab und die Tools greifen sauber ineinander, nur kann kaum jemand noch sagen, welches davon für welchen Fall das richtige ist.
In der Power Platform ist Power Apps das Frontend, Power Automate die Prozessengine und Dataverse die Datenhaltung. Programmiert wird in Power FX, allerdings eigenschaftsweise am jeweiligen Element und nicht als zusammenhängender Code, der sich versionieren oder am Stück von einer KI korrigieren ließe. Solange SharePoint oder Microsoft Lists als Quelle dienen, ist die Standardvariante in der E3-Lizenz enthalten, mit Dataverse wird es lizenzpflichtig und als Speicher schnell teuer. Bei den Daten ist Power BI das Visualisierungswerkzeug und Fabric die Plattform darunter, die Azure Data Factory, OneLake und Synapse zusammenfasst. Der Kern der Arbeit liegt dabei nicht im Dashboard, sondern im semantischen Modell samt Row Level Security, die bis auf Zeilenebene regelt, wer was sieht, und sich bis in die Copilot-Antworten durchzieht.
Beim dritten Block hilft es, die verschiedenen Dinge auseinanderzuhalten, die Microsoft alle Copilot nennt: den integrierten Copilot in Word, Excel, Teams und Outlook, den Copilot Chat mit Webwissen, Copilot Studio für Agenten auf eigener Knowledge Base und Microsoft Foundry, früher Azure AI Foundry, als Pro-Code-Plattform mit freier Modellauswahl. Dazu kommen die Frage nach Determinismus, wenn die Antwort eigentlich eine belastbare Zahl sein soll, und der Hinweis, dass acht von zehn vermeintlichen KI-Fällen in Wahrheit regelbasierte Workflows sind.
Links zur Folge:
IT-Beratung Reinke: https://www.it-beratung-reinke.de
Yannick Reinke auf LinkedIn: https://www.linkedin.com/in/yannick-reinke-7688b2198/
------
Einfach Komplex ist ein Podcast von Heisenware.
Weitere Infos und ein kostenloser Test: https://heisenware.com/einfach-komplex
Kontakt: podcast@heisenware.com

TypeScript ist keine eigene Programmiersprache, sondern ein Typsystem über JavaScript, das beim Kompilieren wieder verschwindet. Am Ende läuft Vanilla JavaScript. Genau daran hat sich Burkhards jahrelange Skepsis entzündet: C++ zwingt Euch, alles zu typisieren, JavaScript wurde unter anderem erfunden, um diesen Ballast loszuwerden, und TypeScript schraubt ihn wieder obendrauf. Entstanden ist es bei Microsoft unter Anders Hejlsberg, dem Architekten hinter Turbo Pascal, Delphi und C#, von Anfang an öffentlich unter Apache-2.0-Lizenz.
Anders als die nominalen Typsysteme von Java oder C++ typisiert TypeScript strukturell, umgangssprachlich Duck Typing: Wenn die Form stimmt, passt der Typ. Der Compiler tsc führt nichts aus, er prüft nur die Konsistenz und meldet Fehler bereits in der IDE statt erst zur Laufzeit. Damit verschwinden die Klassiker, die Ihr sonst erst im Betrieb seht, etwa ein undefined mitten in der UI-Maske oder eine weiße Seite im Frontend. Wer nicht erzwingen will, kann bei JavaScript plus JSDoc bleiben und Typen nur dokumentieren. Testabdeckung ersetzt das übrigens nicht, Typisierung und Tests sind zwei orthogonale Dimensionen.
Der Auslöser für die Umstellung der Heisenware-Engine von Node.js mit Vanilla JavaScript auf TypeScript war allerdings KI. TypeScript ist alt genug für massive Präsenz in den Trainingsdaten, der vorhandene Code ist durch den Compiler-Check überdurchschnittlich sauber, und semantische Typnamen wie User oder ProductionOrder machen eine Codebase für ein LLM lesbar wie Fließtext. Ein durchdefinierter Typ lässt der KI keinen Interpretationsspielraum, und für Tool Calling und MCP lassen sich JSON-Schemata direkt aus den Typen ableiten. Wie schnell sich hier etwas bewegt, zeigt der Compiler selbst: Unter dem Codenamen Corsa nach Go portiert, um echtes Multithreading zu nutzen, ist TypeScript 7.0 am 8. Juli 2026 allgemein verfügbar geworden, mit Beschleunigungsfaktoren von acht bis zwölf bei vollen Builds.
Links zur Folge:
https://www.typescriptlang.org
https://github.com/microsoft/TypeScript
https://github.com/microsoft/typescript-go
---
Einfach Komplex ist ein Podcast von Heisenware.
Heisenware kennenlernen: https://heisenware.com/einfach-komplex
Kontakt: podcast@heisenware.com

Wir begrüßen Stefan Herrmann, VP Product bei Cybus, als unseren Gast für das Thema Unified Namespace, kurz UNS. In vielen Industrieunternehmen wächst die IT- und OT-Landschaft über Jahre hinweg organisch, was meist in starren Punkt-zu-Punkt-Verbindungen, Gateways mit unterschiedlichen Softwareständen und unstrukturierten Daten endet. Ein Unified Namespace löst dieses Integrationschaos, indem er als standardisiertes, integriertes Konzept alle Geräte, Senkrechten und Datenströme innerhalb eines Netzwerks einheitlich benennt und organisiert. Daten erhalten dadurch einen festen, vorhersehbaren Platz, wodurch Applikationen von direkten End-zu-End-Verbindungen entkoppelt werden.
Im Gegensatz zu einer klassischen Datenbank fungiert ein Unified Namespace als reiner Live-Datenstrom für Echtzeitdaten, an den Langzeitspeicher wie Historians oder Analysetools modular angedockt werden. Technisch basiert diese Architektur auf MQTT und einem zentralen Broker als Drehscheibe im Publish-Subscribe-Verfahren. Über hierarchisch verschachtelte Adressierungen, sogenannte Topics, lassen sich Datenstrukturen vom Werk über die Linie bis hin zum einzelnen Sensor logisch abbilden. Das ermöglicht eine eventgetriebene Kommunikation, bei der Funktionen wie Retained Messages den letzten bekannten Zustand puffern oder Last Will and Testament automatische Offline-Meldungen bei Verbindungsabbrüchen absetzen.
Da im industriellen Umfeld strenge Sicherheitsvorgaben gelten, wird die Zugriffssteuerung über ein rollenbasiertes Access-Management bis auf den einzelnen Datenpunkt granular geregelt und an bestehende IT-Benutzermanagements wie LDAP oder Entra-ID gekoppelt. Um diese menschliche und technische OT-IT-Konvergenz in Eurer Fertigung erfolgreich umzusetzen, ist eine klare Konvention notwendig. Hierfür empfiehlt sich der Aufbau einer übergreifenden Taskforce oder eines Center of Excellence, das OT, IT und die fachlichen Prozessverantwortlichen an einen Tisch bringt.
Links zur Folge
Cybus https://cybus.io
Stefan auf LinkedIn https://www.linkedin.com/in/stefanhermannberlin
---
Einfach Komplex ist ein Podcast von Heisenware.
Heisenware kennenlernen: ⁠https://heisenware.com/einfach-komplex⁠⁠⁠⁠
Kontakt: ⁠podcast@heisenware.com

Wer Software, Firmware oder digitale Komponenten für die Industrie auf den Markt bringt, haftet künftig über den gesamten Produktlebenszyklus für die IT-Sicherheit. Der Cyber Resilience Act (CRA) der EU macht Cybersicherheit von der optionalen Produkteigenschaft zur harten gesetzlichen Pflicht. Das betrifft Embedded-Systeme im Schaltschrank genauso wie SCADA-Plattformen oder industrielle Cloud-Anwendungen. Gemeinsam mit Benjamin Becker von abl solutions ordnen wir die rechtlichen und technischen Anforderungen ein.
Das akuteste Thema des CRA ist die neue Meldepflicht, die bereits im September 2026 in Kraft tritt. Aktiv ausgenutzte Schwachstellen müssen innerhalb von nur 24 Stunden an die europäische Cybersicherheitsbehörde ENISA gemeldet werden, was vollkommen neue interne Prozesse in den Unternehmen erfordert. Dabei gilt im Audit ein unerbittliches Prinzip: Was nicht dokumentiert ist, existiert regulatorisch nicht. Jede Risikoanalyse und jede Architekturentscheidung muss lückenlos nachweisbar sein.
Ein zentraler Baustein ist das kontinuierliche Schwachstellen-Management über eine automatisierte Software Bill of Materials (SBOM). Damit lassen sich Abhängigkeiten und bekannte Sicherheitslücken in externen Komponenten oder Open-Source-Bibliotheken fortlaufend überwachen. Entscheidend ist dabei die Frage, wie sich diese automatisierten Risikoanalysen so in die CI/CD-Pipeline integrieren lassen, dass sie die Entwicklungsgeschwindigkeit nicht blockieren und die gesetzliche Konformität innerhalb der dreijährigen Übergangsfrist sichergestellt wird.
Links zur Folge
Benjamin auf LinkedIn: https://www.linkedin.com/in/benjaminbecker2/
Website abl solutions: https://abl-solutions.com/
Website Pallax-Plattform: https://pallax.io/
------
Einfach Komplex ist ein Podcast von Heisenware.
Kontakt: ⁠podcast@heisenware.com⁠
Heisenware kennenlernen: ⁠https://heisenware.com/einfach-komplex⁠⁠⁠⁠

Große Sprachmodelle sind mächtig, aber von Haus aus komplett isoliert. Wenn sie auf interne Firmendaten, lokale Code-Repositories oder Datenbanken zugreifen sollen, artete das bisher in architektonischem Wildwuchs aus: Für jedes neue KI-Tool mussten Entwickler eigene, maßgeschneiderte API-Wrapper schreiben. In Folge 112 räumen wir mit diesem Integrations-Chaos auf und schauen tief in den Maschinenraum des Model Context Protocol (MCP).
Wir erklären, warum MCP als offener Standard genau dieses Problem löst, indem es wie ein universeller USB-Anschluss zwischen KI-Anwendungen und lokalen Datenquellen fungiert. Dabei zerlegen wir die Architektur strikt in ihre Einzelteile: Du erfährst den entscheidenden Unterschied zwischen dem Host (wie der IDE Cursor oder einem Agenten-Framework), dem internen Client-Konnektor und dem lokalen MCP-Server, der die spezialisierten Tools und Datenquellen bereitstellt.
Technisch gehen wir der Frage auf den Grund, wie die Kommunikation via JSON-RPC 2.0 über Standard Input/Output (Stdio) oder Server-Sent Events (SSE) im Detail abläuft. Ein zentraler Fokus liegt dabei auf der IT-Sicherheit: Wir diskutieren, warum die lokale Code-Ausführung durch den MCP-Server einen natürlichen Airgap schafft und sicherstellt, dass Cloud-KIs niemals unkontrollierten Vollzugriff auf Eure Infrastruktur bekommen. Zum Schluss werfen wir einen Blick darauf, wie dieses Protokoll die Art und Weise verändern wird, wie wir in Zukunft Software und interne APIs designen.
MCP Website https://modelcontextprotocol.io/
------
Einfach Komplex ist ein Podcast von Heisenware.
Kontakt: podcast@heisenware.com
Heisenware kennenlernen: https://heisenware.com/einfach-komplex⁠⁠⁠