Entwicklung & Implementierung

Von der Spezifikation zur Integration: OTOKO® entwickelt Anwendungen und verbindet sie mit Ihren bestehenden Systemen und Prozessen.

Ob Fachanwendung, digitales Produkt oder internes Werkzeug: Wir entwickeln Software für Abläufe, die sich mit vorhandenen Systemen nicht sinnvoll abbilden lassen.

Anforderungsanalyse mit dem Fachbereich, Bedrohungsmodell und Zielarchitektur nach dem C4-Modell Domänenmodell, Datenmodell und Schnittstellenverträge vor der ersten Zeile Code Entwicklung in kurzen Iterationen mit Code-Reviews und Abnahmen durch den Fachbereich Sichere Entwicklung nach OWASP ASVS, geprüfte Abhängigkeiten und signierte Builds Übergabe mit Quellcode, Architekturdokumentation und Betriebshandbuch

Lauffähige Anwendung mit Quellcode und Build-Pipeline Architekturdokumentation mit Bedrohungsmodell Betriebshandbuch mit Runbooks und Notfallkonzept

Beispiele der heutigen Arbeitsabläufe und Ausnahmen Verantwortliche für fachliche Entscheidungen Bestandssysteme, Datenquellen und Betriebsanforderungen

Eine Wartungsplanung wird bislang in Tabellen geführt. Eine Fachanwendung bündelt Anlagen, Termine, Zuständigkeiten und Freigaben. Die erste Ausbaustufe bildet einen Standort ab; weitere Standorte folgen erst nach fachlicher Prüfung des Prozesses.

.NET C# Go Rust TypeScript PostgreSQL

Den Anfang macht der Arbeitsablauf, für den sich die Investition lohnen soll. Wir modellieren Begriffe, Zustände und Geschäftsregeln mit den Menschen, die später damit arbeiten. Eine Freigabe ist beispielsweise nicht nur ein Button: Stellvertretung, Berechtigungen, Fristen und die Rücknahme einer Entscheidung müssen zusammenpassen. Diese Regeln werden Teil des Datenmodells und der Tests. Die erste Version konzentriert sich auf einen vollständigen nutzbaren Prozess. Weitere Funktionen ergänzen wir nach Rückmeldung aus dem Einsatz. Dadurch entsteht ein Produkt mit überprüfbarem Nutzen und keine große Sammlung unfertiger Masken.

Für Backend, Oberfläche und Datenhaltung wählen wir Technologien anhand Ihrer Bestandslandschaft und der erwarteten Weiterentwicklung. Bestehende Kompetenzen, Schnittstellen und Betriebsanforderungen wiegen dabei schwerer als ein kurzfristiger Technologietrend. Das vorhandene Angebot umfasst unter anderem .NET, Go und TypeScript; systemnahe Komponenten werden gesondert bewertet. Wir definieren Modulgrenzen und Verantwortlichkeiten so, dass Änderungen nachvollziehbar bleiben. Zugangsdaten gehören nicht in Quellcode, fachliche Regeln nicht ausschließlich in die Oberfläche. Reviews, automatisierte Prüfungen und versionierte Datenbankänderungen begleiten die Umsetzung von Beginn an.

Jede Iteration zeigt nutzbare Funktionen mit bekannten Einschränkungen. Fachliche Abnahme und technische Freigabe werden getrennt betrachtet: Eine korrekt berechnete Bestellung kann fachlich stimmen, während Lastverhalten oder Fehlerbehandlung noch nicht produktionsreif sind. Gemeinsam legen wir fest, welche Nachweise für den jeweiligen Ausbauschritt erforderlich sind. Zum vereinbarten Lieferumfang gehören Quellcode, reproduzierbare Builds und Dokumentation. Für den produktiven Start klären wir Datenübernahme, Schulung, Zuständigkeiten und den Umgang mit Störungen. Nutzungsrechte, Fremdkomponenten und spätere Wartung regeln wir vor der Übergabe.

Eine Anwendung muss auch dann korrekt arbeiten, wenn mehrere Menschen gleichzeitig denselben Bestand verändern. Zwei Reservierungen dürfen nicht unbemerkt denselben letzten Artikel vergeben. Wir bestimmen deshalb, welche Änderungen gemeinsam erfolgreich sein müssen und welche Konflikte eine fachliche Rückmeldung benötigen. Datenbankbedingungen, Transaktionen und Versionsprüfungen können unterschiedliche Teile dieser Aufgabe lösen; die Oberfläche allein kann diese Regeln nicht absichern. Längere Geschäftsprozesse passen dagegen oft nicht in eine einzige Transaktion. Eine Bestellung, ein externer Zahlungsdienst und eine Versandfreigabe haben eigene Fehlerzustände. Wir modellieren den Vorgang mit nachvollziehbaren Zuständen und erlaubten Übergängen. Wiederholte Anforderungen erhalten eine geeignete Vorgangskennung, damit ein Verbindungsabbruch nicht automatisch eine doppelte Aktion auslöst. Bei Teilfehlern braucht es eine fachlich definierte Korrektur, etwa eine Freigaberücknahme, statt eines pauschalen technischen Neustarts.

Für SaaS-Produkte und interne Plattformen unterscheiden wir die Identität eines Nutzers von seinen Rechten auf einen konkreten Datensatz. Ein angemeldeter Mitarbeiter darf nicht automatisch jede Rechnung oder jeden Auftrag lesen. Wir prüfen Zugriffe im Backend auf Ebene von Organisation, Rolle und Vorgang. Auch Exporte, Suchindizes, Hintergrundaufgaben und zwischengespeicherte Ergebnisse müssen diese Grenzen berücksichtigen. Gemeinsame Tabellen mit Mandantenkennzeichen, getrennte Datenbankschemata oder eigene Datenbanken bringen unterschiedliche Anforderungen an Isolation, Migration und Wiederherstellung mit. Wir wählen das Modell anhand der benötigten Trennung und Ihrer Betriebsorganisation. Tests mit mehreren Mandanten prüfen insbesondere unzulässige Zugriffe. Ein Audit-Protokoll dokumentiert fachlich relevante Änderungen mit geeignetem Kontext; welche Daten darin stehen und wie lange sie verfügbar bleiben, wird ausdrücklich festgelegt.

Die Datenstruktur folgt den Abfragen und Geschäftsregeln. Wir untersuchen typische Filter, Sortierungen, Auswertungen und Schreibvorgänge, bevor zusätzliche Speichertechnologien eingeführt werden. Unbegrenzte Ergebnislisten, wiederholte Einzelabfragen und große Datenübertragungen können eine Anwendung ausbremsen, obwohl der Server kaum ausgelastet wirkt. Messungen mit realistischen Datenmengen zeigen, ob Indizes, Abfrageänderungen, Pagination oder eine andere Aufgabenteilung helfen. Caching ist eine bewusste Entscheidung über Aktualität: Es muss feststehen, wann ein gespeichertes Ergebnis ungültig wird und welche Nutzer es sehen dürfen. Umfangreiche Berechnungen können als Hintergrundaufträge laufen, brauchen dann aber Fortschrittsanzeige, Wiederanlauf und Fehlerzustände. Für Erweiterungen trennen wir fachliche Regeln von technischen Adaptern. Automatisierte Tests und versionierte Datenbankänderungen sichern diese Grenzen ab, damit ein neuer Kanal oder ein anderer Anbieter nicht jedes Modul verändern muss.

Anwendungslandschaft, Anforderungen, Risiken Fachbereich, IT, Informationssicherheit, OTOKO® Softwarearchitekt Bewertete Vorhaben, Bestandsaufnahme, Sicherheits- und Betriebsanforderungen

Architektur, Technologie, Betriebsmodell Fachbereich, Architektur, Datenschutz, Informationssicherheit Zielarchitektur, Bedrohungsmodell, Teststrategie, Betriebsmodell, Meilensteine