Power Platform vs. klassische Programmierung

Vorteile und Grenzen von Low-Code 

Die Entwicklung von Individualsoftware zur Abbildung von Business-Prozessen hat in den letzten Jahren einen bemerkenswerten Wandel durchlaufen – insbesondere im Microsoft-365-Umfeld rund um SharePoint. Dabei stellt sich zunehmend die Frage, welche Entwicklungsplattform den größten Mehrwert für Unternehmen bietet.

Bislang kamen vor allem klassische Softwareentwicklungsansätze zum Einsatz, etwa Lösungen auf Basis von SPFx-Webparts in Kombination mit Azure Functions. Mit der Einführung und stetigen Weiterentwicklung der Microsoft Power Platform steht jedoch eine leistungsfähige Low-Code-Alternative zur Verfügung, die immer mehr an Bedeutung gewinnt.

In diesem Blogbeitrag beleuchten wir, ob sich Low-Code-Anwendungen – etwa mit Power Apps und Power Automate – im Vergleich zu klassischen Entwicklungsansätzen lohnen. Wie unterscheiden sich die beiden Ansätze in Bezug auf Entwicklungsaufwand, Erweiterbarkeit, Betrieb und Wartung (insbesondere bei Fehlersuche und Bugfixing) sowie in der Kostenstruktur? Wir geben Ihnen einen fundierten Überblick und unterstützen Sie bei der Wahl der passenden Architektur für Ihr nächstes Projekt.

Low-Code vs. klassische Entwicklung: Ein Vergleich typischer Architekturen  

Eine häufig eingesetzte traditionelle Softwarearchitektur besteht in der Kombination von clientseitigen SharePoint Webparts mit SPFx und React für das Frontend sowie Azure Functions in C# als Backend. Alternativ zu SharePoint Webparts können auch Microsoft Teams Apps eingesetzt werden.

Im Vergleich dazu betrachten wir die Low-Code-Entwicklungsplattform von Microsoft, bei der Power Apps (Canvas Apps) als Frontend und Power Automate (Cloud Flows) als Backend genutzt werden. Beide Ansätze haben ihre Berechtigung, und in diesem Beitrag beleuchten wir die jeweiligen Vor- und Nachteile.

Unter Low-Code versteht man einen Entwicklungsansatz, der entweder ohne klassische Programmiersprachen auskommt oder nur einen minimalen Anteil an Code erfordert. Auf dem Markt existieren verschiedene Plattformen für diesen Ansatz – beispielsweise von Microsoft, Salesforce oder AWS.

Die großen Stärken von Low-Code liegen in der beschleunigten Entwicklung und der potenziellen Kosteneinsparung.

Die folgende Tabelle basiert auf Erfahrungen aus Kundenprojekten und vergleicht die beiden Ansätze anhand konkreter Kriterien.

	Power Platform	SPFx und Azure Functions
Entwicklungsaufwand	Gering	Mittel bis hoch
Erweiterbarkeit	Abhängig von Premium Lizenzen	Flexibel
Komplexität der Anwendung	Einfache Use Cases	Einfache und komplexe Use Cases
Betrieb, Wartung und BugFixes	Teilweise umständlich	Folgt Standards
Lizenz- und Plattformkosten	Gering (außer wenn Premium Lizenzen notwendig sind)	Gering (verschiedene App Pläne verfügbar)

Der Citizen Developer Ansatz: Potenziale und Herausforderungen

Auch wenn auf den ersten Blick die Power Platform als ideale Lösung für die Umsetzung von Unternehmensanwendungen erscheint, sollte man sich der Vor- und Nachteile von Low-Code-Lösungen bei der Architekturentscheidung bewusst sein, um eine langfristig erfolgreiche Anwendung entwickeln zu können.

Der initiale Entwicklungsaufwand ist in der Regel deutlich geringer als bei einer traditionellen Code-Lösung. Besonders der Citizen Developer-Ansatz, bei dem fachliche Mitarbeiter aus den Fachabteilungen in den Entwicklungsprozess eingebunden werden, wird häufig hervorgehoben. Dies geschieht jedoch meist nur im Zusammenhang mit der Automatisierung persönlicher Arbeitsabläufe.

Warum der Citizen Developer Ansatz häufig scheitert

• Zu wenig Zeit neben dem eigenen Tagesgeschäft  
• Häufig geringes technische Verständnis  
• Wenig oder kein Wissen über Standards / Best-Practices 
• Komplexe Anwendungsfälle 
• Keine Erfahrungen im Bereich Bug-Fixes und Betrieb 

Den meisten Mitarbeitern aus den Fachabteilungen fehlt zum einen die Zeit, um sich mit einer Entwicklungsplattform intensiv zu beschäftigen. Häufig übersteigt die Komplexität der Use-Cases das Können der Citizen Developer. Auch die notwendige Erfahrung im Bereich Softwareentwicklung und Best Practices fehlen den meisten fachlichen Mitarbeitern. Geht es um Betrieb und Fehlersuche, stoßen viele an ihre Grenzen.

Die Übernahme des Betriebs durch die IT kann eine Herausforderung darstellen. Zusätzlich stellen die meisten Unternehmen diverse Anforderungen an business-kritische Anwendungen, die ohne Projektmanagement und professionelle Softwareentwickler kaum realisierbar sind. Hier lohnt es sich, genau hinzuschauen, ob eine Anwendung für den Citizen Developer Ansatz geeignet ist oder eine Übernahme des Projektes durch ein professionelles Entwicklungsteam notwendig ist.

Center of Excellence: Unterstützung für Citizen Developer 

Unter einem Center of Excellence (CoE) wird ein Team oder eine organisatorische Einheit verstanden, die sich auf die Verteilung und Entwicklung von Fachwissen sowie Best Practices für bestimmte Themen konzentriert. Darunter fällt das Anbieten von Schulungen, die Bereitstellung von Wissensressourcen und die Unterstützung der Citizen Developer in den Fachabteilungen. Die Einrichtung eines Center of Excellence für die Power Platform stellt eine gute Möglichkeit dar, den Risiken durch den Citizen Developer Ansatz zu begegnen. Kommen die Mitarbeiter in den Fachabteilungen nicht weiter, können sie sich technische Unterstützung holen. Die Mitarbeiter des Center of Excellence haben neben der Unterstützung der Fachabteilungen einen Fokus auf der Entwicklung von Best Practices und der Etablierung von einheitlichen Standards zur Sicherung der Qualität.

Grenzen des Low-Code-Ansatzes durch Premium-Lizenzen

Im Laufe eines Anwendungslebenszyklus kommt es häufig zu Erweiterungen – manchmal schon während der initialen Entwicklungsphase. Auf der Power Platform kann fast alles umgesetzt werden. Die Möglichkeiten sind nahezu grenzenlos. Für die meisten Funktionen benötigen die Nutzer jedoch Premium-Lizenzen, die in den normalen Abonnements (z. B. Microsoft 365 E3 / E5) nicht enthalten sind und zusätzlich pro Benutzer erworben werden müssen. Die Dauerkosten wollen viele Unternehmen nicht zahlen und beschränken sich deshalb auf die Standard-Funktionalitäten der Power Platform. Nutzt man Dynamics 365 im Unternehmen, sieht die Situation anders aus. Die Premium-Funktionalitäten sind in den meisten Dynamics-Lizenzen enthalten. Die Integration von Dynamics 365 und der Power Platform ist hervorragend und stellt einen großen Mehrwert für Unternehmen mit Dynamics 365 dar.  

Häufig gehen Unternehmen ohne Dynamics 365-Lizenzen Kompromisse ein, um die zusätzlichen laufenden Kosten für Power Platform Premium-Lizenzen zu umgehen. Einige Anforderungen werden zurückgestellt und niemals umgesetzt. Wenn bei Erweiterungen der Anwendungen auffällt, dass neue Funktionalitäten nur mit Premium-Funktionalitäten möglich sind, gibt es eigentlich nur drei Möglichkeiten:  

• Verzicht auf die neuen Funktionalitäten
• Zahlung der laufenden Kosten für Premium-Lizenzen
• Neuentwicklung auf einer anderen Architektur  

An dieser Stelle ist eine Abwägung der Möglichkeiten eine Frage von Kosten und Nutzen für das Unternehmen. Aus diesem Grund empfehlen wir, bei Anwendungen, deren Funktionsumfang und mögliche Erweiterungswünsche in der Zukunft noch nicht zu Beginn klar sind, eine Architektur zu wählen, deren Erweiterbarkeit unabhängig vom Lizenzmodell ist und flexible Möglichkeiten bietet.

Datenhaltung: Wo werden die Daten gespeichert? 

In dieser Aufstellung wurde bisher nicht die Frage nach der Datenbank gestellt. Wo werden Anwendungsdaten auf der Power Platform gespeichert? Hier bietet die Power Platform diverse Möglichkeiten in Form von Konnektoren. Angefangen mit SharePoint, das in vielen Anwendungen genutzt wird, da es sich um einen Standard Konnektor handelt. Jedoch gibt es hier bei größeren Datenmengen (ab 2000 Elemente) Probleme bei bestimmten Abfragen – die Ergebnisse von komplexen Abfragen können unvollständig sein, wenn Filterungen oder Sortierungen verwendet werden.   

Dataverse, die Datenplattform der Power Platform, wird in den Learn-Artikeln und auf der Benutzeroberfläche der Power Platform in den Fokus gerückt – jedoch befindet man sich mit Dataverse direkt im Premium Lizenzbereich. Auch die Datenbankgröße ist sehr limitiert und kann nur gegen zusätzliche Kosten erweitert werden. Hier hat sich das Lizenzmodell in den letzten Jahren immer Mal wieder geändert. Nicht immer zum Vorteil der Kunden. Es gibt jedoch auch Konnektoren zu klassischen Datenbanken, wie z.B. SQL Datenbanken. Zu Beginn der Power Apps Zeit war der SQL Konnektor im Standard enthalten. Mittlerweile kann der SQL Konnektor nur noch von Nutzern mit Premium Lizenzen verwendet werden.  

Je nach Business Case sollte die Verbindung eines Power Automate Flows oder Power App mit einer Datenbank kritisch hinterfragt werden: 

• Wird für die Anmeldung ein technischer Account oder der Nutzer der App verwendet? 
• Wie werden die Berechtigungen für lesende oder schreibende Zugriffe sichergestellt? 

Die Implementierung von Berechtigungen ist Teil der Business Logik und wird in normalerweise im Backend abgebildet. Das sorgt dafür, dass sich die Datenbank in einem inhaltlich konsistenten Zustand befindet. Power Apps in Kombination mit Power Automate geraten dabei schnell an ihre Grenzen. Dies verdeutlicht ein Blick auf die gängige Architektur einer Power Platform Lösung bestehend aus einer Canvas App und mehreren Power Automate Flows: 

Direkter Datenzugriff und Berechtigungen bei SharePoint als Datenspeicher

In der Regel werden die Daten direkt als Datenquelle in Power Apps eingebunden. Abfragen und Speichervorgänge werden direkt von der App an die Datenbank gesendet. Dabei müssen die Berechtigungen der Datensätze direkt in der Datenbank implementiert sein. Für SharePoint bedeutet das, Berechtigungen auf Zeilenebene ist nur für eine begrenze Anzahl von Individualberechtigungen möglich und kommt bei großen Datenmengen schnell an seine Grenzen. Berechtigungen für einzelne Felder können überhaupt nicht umgesetzt werden.  

Im Backend wird die Business-Logik wie das Versenden von E-Mails, Erinnerungsfunktionen und Genehmigungen umgesetzt. Ein Teil der Flows wird mit Triggern direkt aus der Power App aufgerufen, ein anderer Teil wird in der Regel automatisiert ausgeführt, z.B. wenn ein neuer Eintrag in SharePoint gespeichert wird.  

Am Beispiel von SharePoint Listen als Datenspeicher würde das bedeuten, dass die Nutzer direkten Zugriff auf die Daten in SharePoint brauchen, um die Daten in Power Apps oder Power Automate nutzen zu können. Rufen die Nutzer die SharePoint Website auf, können sie entsprechend ihrer Berechtigungen auch hier die Daten sehen, bearbeiten und löschen. So können die Nutzer evtl. implementierte Business Logik aus der Power App oder den zugehörigen Flows umgehen. SharePoint bietet Möglichkeiten, Listen vor den Nutzern zu verstecken, jedoch können geübte Nutzer trotzdem auf die Daten zugreifen.  

Fehlerhandling in Power Platform vs. klassischer Entwicklung  

Möchte man in Power Apps oder Power Automate ein Fehlerhandling implementieren, das gängige Standardfehler abdeckt, steigt die Komplexität schnell erheblich an. Aus einem ursprünglich 10 Schritte umfassenden Flow werden ohne Weiteres 30 Schritte oder mehr. Fehlerbehandlungsblöcke wiederholen sich dabei häufig mehrfach innerhalb eines Flows und lassen sich nur schwer auslagern.

Der Versuch, wiederkehrende Fehlerhandling-Elemente in Parent- und Child-Flows auszulagern, führt in der Praxis oft zu Problemen. Dies unterscheidet sich deutlich von klassischen Code-Projekten, in denen Funktionen mehrfach und flexibel an verschiedenen Stellen aufgerufen werden können.

Die Möglichkeiten zur Implementierung von Fehlerlogging sind in klassischen Entwicklungsprojekten vielfältig und erfordern meist nur einen geringfügigen Mehraufwand. Im Gegensatz dazu ist der Aufwand, ein aussagekräftiges und nachvollziehbares Logging in Power Automate Flows umzusetzen, deutlich höher. 

Vorteile eines SPFx Webparts mit Azure Functions Backend 

Neben der Flexibilität in der Erweiterbarkeit liegt ein großer Vorteil darin, dass insbesondere komplexe Business Cases mit einem detaillierten Berechtigungskonzept auf Ebene einzelner Datensätze umgesetzt werden können. Dabei fungiert das SPFx-Webpart im Frontend ausschließlich als Anzeigeelement, während die gesamte Business-Logik im Backend abgebildet wird.

Diese klare Trennung von Frontend und Backend verbessert die Wartbarkeit und Skalierbarkeit der Anwendung erheblich. Beide Bereiche können unabhängig voneinander entwickelt und optimiert werden. Die Kommunikation erfolgt über standardisierte Schnittstellen, was die Wiederverwendbarkeit der einzelnen Komponenten fördert.

Zudem trägt diese Architektur zu einer höheren Sicherheit bei: Sensible Daten werden im Backend verarbeitet und über eine geschützte API nur an authentifizierte und autorisierte Benutzer entsprechend ihrer Rollen in der Anwendung übermittelt.

Die Grafik zeigt die klassische Architektur bestehend aus Frontend zur Anzeige und Backend mit Business-Logik und Datenbankzugriff: 

Die im Microsoft 365 angemeldeten Nutzer rufen die Seite mit dem SPFx Webpart auf. Dabei sendet das Frontend eine Anfrage inklusive Nutzerkontext an das Backend und erhält als Antwort die Rolle des aktuellen Nutzers sowie die initial anzuzeigenden Daten. Das Backend prüft anhand der hinterlegten Business-Logik, auf welche Daten der Nutzer in seiner jeweiligen Rolle Zugriff hat.

Alle Datenzugriffe erfolgen ausschließlich im Backend – im Fall von SharePoint über eine Entra App-Registrierung. Das bedeutet, dass die Nutzer keinen direkten Zugriff auf die Datenbank haben. Die Berechtigungen müssen somit nicht auf Datenbankebene, sondern flexibel im Backend gemäß der Business-Logik umgesetzt werden. Sowohl lesender als auch schreibender Zugriff auf einzelne Felder, basierend auf der Rolle oder dem Status eines Vorgangs, lassen sich so unkompliziert realisieren.

Auch der Zugriff auf weitere Daten aus Microsoft 365, etwa SharePoint-Websites, Teams oder Kalendereinträge, kann über die Entra App-Registrierung eingerichtet werden. Dies ermöglicht eine flexible Erweiterbarkeit und nahtlose Integration der Anwendung in den Arbeitsalltag.

Ausblick: Welche Lösung passt zu welchem Anwendungsfall?

Die Power Platform ist eine wertvolle Ressource für Unternehmen, die schnell einfache Lösungen umsetzen möchten. Für langfristig stabile Anwendungen sollte jedoch der Aufwand für Betrieb, Wartung und Erweiterungen nicht unterschätzt werden.

Bei komplexeren Anforderungen, insbesondere wenn Premium-Funktionalitäten erforderlich sind, empfiehlt sich eine flexible Architektur wie SPFx in Kombination mit Azure Functions. Sie ermöglicht eine klare Trennung von Frontend und Backend sowie ein robustes Berechtigungskonzept – ideal für den sicheren Umgang mit sensiblen Daten.

Zusammenfassung 

• Vergleich von Low-Code und klassischer Softwareentwicklung: Beide Ansätze haben ihre Vor- und Nachteile. 
• Risiken des Citizen Developer Ansatzes: Mitarbeiter in den Fachabteilungen haben häufig unzureichende Ressourcen und technisches Verständnis. 
• Kosteneffizienz vs. langfristige Aufwände: Kurzfristige Vorteile können durch spätere Betriebskosten überschattet werden. 
• Handlungsempfehlung: Die Einrichtung eines Center of Excellence hilft den Mitarbeiter in Fachabteilungen ihre eigenen Anwendungen und Automatisierungen im Arbeitsalltag zu entwickeln. 
• Architekturberatung: Die Herausforderung liegt in der Wahl der richtigen Plattform für die passenden Use Cases und frühzeitig Risiken und KO-Kriterien zu identifizieren.  

Sie stehen vor der Entscheidung zwischen Low-Code und klassischer Entwicklung? Unsere Experten helfen Ihnen dabei, die richtige Architektur für Ihre individuellen Anforderungen zu finden. Kontaktieren Sie uns für eine unverbindliche Beratung und profitieren Sie von unserer Erfahrung in der Entwicklung maßgeschneiderter Lösungen!