Ein Entwicklerwechsel beginnt selten mit einem vollständigen Paket aus Quellcode, Dokumentation und sauberer Testumgebung. Häufig gibt es zunächst nur ein laufendes System, einzelne Projektdateien und Wissen, das bei wenigen Personen liegt.
Trotzdem lässt sich eine bestehende Sage 100 Entwicklung übernehmen. Wichtig ist eine gestufte Bestandsaufnahme. Sie trennt akute Betriebsprobleme von langfristigen Aufgaben und verhindert vorschnelle Änderungen an produktiven Komponenten.
Was zuerst gesichert werden sollte
Bevor jemand Code ändert, sollten die vorhandenen Arbeitsstände und Zugänge gesammelt werden. Dazu gehören nicht nur die eigentlichen Projekte.
- Quellcode, Projektdateien und verwendete Bibliotheken
- Sage-Version und eingesetzte Module
- AppDesigner-Pakete und individuelle Erweiterungen
- Konfigurationen für Schnittstellen und Hintergrunddienste
- Zugänge zu Test-, Build- und Bereitstellungsumgebungen
- bekannte Fehler, offene Anforderungen und vorhandene Dokumentation
Fehlt Quellcode, muss geklärt werden, ob er noch beim bisherigen Dienstleister, in einer Versionsverwaltung oder auf einem Build-Rechner liegt. Ohne diesen Stand kann eine vorhandene Komponente möglicherweise nur analysiert, aber nicht verlässlich weiterentwickelt werden.
Den laufenden Betrieb verstehen
Die sichtbare Funktion in Sage 100 ist nur ein Teil der Lösung. Im Hintergrund können Dienste, geplante Aufgaben, Dateiverzeichnisse, Datenbankzugriffe oder externe APIs beteiligt sein.
Für jeden Prozess sollte nachvollziehbar sein:
- Wie wird er gestartet?
- Welche Systeme und Zugangsdaten werden benötigt?
- Wo liegen Konfiguration und Protokolle?
- Wie wird ein Fehler erkannt und behoben?
- Welche Person kennt den fachlichen Sollablauf?
Bei einer vorhandenen Sage 100 Schnittstelle kommt die Frage hinzu, welches System für Stammdaten und Status führend ist. Diese Information lässt sich aus dem Code allein nicht immer eindeutig ableiten.
Risiken nach Wirkung priorisieren
Eine lange Liste technischer Auffälligkeiten hilft wenig, wenn nicht klar ist, welche davon den Betrieb gefährden. Für die Priorisierung bieten sich drei Gruppen an.
Akute Betriebsrisiken
Dazu gehören wiederkehrende Abbrüche, fehlende Sicherungen, ablaufende Zugangsdaten oder Vorgänge, die zu falschen Beständen und Belegen führen können. Diese Punkte werden zuerst untersucht.
Wartungsrisiken
Nicht reproduzierbare Builds, manuelle Bereitstellungsschritte und unbekannte externe Abhängigkeiten erschweren jede Änderung. Sie müssen nicht sofort sichtbar sein, sollten aber vor der nächsten größeren Erweiterung geklärt werden.
Fachliche Altlasten
Manche Sonderregel war beim Projektstart sinnvoll und ist heute überholt. Ob sie entfernt werden darf, entscheidet nicht der Code. Dafür braucht es einen fachlichen Ansprechpartner und passende Testfälle.
Mit einem abgegrenzten Prüffall beginnen
Ein kleiner, repräsentativer Fall zeigt schnell, ob der vorhandene Stand gebaut, getestet und bereitgestellt werden kann. Geeignet ist eine Änderung mit klarer fachlicher Erwartung und begrenzter Auswirkung.
Dabei lässt sich prüfen, ob Entwicklungsumgebung, Quellcode und produktiver Stand zusammenpassen. Erst danach ist eine belastbare Planung für größere Änderungen sinnvoll.
Was in die neue Dokumentation gehört
Die Bestandsaufnahme sollte direkt eine nutzbare Dokumentation erzeugen. Ein umfangreiches Handbuch ist dafür nicht nötig. Entscheidend sind Angaben, die den nächsten Eingriff sicherer machen.
- Übersicht der Komponenten und Verantwortlichkeiten
- Build- und Bereitstellungsweg
- Konfigurationsorte ohne geheime Werte
- wichtige Datenflüsse und Abhängigkeiten
- repräsentative Testfälle
- offene Risiken und priorisierte nächste Schritte
Welche Angaben für eine erste Einschätzung reichen
Für den ersten Austausch brauchen Sie noch keine vollständige technische Dokumentation. Hilfreich sind die Sage-Version, eine kurze Beschreibung der Lösung, der aktuelle Handlungsdruck und die Information, ob Quellcode und eine Testumgebung vorhanden sind.
Aus diesen Eckdaten ergibt sich, ob zunächst ein konkreter Fehler, eine Bestandsaufnahme oder laufender Developer-Support der passende Einstieg ist.
Beschreiben Sie uns den vorhandenen Stand und das dringendste Thema.