Alexander Kastil

Früh kamen Data-Pipeline-Projekte mit dem SQL Server Integration Tooling dazu, geliefert nach Kundenspezifikation, bevor es Cloud-Infrastruktur gab. Danach folgte der Schritt in die volle Webentwicklung mit ASP.NET und SharePoint. Beide waren server-rendered, beide standen auf derselben Platform, und beide wurden zunehmend von JavaScript im Client getrieben. Diese Überschneidung hat mich in die Client-Side-Spezialisierung gedrängt: progressiv angereicherte Interfaces, touch-optimiertes HTML für den WebKit-Browser des iPhone 4 und Touch Events in Production, bevor es Mobile Frameworks gab.

Das Postback-Modell war keine Einschränkung, die man umgeht. Es war die Decke. Touch-optimierte Interfaces für den WebKit des iPhone 4 zu bauen, bevor es Zugang zum iOS SDK gab, hat bestätigt, was server-rendered Architecture nicht abbilden konnte: Der Browser war längst die Application Runtime, für jeden, der bereit war, ihn so zu behandeln. Diese Verschiebung hat die Arbeit danach geprägt.

Die Arbeit mit SharePoint begann vor 2003, parallel zur Infrastrukturphase. Die ersten SharePoint Development Classes habe ich vor 2007 geschrieben, mit Web Parts, Event Receivers und Content Types. Der eigentliche Unterschied lag im Solution Packaging: WSP Builder machte komplexe, wiederholbare Deployments beherrschbar, bevor es dafür ordentliches Tooling gab, und dieser Fokus hat die Arbeit von gewöhnlicher Intranet-Lieferung abgehoben.

Das ASP.NET Postback-Modell der Platform wurde zum Auslöser für den Wechsel. Für jede Interaktion zum Server und zurück: das funktionierte, bis es nicht mehr funktionierte. Mit Office 365 nahmen Sandboxed Solutions die serverseitige Option ohnehin weg. Client-Side war die einzige gangbare Richtung. AngularJS kam im richtigen Moment: Two-Way Binding ersetzte die manuelle DOM-Manipulation in den UIs von SharePoint-Projekten, und das Pattern trug weit genug, um zum Standardweg zu werden, bevor sich das Ökosystem von Microsoft auf einen geeinigt hatte. Dieses Bekenntnis zu client-seitigem JavaScript in einer Enterprise Collaboration Platform hat das Fundament für alles Weitere gelegt.

Der Übergang begann mit AngularJS in SharePoint. Als Angular 2 in einer frühen Beta erschien, bin ich darauf gewechselt, parallel zur frühen Beta von .NET Core: beides instabil, beides gleichzeitig. Das erzwang eine echte Auseinandersetzung mit objektorientiertem JavaScript und danach mit TypeScript, das nahe genug an C# lag, um zum Wendepunkt zu werden. Daraus entstand eine tiefe Spezialisierung auf Angular, die sich natürlich mit den vorhandenen Microsoft 365 und Azure Skills verband und Lösungen für Randfälle an der Schnittstelle von Frontend Architecture und Enterprise-Platform-Arbeit hervorbrachte. Ionic und Hybrid Mobile liefen als konsequenter Nebenstrang: früher Einsatz mit noch nicht stabilem Tooling, Cordova Pipelines und plattformspezifischen Eigenheiten, bevor sich das Ökosystem setzte. Die Node.js Toolchain des SharePoint Framework schloss eine größere Verschiebung ab: Visual Studio Professional wich VS Code und dem Windows Subsystem for Linux als tägliche Entwicklungsumgebung.

Der Wechsel der Toolchain war nicht kosmetisch. Er nahm die Abhängigkeit von der Platform weg, die still jede frühere Entscheidung geprägt hatte. Ab da war die Arbeit portabel, kombinierbar und auf jene Unix-basierte Infrastruktur ausgerichtet, die Cloud-Native-Entwicklung verlangt. Die Frontend-Spezialisierung und der Cloud-Strang liefen zusammen, weil die Umgebung endlich zu beidem passte.

Diese terminalbasierte Umgebung machte den Schritt in die Azure-Entwicklung zum naheliegenden nächsten. Als die COVID-19-Pandemie kam, war ich einer der wenigen zertifizierten Azure Developers und Azure DevOps Engineers, die über verteilte Umgebungen in Europa und im Nahen Osten hinweg gearbeitet haben. Ich habe verteilte Systeme auf Azure Container Apps entworfen, mit Dapr für Service-to-Service-Kommunikation, State Management und Distributed Application Patterns. .NET Aspire lieferte Orchestration und Observability über die Microservices hinweg. CI/CD-Automatisierung und Infrastructure-as-Code wurden in allen Projekten zum Standard.

Die Pandemie nahm die Wahlfreiheit weg. Unternehmen, die Cloud-Native-Infrastruktur als architektonische Vorliebe behandelt hatten, merkten binnen Wochen, dass sie zur betrieblichen Notwendigkeit geworden war. Verteilte Systeme, aus technischer Strenge gebaut, waren plötzlich für Business Continuity gefragt. In diesem Stack zu diesem Zeitpunkt zu stehen war kein Zufall. Es war das direkte Ergebnis von sechs Jahren Aufbau an der Infrastruktur.

Die frühe Arbeit mit Azure Cognitive Services hat den AI-Strang eröffnet. Ab da liefen zwei Fäden. Semantic Kernel, Copilot Studio und Microsoft Foundry haben die Agentic-AI-Seite aufgebaut. GitHub Copilot, seit dem ersten öffentlichen Release im Einsatz, die Seite des Agentic Software Engineering.

Heute laufen diese Fäden in der Arbeit zusammen. Microsoft Agent Framework ist der Ort, an dem sie sich treffen: mehrstufige autonome Workflows, gebaut mit der architektonischen Disziplin, die dreißig Jahre auf der Microsoft Platform möglich machen. Anthropic Claude ist ein wesentlicher Teil dieses Stacks.

Diese Beweglichkeit über Stacks hinweg baue ich seit dreißig Jahren auf, und der Name integrations.at steht genau dafür.