Power Platform für komplexe Unternehmenslösungen architektonisch gestalten mit Ian Tweedie [MVP]

Microsoft Power Platform wird oft als Low-Code-Plattform beschrieben. Doch was passiert, wenn die Anwendungen, die Sie erstellen, geschäftskritisch, stark integriert und zu komplex für einen einfachen, Maker-orientierten Ansatz werden?In dieser Folge von M365 FM spricht Mirko Peters mit dem Power Platform Solution Architect Ian Tweedie darüber, was geschieht, wenn Power Platform über einfache Low-Code-Anwendungen hinauswächst und Teil einer ernsthaften Unternehmensarchitektur wird.

LOW-CODE BEDEUTET NICHT LOW ARCHITECTURE
Power Platform kann einen großen Teil des geschäftlichen Nutzens schnell liefern, doch Unternehmenslösungen enthalten fast immer Anforderungen, die über die Standardfunktionen von Low-Code hinausgehen.Ian erklärt, warum Low-Code niemals mit No-Code verwechselt werden sollte – und warum traditionelle Prinzipien der Softwarearchitektur auch beim Entwickeln mit Power Apps, Power Automate, Dataverse, benutzerdefinierten Konnektoren, APIs und Azure-Diensten weiterhin wichtig sind.

WENN POWER PLATFORM ZUR UNTERNEHMENSSOFTWARE WIRD
Zwischen „Low-Code“ und „Unternehmen“ gibt es nicht zwingend eine klare Grenze.Die Komplexität steigt, sobald Anwendungen mehrere Benutzerreisen, Entwicklungsteams, Integrationen, Sicherheitsanforderungen, geschäftskritische Prozesse und miteinander verbundene Dienste umfassen.Ab diesem Punkt wird Architektur unverzichtbar.Ian erläutert, warum Lösungen in klar definierte Features und Module mit sauberen Schnittstellen aufgeteilt werden sollten, anstatt zu einer großen, miteinander verflochtenen Anwendung zu werden.

DEM PROBLEM DER „WHACK-A-MOLE“-ENTWICKLUNG ENTKOMMEN
Man behebt einen Fehler, und an einer anderen Stelle taucht ein neuer auf.Dieses bekannte Entwicklungsproblem ist häufig ein Symptom einer eng gekoppelten Architektur.Ian erörtert, wie modulares Design Funktionalität isolieren und ungewollte Abhängigkeiten reduzieren kann. Am Beispiel der E-Mail-Zustellung zeigt er, wie die Trennung von Geschäftsprozessen und Zustellmechanismen Anwendungen leichter testbar, wartbar, austauschbar und skalierbar machen kann.

LOW-CODE + PRO-CODE = HYBRIDE ARCHITEKTUR
Power Platform muss nicht mit der klassischen Softwareentwicklung konkurrieren.Ein Power-Apps-Frontend kann nur einen kleinen Teil einer deutlich größeren Anwendung darstellen, die Azure, AWS, GCP, APIs oder benutzerdefinierte Dienste nutzt.Die entscheidende architektonische Frage lautet nicht, ob etwas „Low-Code“ oder „Pro-Code“ ist.Sie lautet vielmehr, welche Technologie für jedes einzelne Feature am besten geeignet ist.

CITIZEN DEVELOPER, MAKER UND ARCHITEKTUR
Citizen Developer bringen etwas äußerst Wertvolles mit: tiefes Wissen über die Geschäftsprozesse, mit denen sie täglich arbeiten.Geschäftliche Fachkompetenz lässt sich jedoch nicht automatisch in eine gute Anwendungsarchitektur übersetzen.Ian diskutiert, wie man ein Gleichgewicht zwischen der Befähigung von Makern und einem ausreichenden Maß an Architektur, Governance, Normalisierung und technischer Prüfung findet, damit Lösungen nicht schwer wartbar werden.

GOVERNANCE OHNE INNOVATION ZU ERSTICKEN
Zu wenig Governance erzeugt Chaos.Zu viel Governance erzeugt Reibung – und kann Mitarbeitende zu nicht unterstützten Workarounds, Tabellenkalkulationen, VBA und Schatten-IT treiben.Die Herausforderung besteht darin, das richtige Maß an Governance zu finden, abhängig von organisatorischem Risiko, Kritikalität der Anwendung, Nutzern und geschäftlichen Auswirkungen.

POWER PLATFORM, APIs UND AZURE
Wo sollte die Geschäftslogik liegen?Sollten Geheimnisse innerhalb von Power Platform gespeichert werden? Wann sollten Azure Key Vault, Azure Functions oder API Management Teil der Architektur werden?Ian erklärt, warum die Architektur stets mit dem zu lösenden Problem beginnen sollte, anstatt Azure-Dienste nur deshalb hinzuzufügen, weil sie verfügbar sind.

GIT, QUELLCODEVERWALTUNG UND CI/CD
Da die Entwicklung mit Power Platform immer stärker kollaborativ wird, gewinnen traditionelle Entwicklungspraktiken zunehmend an Bedeutung.Das Gespräch behandelt Git, Repositories, Entwicklungsumgebungen, Pipelines, Quellcodeverwaltung, Feature-Isolation, Querabhängigkeiten und CI/CD.Es gibt in Power Platform nicht immer einen perfekten Ansatz für die Quellcodeverwaltung – manchmal geht es darum, für das Projekt die „am wenigsten schlechte Option“ zu wählen.

IANS POWER-PLATFORM-ARCHITEKTUR-LEITFADEN

Ians zentraler Grundsatz ist einfach:Lösungen in Features und Module aufteilen.Jedes Feature sollte einen klaren Existenzgrund haben und idealerweise genau eine bestimmte Verantwortung übernehmen.Anschließend wird festgelegt, wie diese Features miteinander kommunizieren, wo die Logik ausgeführt werden soll, wie sie getestet werden sollten und welche Technologie sich für ihre Umsetzung am besten eignet.

DIE SCHNELLE FRAGERUNDE
Mirko stellt Ian eine Reihe kurzer Fragen:Sollte jede Unternehmensanwendung Dataverse verwenden?Kann Power Platform geschäftskritische Anwendungen erstellen?Kann Power Automate Logic Apps ersetzen?Reduziert Low-Code automatisch technische Schulden?Kann Power Platform die klassische Anwendungsentwicklung ersetzen?Und vielleicht am wichtigsten: Was sollte man bestellen, wenn man Newcastle besucht?

FAZIT
Low-Code bedeutet nicht geringe Architektur.Je größer, vernetzter und geschäftlich wichtiger Power-Platform-Lösungen werden, desto relevanter bleiben die Grundlagen der Softwareentwicklung.Architektur ist wichtig.Datenmodellierung ist wichtig.Governance ist wichtig.Sicherheit ist wichtig.API-Design ist wichtig.DevOps ist wichtig.Und erfolgreiche Power-Platform-Entwicklung im Unternehmen dreht sich zunehmend darum, zu verstehen, wie Low-Code, Pro-Code, Azure, APIs, Automatisierung und traditionelle Softwareentwicklungspraktiken zusammenwirken.

Unterstützen Sie diesen Podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.