Sie beauftragen eine Anwendung für Prüfmittel, Mietverträge oder Anträge. Bezahlt wird zum größeren Teil etwas anderes: Anmeldung, Rechte, Suche, Filter, Fehlermeldungen, Protokoll, Anhänge, Export, Tests, Dokumentation. Diese Seite zählt auf, was davon aus dem Framework kommt, statt bezahlt zu werden.
Der größte Teil einer Fachanwendung liegt neben Ihrer Fachlichkeit
Nehmen wir eine Prüfmittelverwaltung. Fachlich geht es um wenig: Geräte erfassen, Prüffristen im Blick behalten, Kalibrierscheine ablegen, rechtzeitig erinnern. In einer halben Stunde erklärt, und das steht so im Lastenheft.
Bevor der erste Mitarbeiter das erste Gerät erfasst, muss die Anwendung aber noch anderes können. Er muss sich anmelden und sein Passwort zurücksetzen. Die Werkstatt darf andere Geräte sehen als der Einkauf. Die Liste hat nach zwei Jahren viertausend Zeilen und braucht Suche, Sortierung, Filter und Seiten. Der Prüfbericht hängt als PDF am Datensatz, der Auditor fragt, wer das Prüfdatum geändert hat, der Controller will die Liste in Excel.
Nichts davon ist Ihr Geschäft, alles davon muss jemand bauen. In einer Individualentwicklung ist jeder dieser Punkte Entwurf, Umsetzung, Test und danach Wartungsposten. Der Teil, den niemand sieht, ist der teuerste, und er wiederholt sich in jedem Projekt fast unverändert.
Was neben der Fachlichkeit in einer Anwendung steckt
Gruppen, die in keinem Lastenheft stehen, weil sie selbstverständlich wirken.
Anmeldung, Passwort vergessen, Sitzungsdauer, zweiter Faktor, Konto aus dem Firmenverzeichnis, öffentliche Formulare für Externe.
Rollen, Rechte je Entität und Operation, feldweise Sichtbarkeit, Einschränkung auf den eigenen Standort.
Spaltenwahl, Sortierung, Volltextsuche, Filter mit bis zu acht Vergleichsarten je Feldtyp, gespeicherte Sichten, Sammelaktionen.
Pflichtangaben, Längen, Wertebereiche, Nachkommastellen, Einheiten, Prüfmuster, geprüft im Formular und noch einmal im Server.
Deutsche Oberfläche bis in Systemdialog und Fehlertext, weitere Sprachen als Datei, Datums- und Zahlenformate, mehrsprachige Inhalte.
Änderungsverlauf am Datensatz, bei dem sich der Stand vor einer Änderung wieder öffnen lässt, Archivieren statt Löschen, lückenlose Belegnummern, Anonymisieren.
Anhänge am Datensatz, Export als Excel, CSV oder PDF, erzeugte Dokumente aus Vorlagen, Druckansicht, Mails aus der Anwendung.
Tastaturbedienung, Kontraste und Vorlesbarkeit nach WCAG 2.1 AA, Container-Abbild, Drosselung gegen Überlast, Pflege der Bibliotheken.
Funktionen, die nicht programmiert, sondern eingerichtet werden
Anmeldung und Sitzungen, Anbindung an das Firmenverzeichnis, öffentliche Formulare für Externe ohne Konto.
Aktivitätsprotokoll, Archivieren statt Löschen, lückenlose Belegnummern wie PRF-000123, Anonymisieren personenbezogener Daten. Ab Werk läuft davon nichts: Was protokolliert wird und welche Frist für welchen Datensatz gilt, legt Ihr Haus fest, und eingerichtet wird es je Anwendung.
Dateianhänge an jedem Datensatz, erzeugte Dokumente aus Vorlagen, gespeicherte Filtersichten, Kurzlinks zum Weiterreichen eines Vorgangs.
E-Mail-Versand, Zugriff auf Daten anderer Anwendungen des Hauses, Aktualisierung offener Listen ohne Neuladen, Push-Nachrichten.
Mehrsprachigkeit bis in die Fehlermeldung, Kennzahlen und Auswertungen, systemweite Einstellungen.
Mobile App, Weiterarbeiten ohne Netz mit Nachsende-Warteschlange, Container-Abbild, sicher hinterlegte Zugangsdaten, Testgerüst.
Wie dieser Teil entsteht, ohne dass ihn jemand tippt
Bis hierhin stand nur, was in jeder Fachanwendung steckt. Die zweite Frage ist, wer das baut, und die Antwort lautet bei uns: ein Programm. Ein Generator liest eine Beschreibung der Anwendung und schreibt daraus den Quelltext, so wie ein Setzer aus einem Manuskript eine Seite setzt. Keine KI, die formuliert, sondern feste Regeln, die immer dasselbe Ergebnis liefern.
Damit das geht, muss die Beschreibung maschinenlesbar sein. Sie ist deshalb kein Text, sondern eine Sammlung von Datensätzen im SOLUTIONS.designer: eine Entität je Ding, ein Feld je Eigenschaft, eine Beziehung je Zusammenhang, dazu Formulare und Listen.
Daraus folgt, warum die Punkte aus der Liste oben nicht programmiert werden müssen. Steht am Feld, dass es eine Zahl mit zwei Nachkommastellen ist und in Euro angezeigt wird, ergeben sich daraus die Eingabemaske, die Prüfung im Browser, die Prüfung im Server, die Spaltendarstellung, das Format im Excel-Export und der Eintrag in der Dokumentation. Sechs Ergebnisse aus einer Angabe. Das ist der Hebel, nicht die Geschwindigkeit der Codeerzeugung.
Was Sie beschreiben, und was daraus entsteht
Links die Datensätze, die jemand im Designer anlegt, rechts das, was der Generator daraus schreibt.
Beschreibung
Erzeugnis
417
Entitäten über 58 Anwendungen
im Median 6 je Anwendung
3.733
Felder, davon 1.066 Beziehungen
317 Auswahllisten, 199 berechnet
423 / 444
Formulare und Listen
jede mit Suche und Filter
2.569
Eingabefelder in diesen Formularen
dazu 1.744 Spalten in den Listen
Oberfläche, Schnittstelle, Datenhaltung
Die Oberfläche
Das Frontend ist eine Angular-Anwendung aus einer gepflegten Bausteinbibliothek: Kopfzeile, Menü, Liste, Formularabschnitt, Auswahlfeld, Datumsfeld. Jeder Baustein existiert einmal und ist überall gleich bedienbar.
Barrierefreiheit nach WCAG 2.1 AA ist Vorgabe, nicht Zusatzleistung: Tastaturbedienung, Kontrast, mit dem Feld verknüpfte Fehlermeldungen. Der Nutzen zeigt sich beim zweiten Projekt: Wer eine Anwendung kennt, findet sich in der nächsten zurecht.
Die Schnittstelle
Zwischen Oberfläche und Server liegt eine REST-Schnittstelle als offizieller Zugang zu den Daten: je Entität die Ressourcen und Operationen nach OpenAPI, daraus eine lesbare Dokumentationsseite, die zum Stand der Anwendung passt.
Braucht das Nachbarsystem später dieselben Daten, ist keine Sonderschnittstelle nötig. Der Zugang läuft über dieselbe Anmeldung und dasselbe Rechtesystem. Ein Auswertungswerkzeug sieht nicht mehr als der Benutzer, für den es fragt.
Die Datenhaltung
Jede Anwendung bekommt ihre eigene MongoDB; Schema, Prüfungen und Zugriffsklassen entstehen aus dem Modell. Die Modellklassen liegen in einem gemeinsamen Bereich, den Frontend und Backend benutzen. Ein umbenanntes Feld bleibt auf keiner Seite unbemerkt stehen.
Dateien liegen wahlweise in der Datenbank, in einem S3-Speicher oder in Azure. Warum jede Anwendung ihre eigene Datenbank hat, steht unter Microservice-Architektur.
Was mitkommt und anderswo extra berechnet wird
Technische Dokumentation. Verzeichnisse und Dateinamen folgen einer festen Konvention, Klassen und Funktionen sind kommentiert, die Schnittstelle dokumentiert sich selbst. Dazu entsteht aus dem Modell eine Benutzerdokumentation als Baum, je Entität, Liste und Formular eine Seite, die niemand von Hand geschrieben hat.
Tests. Hier lohnt eine Unterscheidung. Die Erzeugungsroutinen und die Bausteine der Oberfläche sind geprüft, die Testwerkzeuge ab der Generierung eingerichtet, die Backend-Logik abgesichert. Nicht automatisch entstehen Testfälle für Ihre Fachlogik. Dafür kommt ein Gerüst aus 132 vorbereiteten Prüfobjekten mit, eines je Oberflächenbaustein. Ein Test prüft damit den Vorgang statt der Schaltflächen. Diese Tests zu schreiben wird geplant.
Mehrsprachigkeit. Sie ist im Modell angelegt und keine Erweiterung: Zu jeder Feldbeschriftung und jedem Wert einer Auswahlliste gehören die Übersetzungen. Ausgeliefert wird Deutsch, eine weitere Sprache ist eine zusätzliche Datei. Und diese Datei füllt niemand von Hand: SOLUTIONS.translate sammelt die Texte aus der Anwendung ein und legt sie Übersetzern in einer Weboberfläche vor, alle Sprachen nebeneinander. Wer einmal nachträglich internationalisiert hat, kennt den Unterschied.
Eine App fürs Telefon. Aus derselben Beschreibung entsteht auf Wunsch eine Flutter-Anwendung: Datenmodelle, Zugriffsdienste und die Listen- und Leseansichten. Mobile Eingabemasken sind heute noch Folgearbeit.
Wo der vorgegebene Aufbau an seine Grenze stößt
Ein vorgegebener Aufbau ist eine Festlegung. Der Vorteil entsteht daraus, dass alle Anwendungen gleich aufgebaut sind. Damit fällt weg, was sonst je Projekt neu entschieden würde, und damit auch die Freiheit, es anders zu entscheiden. Formulare folgen einem Raster, keinem Zeichenbrett. Wer darüber hinaus eine eigene Bedienlogik braucht, etwa eine grafische Plantafel oder eine Zeichenfläche, bekommt sie als eigens gebaute Komponente: Sie steht dann als benannte Aufgabe im Angebot, mit Schätzung. Je mehr eine Anwendung davon braucht, desto größer wird dieser Teil und desto kleiner der erzeugte.
Der Aufbau setzt ein Modell aus Entitäten und Feldern voraus. Wo die Daten sich so nicht beschreiben lassen, etwa bei Messwerten im Sekundentakt, stark vernetzten Graphdaten oder Anwendungen, deren Kern ein Rechenverfahren ist, trägt er nicht. Das ist die eine Grenze, an der wir abraten.
Einzelne Bausteine laufen als eigener Dienst weiter, darunter SOLUTIONS.file für die Erzeugung von Dokumenten und SOLUTIONS.transformer für die Datenübernahme aus Altsystemen. Wer die Anwendung ganz übernimmt, ersetzt sie oder lizenziert sie weiter. Das gehört in die Rechnung, bevor von Unabhängigkeit die Rede ist; der vollständige Schnitt steht unter Lizenzmodell und Quellcode.
Der Generator schreibt nur, was im Modell steht. Was von Hand im erzeugten Teil geändert wird, ist nach dem nächsten Generatorlauf weg. Eigene Fachlogik gehört deshalb in getrennte Dateien, die an definierten Ereignissen einhaken. Ist eine Anwendung stark von Hand ausgebaut, wird sie nicht mehr überschrieben. Verloren ist der Anschluss ans Modell deshalb nicht: Jedes erzeugte Projekt trägt den Modellstand mit, aus dem es entstanden ist, und SOLUTIONS.designer vergleicht ihn mit dem neuen. Heraus kommt keine neue Fassung, sondern eine lesbare Liste dessen, was sich geändert hat und wo es einzubauen wäre. Deshalb gilt bei uns Konfiguration vor Programmierung.
Weiterlesen
Anmeldung, Rollen und Rechte, Listen mit Suche, Sortierung und Filter, Eingabeprüfung im Formular und noch einmal im Server, Fehlermeldungen, Mehrsprachigkeit, Änderungsprotokoll, Anhänge, Export, Barrierefreiheit, Tests, Dokumentation und jahrelange Sicherheitsaktualisierungen. Jeder Punkt ist sonst Entwurf, Umsetzung, Test und Wartung.
Als gewöhnliches Projekt aus drei Teilen: einem Angular-Frontend, einem NestJS-Backend und einem gemeinsamen Bereich mit den Modellklassen beider Seiten. Dazwischen eine REST-Schnittstelle nach OpenAPI, darunter eine eigene MongoDB. Alles liegt in einem Git-Repository.
Die Dokumentation ja: feste Namenskonventionen, kommentierter Quelltext, eine Schnittstellenseite aus der OpenAPI-Beschreibung und eine Benutzerdokumentation aus dem Modell, je Entität, Liste und Formular eine Seite. Beim Testen liefern wir das Gerüst: 132 vorbereitete Prüfobjekte für die Oberflächenbausteine. Die fachlichen Testfälle werden geplant.
Ja, im Modell selbst: Zu jeder Feldbeschriftung, jedem Abschnitt und jedem Wert einer Auswahlliste gehören die Übersetzungen; auch Fehlermeldungen und Systemdialoge werden übersetzt. Ausgeliefert wird Deutsch, eine weitere Sprache ist eine zusätzliche Datei.
Er passt selten gar nicht, aber er verschiebt sich. Eine eigene Bedienlogik wie eine grafische Plantafel oder eine Zeichenfläche bauen wir als eigene Komponente; sie steht dann als benannte Aufgabe im Angebot, mit Schätzung, statt als Ausschlussgrund. Je mehr eine Anwendung davon braucht, desto größer wird dieser Teil und desto kleiner der erzeugte. Wirklich unpassend wird es erst, wenn Ihre Daten sich nicht in Entitäten und Feldern beschreiben lassen, etwa bei Signalen aus der Messtechnik oder Bildverarbeitung. Dann sagen wir das auch.
Sprechen Sie mit uns.