Ein Prozess läuft heute über eine Excel-Datei, die per E-Mail wandert, und über Wissen, das nur eine Person hat. Es gibt Standardsoftware dafür, aber sie passt nicht — oder sie passt, verlangt aber, dass Sie Ihre Abläufe ändern statt umgekehrt.
Wenn Ihre Daten in einer Oracle-Datenbank liegen oder dort liegen sollen, ist eine APEX-Anwendung in dieser Lage oft der kürzeste Weg zu etwas Belastbarem: keine zusätzliche Laufzeitumgebung, kein neuer Technologiestapel, Fachlogik dort, wo die Daten sind.
Erst etwas Nutzbares, dann alles
Wir beginnen nicht mit einem Lastenheft, sondern mit dem Ablauf, den Sie heute schon haben. Daraus entsteht zuerst ein Stand, der einen Teil der Arbeit wirklich abdeckt — nicht eine Demo, sondern etwas, mit dem jemand arbeiten kann.
Der Grund ist einfach: An etwas Lauffähigem erkennt ein Fachbereich in zwei Tagen mehr über seine eigenen Anforderungen als in zwei Wochen Workshop. Und Sie sehen früh, ob die Zusammenarbeit trägt, statt es nach drei Monaten festzustellen.
Danach wächst die Anwendung in Abschnitten, die einzeln nutzbar sind. Das hält den Aufwand sichtbar und die Entscheidung bei Ihnen: Nach jedem Abschnitt kann man weitermachen, umsteuern oder aufhören.
Wie wir bauen, damit es hinterher beherrschbar bleibt
Die meisten Anwendungen, die wir übernehmen, sind nicht schlecht entwickelt worden — sie sind nur so entwickelt worden, dass niemand außer dem Autor sie weiterführen konnte. Aus dieser Erfahrung ergeben sich unsere Regeln:
- Fachlogik in die Datenbank, nicht in die Oberfläche. Was in Packages und Prozeduren liegt, überlebt einen Wechsel der Oberfläche und lässt sich testen.
- Lesbarkeit vor Kürze. Namen, die erklären, wofür etwas da ist. Ein Nachfolger liest den Code häufiger, als der Autor ihn geschrieben hat.
- Ein dokumentierter Weg nach produktiv. Wenn niemand weiß, wie eine Änderung in den Betrieb kommt, ist die Anwendung schon halb verloren.
- Berechtigungen von Anfang an. Nachträglich eingezogene Rechte sind in gewachsenen Anwendungen die häufigste Sicherheitslücke.
- Keine Abhängigkeit von uns als Konstruktionsprinzip. Wir bauen so, dass ein anderer weiterarbeiten kann.
Aus früheren Projekten bringen wir erprobte Bausteine mit — Muster für Berechtigungen, Protokollierung, Import- und Exportwege, Deployment. Das verkürzt den Weg, ersetzt aber nicht die fachliche Arbeit: Was Ihre Anwendung tun soll, ist bei jedem Kunden anders. Wir sind Dienstleister und verkaufen kein Produkt von der Stange.
Wenn Ihr Team mitbauen soll
Eine Neuentwicklung ist der beste Anlass, eigenes APEX-Wissen aufzubauen: Ihre Entwickler lernen an der Anwendung, die sie später betreuen. Wenn Sie das wollen, arbeiten wir gemeinsam — Ihr Team übernimmt Teile, wir machen Reviews und die Stellen, für die Plattformerfahrung nötig ist. Das Ziel ist, dass Ihr Team am Ende eigenständig arbeiten kann. Für die Grundlagen gibt es unsere APEX-Schulungen, inklusive Oracle APEX und KI.
Wenn KI ins Spiel kommt
Datenbanknahe Anwendungen sind ein guter Ort für KI-Funktionen, weil die Daten schon strukturiert vorliegen: eine Suche, die Bedeutung statt Stichworte trifft, ein Assistent, der Belege vorbereitet, ein Chat auf den eigenen Daten. Wir setzen das in APEX-Anwendungen um — auf Wunsch mit lokal betriebenen Modellen, sodass keine Daten das Haus verlassen. Wie externe KI-Systeme kontrolliert auf eine bestehende Anwendung zugreifen können, steht beim Aquantico APEX MCP Server.
Wo APEX nicht passt
Wir sagen es vor dem Projekt, nicht darin: Ohne Oracle-Datenbank im Rücken ist APEX die falsche Wahl. Ebenso bei Anwendungen, deren Oberfläche eher einer Consumer-App gleichen soll, und bei echter Offline-Fähigkeit auf mobilen Geräten. Für solche Fälle gibt es passendere Werkzeuge — auch wenn das für uns bedeutet, dass wir das Projekt nicht bekommen. Was wir außerhalb von APEX umsetzen, steht unter Ihre individuelle Applikation.
Ihr nächster Schritt
Beschreiben Sie den Prozess, der heute nicht sauber läuft — wer daran beteiligt ist, wo die Daten liegen und was schiefgeht. Daraus lässt sich meist schon im Erstgespräch abschätzen, ob eine APEX-Anwendung der richtige Weg ist und wie ein erster nutzbarer Stand aussehen könnte.
Direkt Termin vereinbaren oder
Häufige Fragen zur Neuentwicklung
Wann ist APEX die richtige Wahl und wann nicht? Richtig ist APEX, wenn die Daten in einer Oracle-Datenbank liegen oder dort liegen sollen und die Anwendung datenbanknah arbeitet: erfassen, prüfen, auswerten, freigeben. Falsch ist es bei Anwendungen ohne Oracle-Datenbank im Rücken, bei Anforderungen an eine Oberfläche, die eher einer Consumer-App gleicht, und bei Offline-Fähigkeit auf mobilen Geräten. In diesen Fällen sagen wir das — auch wenn ein anderes Werkzeug bedeutet, dass wir das Projekt nicht machen.
Wie fangen wir an, wenn die Anforderungen noch nicht klar sind? Mit dem Prozess, nicht mit einem Lastenheft. Wir sehen uns an, wie die Arbeit heute läuft — meist in Excel-Dateien, E-Mails und Zurufen — und bauen daraus einen ersten nutzbaren Stand für den wichtigsten Teil. An etwas Lauffähigem erkennen Fachbereiche in zwei Tagen mehr über ihre Anforderungen als in zwei Wochen Workshop.
Wie lange dauert es, bis wir etwas sehen? Ein erster nutzbarer Stand entsteht typischerweise in Wochen, nicht in Monaten — er deckt einen Teil ab, nicht alles. Wie lange die vollständige Anwendung braucht, hängt an Schnittstellen, Berechtigungen und Sonderfällen. Wir schätzen das nach dem ersten Stand belastbarer als davor und sagen es dann ehrlich, statt eine Zahl zu Projektbeginn zu verteidigen.
Können wir die Anwendung später selbst weiterentwickeln? Das ist das Ziel, wenn Sie es wollen. Deshalb achten wir auf lesbaren PL/SQL-Code, nachvollziehbare Namen, Fachlogik in der Datenbank statt in der Oberfläche und einen dokumentierten Weg, wie Änderungen produktiv gehen. Auf Wunsch entwickelt Ihr Team von Anfang an mit und wir übernehmen Reviews. Der Code gehört Ihnen.
Bringen Sie fertige Bausteine mit? Ja, aber es sind Bausteine und keine Produkte: Muster für Berechtigungen, Protokollierung, Import- und Exportwege, Deployment. Sie verkürzen den Weg zum ersten Stand und werden an Ihre Umgebung angepasst. Was Ihre Anwendung fachlich tut, entsteht bei jedem Kunden neu — sonst hätten Sie eine Standardsoftware gekauft.
Was passiert nach dem Produktivgang? Entweder übernimmt Ihr Team, oder wir betreuen die Anwendung weiter — mit derselben Trennung zwischen laufendem Betrieb und Weiterentwicklung wie bei übernommenen Anwendungen. Beides ist möglich, und die Entscheidung muss nicht zu Projektbeginn fallen.
Weiter: Support und Übernahme · Performance · Migration von Oracle Forms · zurück zur Übersicht Oracle APEX.