Low-Code oder Eigenentwicklung: Wann sich Appian wirklich rechnet

Ein Fachbereich braucht eine Anwendung für einen Genehmigungs- oder Antragsprozess. Die erste Frage im Raum ist meist die falsche: „Welches Tool nehmen wir?" Die richtige Frage lautet, ob überhaupt eine Plattform wie Appian die passende Antwort ist oder ob klassische Eigenentwicklung besser trägt. Hier ist die Entscheidungshilfe, die ich Kunden und Kursteilnehmern gebe.

Die Frage hinter der Frage

Buy-or-Build klingt nach einer Tool-Auswahl, ist aber eine Architektur- und Kostenentscheidung über mehrere Jahre. Wer sie auf „Low-Code ist schneller" verkürzt, übersieht die eigentliche Abwägung: Man tauscht Entwicklungsfreiheit gegen Geschwindigkeit und eine Bindung an einen Plattformhersteller. Das kann ein hervorragender Handel sein oder ein teurer Fehler, je nachdem, was gebaut werden soll.

Ich entwickle seit über 20 Jahren genau die Art von Prozess- und Workflow-Anwendungen, um die es hier geht, früher in C# und Java, heute auch auf der Low-Code-Plattform. Ich habe die Rechnung also von beiden Seiten gesehen. Und die ehrliche Antwort ist selten „immer Low-Code" oder „immer selbst bauen", sondern hängt an einer Handvoll konkreter Merkmale des Vorhabens.

Was Appian als Plattform tatsächlich übernimmt

Der Wert einer Low-Code-Plattform steckt nicht im Schlagwort „kein Code". Er steckt in den Dingen, die man bei jeder Eigenentwicklung neu bauen müsste und die selten jemand sehen will, aber immer gebraucht werden:

• Authentifizierung, Rollen und Berechtigungen, ohne dass man ein eigenes Rechtesystem entwirft
• Audit-Trail und Nachvollziehbarkeit, wer wann was entschieden hat, in regulierten Umgebungen die halbe Miete
• Prozess-Steuerung: Aufgaben, Fristen, Eskalationen und Zuständigkeiten als modellierbare Abläufe statt als handverdrahteter Code
• Ein sauberes Datenmodell und Oberflächen, die zusammenpassen, statt in jedem Projekt neu zusammengesteckt zu werden
• Anbindung externer Datenquellen wie SQL Server, Oracle oder REST-Schnittstellen, sodass die Anwendung mit Bestandssystemen spricht

Bei einem prozessgetriebenen Vorgang, der durch mehrere Hände, Rollen und Freigaben läuft, spart das einen großen Teil der Arbeit, die in klassischer Entwicklung als „Infrastruktur" gilt und trotzdem Wochen kostet. Genau dort spielt Appian seine Stärke aus.

Low-Code heißt nicht No-Code

Ein Punkt, der in der Praxis regelmäßig unterschätzt wird und der auch in meinen Kursen immer wieder für Aha-Momente sorgt: „Low-Code" heißt nicht, dass gar nichts mehr geschrieben wird. Ablauf, Oberflächen und Datenmodell modelliert man visuell, aber die eigentliche Fachlogik schreibt man weiterhin selbst, als Ausdrücke und Regeln. Die Plattform nimmt einem das Gerüst ab, nicht das Denken.

2 Beispiele, die in echten Projekten sofort auftauchen:

• Validierungen. Ein Upload-Feld begrenzt nicht von allein die Dateigröße auf ein bestimmtes MB-Limit und lässt auch nicht automatisch nur erlaubte Dateitypen zu. Solche Regeln formuliert man selbst, sonst nimmt die Anwendung an, was man ihr gibt.
• Berechnungen. Die Anzahl der Tage eines Dienstreise-Antrags, Fristen, abgeleitete Beträge: jede fachliche Rechnung ist ein Ausdruck, den jemand schreiben und später auch pflegen muss.

Das ist kein Nachteil, sondern die Realität jeder Low-Code-Plattform. Es ist aber der Grund, warum ein Appian-Projekt trotzdem Entwickler-Denke braucht und warum „kein Code" beim Aufwand in die Irre führt. Der Gewinn liegt darin, dass die Infrastruktur wegfällt, nicht die Fachlogik. Wer das einplant, kalkuliert richtig. Wer eine No-Code-Wunderwelt erwartet, wird an genau diesen Stellen überrascht.

Wann Eigenentwicklung die bessere Wahl bleibt

Eine Plattform, die viel vorgibt, engt auch ein. In diesen Fällen ist Eigenentwicklung meist die tragfähigere Entscheidung:

• Hochspezialisierte oder rechenintensive Logik. Sobald der Kern der Anwendung eine ungewöhnliche Berechnung, eine eigene Engine oder sehr spezielle Algorithmen ist, arbeitet man gegen die Plattform statt mit ihr.
• Produkte für den Markt. Was Sie an Endkunden verkaufen oder als Kern Ihres Geschäftsmodells betreiben, gehört selten auf eine fremde Low-Code-Plattform, schon wegen der laufenden nutzerbasierten Kosten und der Abhängigkeit.
• Sehr viele Nutzer bei einfacher Fachlichkeit. Wenn Tausende Anwender eine simple Maske bedienen, kann eine nutzerbasierte Lizenzierung teurer werden als eine schlanke Eigenentwicklung.
• Volle Kontrolle über den Code ist Pflicht. In manchen Umgebungen muss der Quellcode im Haus liegen, prüfbar und ohne Plattformbindung. Das ist mit Low-Code naturgemäß schwer.

Wann Low-Code mit Appian gewinnt

Umgekehrt gibt es ein klares Profil, bei dem Appian regelmäßig die wirtschaftlichere und schnellere Lösung ist:

• Prozess statt Produkt. Interne Vorgänge wie Antragsstrecken, Genehmigungs- und Rechnungsworkflows, Onboarding, Case Management oder Fachverfahren, bei denen der Ablauf wichtiger ist als eine exotische Rechenlogik.
• Nachvollziehbarkeit ist gefordert. Überall, wo jeder Schritt dokumentiert und auditierbar sein muss, ist der mitgelieferte Audit-Trail bares Geld wert.
• Es muss schnell gehen. Wenn ein Vorgang heute über Excel und E-Mail läuft und niemand mehr weiß, wo er gerade hängt, bringt eine modellierte Anwendung in Wochen Ordnung, nicht in Monaten.
• Die IT will den technischen Unterbau abgeben. Serverbetrieb, Updates und Skalierung übernimmt die Plattform. Die Anwendung selbst muss trotzdem jemand kennen und betreiben, dazu weiter unten mehr.

Das ist bewusst dieselbe Grenzziehung, die ich auch im Beratungsgespräch mache: Ich sage Ihnen, wo die Plattform an ihre Grenze stößt, statt jeden Anwendungsfall hineinzuzwingen.

Der Kostenvergleich, den selten jemand offen macht

Die beiden Wege haben grundverschiedene Kostenprofile und genau das wird in Entscheidungen oft vermischt. Low-Code verschiebt Aufwand von der einmaligen Entwicklung hin zu laufenden Lizenzkosten. Eigenentwicklung dreht es um.

Appian veröffentlicht keine festen Listenpreise für den produktiven Einsatz. Die Lizenzierung wird individuell verhandelt und richtet sich im Kern nach Nutzung und Anzahl der Anwender. Für eine belastbare Entscheidung beide Varianten über 3 bis 5 Jahre rechnen, nicht nur die Anfangsinvestition.

Die entscheidende Frage ist deshalb nicht „was ist billiger", sondern „wie sieht die Rechnung nach 3 Jahren aus". Eine Anwendung mit überschaubarer Nutzerzahl und hohem Prozessanteil kippt oft zugunsten von Appian, weil die eingesparte Infrastruktur- und Wartungsarbeit die Lizenz mehr als aufwiegt. Eine breit ausgerollte Anwendung mit einfacher Fachlichkeit kippt in die andere Richtung.

Wer hilft, wenn ein Prozess hängen bleibt?

Die Frage kommt im Auswahlprozess fast immer zu spät: Was passiert, wenn eine Antragsstrecke am Monatsende stehen bleibt? Eine Aufgabe hängt, eine Integration antwortet nicht, ein Vorgang kommt nicht weiter. Dann muss jemand wissen, wo in der Anwendung er nachschaut, woran es liegt und wie er den Vorgang wieder in Gang bringt.

Dieses Wissen ist selten reine Appian-Kenntnis. Es ist die Kombination aus Plattform und Ihrem konkreten Prozess. Wer nur die Plattform kennt, sieht zwar, dass etwas hängt, aber nicht warum. Für den Betrieb gibt es 2 ehrliche Wege und beide brauchen Investition:

• Wissen intern aufbauen. Jemand im Haus wird zur Ansprechperson für die Anwendung, kennt die Prozessmodelle und weiß, wo ein hängender Vorgang zu finden und zu korrigieren ist. Das ist eine dauerhafte Rolle, keine Nebenbei-Aufgabe. Und eine Person allein genügt selten: Für Urlaub, Krankheit oder einen Weggang gehört eine Vertretung dazu, sonst steht die Anwendung genau dann still, wenn der einzige Wissensträger fehlt.
• Support auslagern. Möglich, aber der Dienstleister muss Ihren Prozess kennen, nicht nur Appian im Allgemeinen. Generischer Plattform-Support hält die Plattform am Laufen. Klemmt Ihr Vorgang wegen Ihrer eigenen Logik oder einer Ihrer Integrationen, hilft nur jemand, der Ihre Anwendung kennt.

Damit relativiert sich der oft gehörte Satz „mit Low-Code gibt die IT den Betrieb ab". Für den technischen Unterbau stimmt er, für die Anwendung selbst nicht. Die operative Verantwortung für Ihren Prozess bleibt bei Ihnen oder bei einem Partner, der ihn kennt. Es ist dieselbe Betriebsfrage wie bei der Eigenentwicklung, nur mit einem kleineren, plattformspezifischen Personenkreis.

Deshalb gehört sie vor die Entscheidung, nicht in die Woche nach dem ersten hängenden Vorgang. Mein Ansatz ist, den Prozess gemeinsam mit Ihrem Team aufzubauen, sodass das Betriebswissen von Anfang an im Haus entsteht statt als Abhängigkeit.

Die dritte Option, die es früher so nicht gab

Buy-or-Build war jahrelang eine harte Wahl, weil Eigenentwicklung teuer und langsam war. Das hat sich verschoben. KI-gestützte Entwicklung macht kleine, klar umrissene Eigenentwicklungen erstmals kalkulierbar, auch als Festpreis. Damit steht neben „Low-Code-Plattform" und „großes Entwicklungsprojekt" eine dritte Variante im Raum: ein schlankes, selbst gehostetes Tool, dessen Quellcode im Haus bleibt, ohne laufende Plattformlizenz.

Diese Option lohnt die Prüfung vor allem dann, wenn die Fachlichkeit eng ist, die Nutzerzahl klein und die Herstellerbindung stört. Wie so ein Weg konkret aussieht, steht im Angebot internes Tool zum Festpreis entwickeln. Es ersetzt Appian nicht, aber es verändert die Schwelle, ab der sich Eigenentwicklung wieder rechnet.

Entscheidungshilfe auf einen Blick

Häufige Fragen

Was ist der Unterschied zwischen Low-Code und Eigenentwicklung?

Bei der Eigenentwicklung baut ein Team eine Anwendung von Grund auf in einer Programmiersprache wie C#, Java oder Python. Eine Low-Code-Plattform wie Appian liefert die Bausteine vorkonfiguriert mit: Prozessmodelle, Oberflächen, Datenmodell, Rollen- und Rechtesystem, Audit-Trail. Man modelliert die Anwendung visuell, statt jede Schicht neu zu programmieren. Der Preis dafür ist weniger Freiheit und eine Bindung an den Plattformhersteller.

Wann lohnt sich Appian und wann nicht?

Es lohnt sich bei prozessgetriebenen Anwendungen, bei denen ein Vorgang durch mehrere Rollen und Freigaben läuft und Nachvollziehbarkeit gefordert ist. Es lohnt sich nicht bei hochspezialisierter Rechenlogik, performancekritischen Systemen, Produkten für den Endkundenmarkt oder wenn nutzerbasierte Lizenzkosten über sehr viele Anwender nicht tragbar sind.

Was kostet Appian?

Appian veröffentlicht keine festen Listenpreise für den produktiven Einsatz. Die Lizenzierung wird individuell verhandelt und richtet sich im Kern nach Nutzung und Anzahl der Anwender. Für die Buy-or-Build-Entscheidung zählt weniger die genaue Zahl als das Muster: laufende, mit der Nutzung wachsende Lizenzkosten gegen einmaligen Entwicklungsaufwand plus Wartung. Beides über mehrere Jahre rechnen.

Bindet mich Appian an den Hersteller?

Ja. Prozessmodelle, Oberflächen und Konfiguration leben in der Plattform und lassen sich nicht ohne Weiteres woanders hin übertragen. Das ist der Kern des Handels: schnellere Umsetzung und weniger eigene Wartung gegen eine Abhängigkeit von Plattform und Lizenzmodell. Wer die Fachdaten bewusst in eigenen Datenbanken hält, kann das Risiko begrenzen.

Der ehrliche Schluss

Es gibt keine Variante, die immer gewinnt. Es gibt einen Anwendungsfall, der eine bestimmte Variante nahelegt. Prozessgetrieben, auditpflichtig und schnell gebraucht spricht für Appian. Spezialisiert, produktnah oder breit ausgerollt spricht für Eigenentwicklung. Und für die enge, kleine Anwendung lohnt der Blick auf ein KI-gestütztes Festpreis-Tool.

Wer diese Merkmale sauber gegen das eigene Vorhaben hält, entscheidet nicht nach Marketing, sondern nach der Rechnung, die in 3 Jahren noch stimmt.