Low-Code Development Services-Programm: Ein Leitfaden für Käufer

Gartner prägte 2014 den Begriff „Low-Code“, und seitdem hat sich der Markt in verschiedene Servicekategorien gespalten, die sich in Bezug auf Kosten, Kontrolle und Bindung sehr unterschiedlich verhalten.

Low-Code-Entwicklungsdienstprogramme bündeln drei Dinge, die in der traditionellen IT normalerweise separat verkauft werden: eine visuelle Entwicklungsplattform, die darauf aufbauenden professionellen Dienste und den fortlaufenden Support, um die resultierenden Anwendungen am Laufen zu halten. Käufer, die verstehen, dass man bei einer Bündelung jede Ebene unabhängig aushandeln kann – und hier wird der größte Teil des Werts gewonnen oder verloren.

Die Plattformschicht ist das Werkzeug: Drag-and-Drop-Formularersteller, Datenmodelldesigner, Workflow-Engines, API-Konnektoren und Bereitstellungspipelines. Zu den genannten Beispielen gehören Microsoft Power Apps, OutSystems, Mendix, Appian, Retool, Budibase und – für Teams, die bereits in das 4D-Ökosystem investiert haben – 4Ds eigene Form-, Methoden- und Datenmodell-Tools.

Die Serviceschicht ist die menschliche Arbeit: Entdeckungsworkshops, Datenmodellierung, Integration, Tests und Übergabe. Die Support-Ebene ist das, was nach dem Go-Live passiert: Überwachung, Änderungsanfragen, Versions-Upgrades und Benutzerschulung.

Ein Low-Code-Entwicklungsdienstprogramm unterscheidet sich von einem einmaligen Projekt in einem wichtigen Punkt: Es setzt eine wiederholte Lieferung voraus. Anstatt eine einzelne App in Auftrag zu geben, richtet der Käufer eine dauerhafte Funktion ein – ein Governance-Modell, eine wiederverwendbare Komponentenbibliothek und einen Bereitstellungsrhythmus – sodass die zweite App weitaus weniger kostet als die erste. Diese Wiederverwendungsökonomie ist die einzige Rechtfertigung für die Formulierung des „Programms“.

Die vier Servicemodelle im Vergleich

Low-Code-Entwicklungsdienste gibt es in verschiedenen Formen, die für sehr unterschiedliche Organisationen geeignet sind. Die folgende Tabelle ist die Entscheidungshilfe, die die meisten Käufer benötigen, bevor sie mit einem Anbieter sprechen.

Verwandte: Claris FileMaker Pro — Die langlebige relationale Datenbankplattform für Teams, die benutzerdefinierte Apps auf Desktop, Web und Mobilgeräten aus einer einzigen Datei benötigen..

Modell	Typischer Käufer	Kontrolle	Kostenprofil	Hauptrisiko
Staff augmentation	IT-Team mit Plattformkompetenzlücken	Hoch – Sie leiten die Arbeit	Stunden- oder Monatssatz	Das Wissen bleibt beim Auftragnehmer
Fixed-scope project	Abteilung mit einer definierten App	Niedrig während der Erstellung	Festpreis pro App	Änderungswünsche werden separat in Rechnung gestellt
Verwaltete Anwendungsdienste	Betriebsteam, das Live-Apps ausführt	Niedrig bis mittel	Wiederkehrende Pauschale	Langsame Reaktion auf neue Anforderungen
Plattform + Enablement-Partnerschaft	Organisation baut interne Fähigkeiten auf	Mittelgroß, wächst mit der Zeit	Gemischt: Plattform, Schulung, Aufbau	Erfordert interne Mitarbeiterzeit zur Aufnahme

Die Personalaufstockung eignet sich für Teams, die bereits über einen Plattformstandard und einen Rückstand verfügen. Projekte mit festem Umfang eignen sich für einen einzigen hochwertigen Workflow mit stabilen Anforderungen. Managed Services eignen sich für regulierte Umgebungen, in denen Verfügbarkeit und Audit-Trails wichtiger sind als Geschwindigkeit. Enablement-Partnerschaften eignen sich für Organisationen, die Dutzende von Apps erstellen möchten und die Fähigkeit intern benötigen.

Eine praktische Regel: Wenn der Käufer in achtzehn Monaten nicht benennen kann, wer die Anwendung besitzen wird, wird das Programm aus dem falschen Grund gekauft. Programme für Low-Code-Entwicklungsdienste scheitern meist nicht, weil die Plattform falsch war, sondern weil nie ein interner Eigentümer zugewiesen wurde.

Wie sich Low-Code- und No-Code-Dienste in der Praxis unterscheiden

Low-Code- und No-Code-Entwicklungsdienste werden häufig als eine Kategorie vermarktet, aber die beiden Hälften legen unterschiedliche Einschränkungen für einen Dienstleistungsauftrag fest. No-Code-Tools richten sich an Geschäftsanwender, die Anwendungen konfigurieren, ohne Logik zu schreiben. Bei Low-Code-Tools wird davon ausgegangen, dass ein Entwickler die Plattform mit Code erweitert, wenn der visuelle Builder nicht mehr verfügbar ist.

Unsere Wahl: Airtable — Eine einfache Tabellenkalkulationsschnittstelle, die auf einer echten relationalen Datenbank aufbaut, mit Automatisierungen, Ansichten und gemeinsam nutzbaren Schnittstellen..

Diese Unterscheidung ändert den Dienstleistungsvertrag. Ein No-Code-Einsatz besteht hauptsächlich aus Konfiguration, Schulung und Governance – die Aufgabe des Anbieters besteht darin, Bürgerentwickler innerhalb sicherer Grenzen zu halten. Bei einem Low-Code-Einsatz kommen Integrationstechnik, benutzerdefinierte Komponenten, Leistungsoptimierung und CI/CD-Setup hinzu, da von den Anwendungen erwartet wird, dass sie Produktionssysteme berühren und skalieren.

Die meisten Unternehmensprogramme sind letztendlich hybrid. Eine No-Code-Ebene verwaltet Abteilungs-Tracker, Genehmigungsabläufe und Datenerfassung. Eine Programmebene für Low-Code-Entwicklungsdienste kümmert sich um alles, was in ein Kernsystem schreibt, komplexe Geschäftsregeln durchsetzt oder einen Prüfpfad benötigt. Anbieter, die nur eine Stufe verkaufen, schieben alle Anforderungen in diese Stufe, was bei der Festlegung des Umfangs im Auge behalten werden sollte.

Wie ein echtes Engagement aussieht, Phase für Phase

Die Bereitstellung von Low-Code-Entwicklungsdiensten folgt einem erkennbaren Bogen, und wenn ein Käufer die Phasen kennt, kann er einen Anbieter erkennen, der die teuren Phasen überspringt.

Erkennung und Datenmodellierung. Der Anbieter bildet den Geschäftsprozess ab, identifiziert die Entitäten und Beziehungen und entscheidet, was in der Low-Code-Plattform verbleibt und was im Aufzeichnungssystem verbleibt. Die meisten Nacharbeiten entstehen in der Datenmodellierung. Ein Formular, das auf einem falschen Entitätsmodell basiert, wird neu erstellt und nicht gepatcht.

Prototyp und Validierung. Innerhalb der ersten Wochen wird ein funktionierender Prototyp echten Benutzern präsentiert. Low-Code-Plattformen machen dies kostengünstig, und ein Anbieter, der nicht schnell einen anklickbaren Prototypen erstellen kann, nutzt den Hauptvorteil der Plattform nicht aus.

Build und Integration. Bildschirme, Workflows, Wertelisten und API-Verbindungen werden zusammengestellt. In jeder ehrlichen Schätzung ist die Integration in der Regel der größte Einzelposten, da Authentifizierung, Fehlerbehandlung und Datensynchronisierung nie so einfach sind, wie die Demo vermuten lässt.

Verwandte: Knack — Ein Datenbank-Builder ohne Code für Portale, Verzeichnisse und interne Tools – mit Pauschalpreisen statt Gebühren pro Benutzer..

Testen und Härten. Rollenbasierter Zugriff, Eingabevalidierung, Parallelitätsverhalten und Leistung unter realistischen Datenmengen werden überprüft. Low-Code-Plattformen verbergen die Komplexität, was dazu führt, dass Leistungsprobleme oft erst spät auftauchen.

Bereitstellung und Übergabe. Die Anwendung wird in die Produktion überführt und – was von entscheidender Bedeutung ist – Dokumentation, Administratorschulung und die Übertragung eines Änderungsanfrageprozesses an das interne Team.

Operieren und iterieren. Das Low-Code-Entwicklungsserviceprogramm wird mit einem Rückstand, einem Release-Rhythmus und regelmäßigen Plattform-Upgrades fortgesetzt. Plattformanbieter liefern neue Versionen nach ihrem eigenen Zeitplan aus, und jemand muss diese Änderungen übernehmen.

Leserfavorit: Microsoft Power Apps — Low-Code-App-Entwicklung auf Unternehmensniveau, vernetzt mit Microsoft 365, Dataverse und Power Automate..

Auswahlkriterien, die tatsächlich den Erfolg vorhersagen

Die Bewertung von Anbietern von Low-Code-Entwicklungsdiensten allein anhand der Markenbekanntheit führt zu kostspieligen Fehlern. Die folgenden Kriterien beziehen sich auf Low-Code-Entwicklungsdienstprogramme, die ihr zweites Jahr überleben.

• Kosten für Plattformausstieg. Fragen Sie, was mit der Anwendung passiert, wenn das Engagement endet. Können die Daten in ein verwendbares Format exportiert werden? Kann die Logik von jemand anderem gelesen werden? Proprietäre visuelle Logik stellt das größte Lock-in-Risiko in diesem Markt dar.
• Erfolgsbilanz bei der Integration. Fordern Sie zwei Referenzen an, die dieselbe Systemklasse betreffen, die Sie verbinden müssen – ein ERP, ein CRM, eine Legacy-Datenbank oder ein lokales Verzeichnis.
• Benanntes Team, kein Fähigkeitsdeck. Fragen Sie, wer die Arbeit tatsächlich erledigen wird und ob es sich bei diesen Personen um Mitarbeiter oder Subunternehmer handelt.
• Governance-Artefakte. Ein seriöses Programm erstellt eine Umgebungsstrategie, ein Zugriffskontrollmodell und eine Namenskonvention. Anbieter, die diese als optional betrachten, bauen zukünftige Unterhaltsschulden auf.
• Übergabeverpflichtung. Der Vertrag sollte Dokumentation, Administratorschulung und einen definierten Zeitraum für Post-Launch-Support festlegen.
• Preistransparenz. Es gibt Preise pro App, pro Benutzer, pro Stunde und für Retainer. Das Modell ist weniger wichtig als die Frage, ob der Anbieter Ihnen zeigt, wie die Nummer erstellt wurde.

Für die Due Diligence auf Plattformebene sind die von Unternehmen wie Gartner und Forrester veröffentlichten Analystenstudien ein sinnvoller Ausgangspunkt, und der Wikipedia-Eintrag zu Low-Code-Entwicklungsplattformen bietet einen neutralen Überblick über die Geschichte und Definitionen der Kategorie. Käufer in regulierten Branchen sollten auch die Haltung des Anbieters anhand des NIST Cybersecurity Framework überprüfen, das viele Beschaffungsteams in Unternehmen mittlerweile als gemeinsames Vokabular für Sicherheitsfragen verwenden.

Wo sich Low-Code-Programme wirklich auszahlen – und wo nicht

Low-Code-Entwicklungsdienstprogramme liefern die höchsten Erträge bei Anwendungen, die zahlreich, ähnlich und kurzlebig sind. Interne Antragsformulare, Genehmigungsworkflows, Inspektionschecklisten, Bestandsverfolgungen und Abteilungs-Dashboards passen in dieses Muster: Jedes ist klein, jedes teilt Komponenten mit seinen Geschwistern und jedes würde sonst monatelang in einem IT-Rückstand sitzen.

Programme haben Schwierigkeiten, wenn die Anwendung wirklich komplex ist. Transaktionssysteme mit hohem Volumen, Anwendungen mit komplizierten Parallelitätsanforderungen und alles mit starker Echtzeitberechnung werden in der Regel besser durch konventionelle Entwicklung bedient – ​​oder durch einen Hybrid, bei dem die Low-Code-Schicht die Schnittstelle übernimmt und ein herkömmlicher Dienst die Kernlogik übernimmt.

Ein zweites Fehlermuster ist der verlassene Pilot. Organisationen führen häufig einen erfolgreichen Machbarkeitsnachweis durch und geraten dann ins Stocken, weil niemand die Governance-Ebene finanziert hat. Der Pilot beweist, dass die Plattform funktioniert; es beweist nicht, dass das Programm funktioniert. Die Budgetierung der langweiligen Teile – Umgebungsmanagement, Sicherheitsüberprüfung, Schulung und Support – macht aus einem Pilotprojekt ein Programm.

Ein drittes Muster ist die Schattenausbreitung. Wenn Bürgerentwickler frei und ohne Komponentenbibliothek oder Überprüfungsprozess erstellen, kann es sein, dass ein Unternehmen am Ende Hunderte von nahezu doppelten Anwendungen hat und keine Bestandsaufnahme dessen hat, was vorhanden ist. Ein Dienstleistungsprogramm sollte vom ersten Tag an ein Anwendungsregister umfassen.

Build versus Buy: Wenn ein internes Programm ein externes übertrifft

Organisationen mit vorhandenen Entwicklungskapazitäten fragen sich manchmal, ob sie überhaupt externe Low-Code-Entwicklungsdienste benötigen. Die ehrliche Antwort hängt von drei Variablen ab: Wie viele Anwendungen sind geplant, wie ungewöhnlich sind die Integrationsanforderungen und ob die Plattform bereits standardisiert ist.

Ein internes Programm ist sinnvoll, wenn sich die Organisation auf eine Plattform festgelegt hat, mehr als eine Handvoll Anwendungen plant und mindestens einen erfahrenen Entwickler für die Plattformverantwortung einsetzen kann. Die Rolle des externen Anbieters beschränkt sich dann auf die anfängliche Befähigung und gelegentliche Facharbeit.

Ein externes Programm macht dann Sinn, wenn die Plattformentscheidung noch offen ist, wenn es bei den ersten Anwendungen um ungewohnte Integrationen geht oder wenn interne Mitarbeiter einfach nicht von bestehenden Verpflichtungen befreit werden können. In diesem Fall sollte der Vertrag mit einer expliziten Ausstiegsrampe verfasst werden – einem Punkt, an dem das interne Team übernimmt – und nicht mit einer unbefristeten Vereinbarung.

Teams, die auf 4D aufbauen, stehen oft im Mittelfeld. Das Datenmodell, die Formulare und Methoden sind dem internen Entwickler bereits vertraut, sodass externe Dienste für Integrationsarbeiten, Bereitstellungsarchitekturen und die Modernisierung älterer Binärstrukturen am wertvollsten sind. Das ist ein engeres Engagement als ein vollständiges Programm und sollte dementsprechend bepreist werden.

Quellen und weiterführende Literatur

• Low-Code-Entwicklungsplattform – Wikipedia: Eine Low-Code-Entwicklungsplattform (LCDP) bietet eine Softwareentwicklungsumgebung – typischerweise eine grafische Benutzeroberfläche (GUI) – die wenig oder gar kein Schreiben erfordert…

Häufig gestellte Fragen

Was ist ein Low-Code-Entwicklungsdienstprogramm?

Bei einem Low-Code-Entwicklungsdienstprogramm handelt es sich um eine dauerhafte Vereinbarung, bei der ein Anbieter sowohl eine Low-Code-Plattform als auch die professionellen Dienste zum Erstellen, Bereitstellen und Warten von Anwendungen darauf bereitstellt. Es unterscheidet sich von einem Einzelprojekt dadurch, dass es eine wiederholte Lieferung, gemeinsame Komponenten und ein fortlaufendes Governance-Modell voraussetzt. Käufer wählen in der Regel zwischen Personalaufstockung, Projekten mit festem Umfang, Managed Services und Enablement-Partnerschaften.

Wie viel kosten Low-Code-Entwicklungsdienste?

Für eine einzige verlässliche Zahl variieren die Preise zu stark, da sie von der Plattformlizenz, dem Auftragsmodell und der Komplexität der Integrationen abhängen. Anbieter bieten Angebote pro Stunde, pro Anwendung, pro Benutzer oder als monatliche Gebühr an, und die Plattformlizenzierung wird normalerweise separat von den Diensten abgerechnet. Der nützlichste Vergleich sind die Gesamtkosten pro bereitgestellter Anwendung in einer Multi-App-Roadmap und nicht die Gesamtrate.

Ist Low-Code-Entwicklung für Unternehmensanwendungen geeignet?

Low-Code eignet sich für Unternehmensanwendungen, die zahlreich, Workflow-gesteuert und integrationsintensiv sind – Genehmigungssysteme, Tracker, Portale und Abteilungstools. Es eignet sich weniger gut für hochvolumige Transaktionskerne, Echtzeitberechnungen und Systeme mit ungewöhnlichen Parallelitätsanforderungen. Viele Unternehmen betreiben einen Hybrid: Low-Code für die Schnittstellen- und Workflow-Ebene, konventioneller Code für die Kernlogik.

Was ist der Unterschied zwischen Low-Code- und No-Code-Entwicklungsdiensten?

No-Code-Dienste konzentrieren sich auf Konfiguration und Governance, sodass Geschäftsanwender ohne Programmierung sicher erstellen können. Low-Code-Dienste fügen Integrationstechnik, benutzerdefinierte Komponenten, Leistungsoptimierung und Bereitstellungspipelines hinzu, da von den Anwendungen erwartet wird, dass sie Produktionssysteme berühren. Die meisten Unternehmensprogramme arbeiten auf beiden Ebenen und leiten einfache Apps an No-Code und komplexe an Low-Code weiter.

Wie lange dauert die Bereitstellung einer Anwendung über ein Low-Code-Serviceprogramm?

Ein Prototyp kann häufig innerhalb der ersten Wochen gezeigt werden, und eine einfache Abteilungsanwendung erreicht die Produktion normalerweise innerhalb weniger Monate und nicht erst nach Quartalen. Wenn die Integrationen komplex sind, die Sicherheitsüberprüfung intensiv ist oder sich die Anforderungen während der Erstellung ändern, verlängern sich die Zeitpläne. Der eigentliche Geschwindigkeitsvorteil des Programms zeigt sich bei der zweiten und dritten Anwendung, sobald Komponenten und Governance vorhanden sind.

Was sollte ein Low-Code-Dienstleistungsvertrag beinhalten?

In einem Vertrag sollten das benannte Lieferteam, die Plattform- und Lizenzverantwortung, der Integrationsumfang, die Dokumentation und die Administratorschulung, ein definierter Supportzeitraum nach der Markteinführung sowie die Bedingungen festgelegt werden, unter denen der Käufer die Arbeit intern übernehmen kann. Datenexportrechte und die Lesbarkeit der benutzerdefinierten Logik verdienen eine explizite Formulierung, da sie bestimmen, wie teuer es ist, den Anbieter später zu verlassen.