Das System, von dem die Geschäftsprozesse eines Unternehmens abhängen – das System, das Bestellungen, Richtlinien, Dateien oder Lieferungen verwaltet – entsteht nicht durch das Aneinanderreihen von spontan generierten Fragmenten. Es benötigt ein definiertes Datenmodell, Verträge zwischen den Modulen, ein Berechtigungs- und Rückverfolgbarkeitsmodell, und diese vier Aspekte sind Entscheidungen, die getroffen werden, keine Ergebnisse, die sich von selbst ergeben.
Die Verwirrung entsteht dadurch, dass die unterstützte Energieerzeugung in der Peripherie sehr gut funktioniert, und dies die Erwartung weckt, dass sie im Kern genauso funktionieren wird.
Kriterium | Kernsystem | Peripheres System |
|---|---|---|
Wenn es nicht mehr funktioniert | Das Unternehmen für | Jemand ist verärgert |
Erwartete Nutzungsdauer | 5-15 Jahre | Monate oder ein paar Jahre |
Anzahl der Integrationen | Viele und kritische | Wenige oder keine |
Kosten eines Fehlers | Geld, Kunde oder Auftragsabwicklung | Zeitverschwendung |
Wer sollte es unterstützen können? | Jedes kompetente Team | Wer war es? |
Die erste Zeile genügt, um die Fälle nach Regel 90% zu klassifizieren. Wenn die Antwort auf die Frage «Was passiert, wenn dies einen Tag lang nicht funktioniert?» lautet, dass Abrechnung, Produktion oder Kundenservice ausfallen, dann handelt es sich um einen Kernprozess, der unabhängig von seinem Umfang als solcher behandelt werden sollte.
Ein häufiger Fehler ist die Annahme, das Kernsystem sei das Wichtigste. Es gibt kleine Systeme, von denen der gesamte Betrieb abhängt, und riesige Systeme, die niemand eine Woche lang vermissen würde.
Das Datenmodell. Wie Geschäftseinheiten dargestellt werden: Was ist ein Kunde, eine Datei, eine Sendung? Welche Beziehungen bestehen zwischen ihnen? Welche Phasen durchlaufen sie? Diese Entscheidung ist am kostspieligsten zu revidieren, da alles andere darauf aufbaut.
Grundstücksgrenzen. Welches Modul hat Vorrang vor welchen Informationen und welcher Abfrage? Ohne diese Entscheidung scheinen drei Systeme dieselben Daten zu schreiben, und es gibt keine Möglichkeit festzustellen, welches System korrekt ist.
Das Berechtigungsmodell. Wer was sieht und wer was tun kann, wird auf Systemebene festgelegt und nicht als Bedingungen, die sich in der gesamten Anwendung wiederholen. Dies entscheidet darüber, ob morgen ein Assistent, ein Kundenportal oder eine API hinzugefügt werden kann, ohne eine Sicherheitslücke zu schaffen.
Rückverfolgbarkeit. Was bei jeder Änderung protokolliert wird und wie lange? Der Vorgang ist unumkehrbar: Was nicht gespeichert wurde, existiert nicht.
Keiner der vier Punkte kann an ein Generationstool delegiert werden, da sie alle darauf beruhen, das Geschäft zu kennen und vorherzusehen, wie es sich verändern wird.
Es wäre absurd, auf die verfügbare Geschwindigkeit zu verzichten. In einem gut strukturierten Kernsystem arbeitet die unterstützte Stromerzeugung gut in folgenden Bereichen:
Die Regel ist einfach: Die Ausführung wird delegiert, nicht die Struktur.. Die Überprüfung bleibt weiterhin obligatorisch, aus dem Grund, den wir in erläutert haben. Der Code, den niemand versteht, ist die Verschuldung.
Es gibt ein operatives Kriterium zur Feststellung, ob ein Kernsystem gut aufgebaut ist, und es bedarf keiner Prüfung: Könnte ein anderes Team dieses System innerhalb eines Monats übernehmen, ohne mit demjenigen zu sprechen, der es entwickelt hat?
Damit die Antwort Ja lautet, sind vier Dinge erforderlich: Architekturdokumentation, versionierte Integrationsverträge, Tests, die ausdrücken, was das Unternehmen erwartet, und Entscheidungen, die schriftlich erläutert werden.
Ein System, das diesen Test nicht besteht, stellt unabhängig von seiner technischen Qualität ein reales Betriebsrisiko dar: Die Kontinuität des Unternehmens hängt von der Verfügbarkeit bestimmter Fachkräfte ab. Und es hat auch finanzielle Auswirkungen, denn genau das wird im Rahmen einer Technologie-Due-Diligence-Prüfung bestraft.
Weil die Eintrittsbarriere für die Herstellung eines funktionierenden Produkts deutlich gesunken ist, und damit auch die Barriere für die Herstellung eines zwar funktionierenden, aber nicht nachhaltigen Produkts.
Die GitClear-Daten zu 211 Millionen Codezeilen zeigen ein klares Muster: Der Refactoring-Aufwand sank von rund 251 Tsd. Gesamtänderungen im Jahr 2021 auf unter 101 Tsd. Gesamtänderungen im Jahr 2024, während die Replikation um das Achtfache zunahm. Es wird mehr entwickelt und weniger strukturiert. In einem peripheren System ist das noch verkraftbar, in einem Kernsystem hingegen eine Belastung.
Bei der Entscheidung, wie ein kritisches System aufgebaut werden soll, geht es in der zielführenden Diskussion nicht um Methodik oder Werkzeuge. Es geht um drei Verpflichtungen:
Mit diesen drei Kompromissen ist die Erzeugungsgeschwindigkeit ein Vorteil. Ohne sie ist es die schnellste bekannte Methode, etwas zu bauen, das niemand mehr ändern kann.
Es ist das System, von dem der Betrieb abhängt: Fällt es auch nur einen Tag lang aus, stehen Abrechnung, Produktion und Kundenservice still. Es definiert sich nicht durch seine Größe – es gibt kleine Kernsysteme und große Systeme, die nicht so klein sind –, sondern durch die Folgen seiner Nichtverfügbarkeit.
Viertens: das Datenmodell, das die Geschäftseinheiten repräsentiert, die Zuständigkeitsgrenzen, die festlegen, welches Modul welche Informationen kontrolliert, das als Systemebene aufgelöste Berechtigungsmodell und die Nachverfolgbarkeit von Änderungen. Nichts davon kann an ein Generierungstool delegiert werden.
Ja, innerhalb einer vordefinierten Struktur: Implementierung vordefinierter Regeln, eine Präsentationsschicht, Transformationen mit expliziten Akzeptanzkriterien und Dokumentation zuvor beschriebener Fälle. Die Regel lautet, die Konstruktion zu delegieren, nicht die Struktur.
Der Übergabetest dient der Beurteilung, ob ein anderes Team innerhalb eines Monats ohne Rücksprache mit dem ursprünglichen Team die Aufgaben übernehmen kann. Dies erfordert Architekturdokumentation, versionierte Integrationsvereinbarungen, Tests, die die Geschäftserwartungen abbilden, und klar begründete Entscheidungen.
Ein operationelles Risiko – die Kontinuität hängt von bestimmten Personen ab – und ein finanzielles Risiko, denn genau das wird bei einer technologischen Due-Diligence-Prüfung bestraft, wenn es um die Bewertung des Unternehmens oder die Suche nach Investitionen geht.
Weil die Hürden für die Erstellung von funktionierendem Code deutlich gesunken sind. GitClear dokumentierte, dass das Refactoring von etwa 251 TP3T Gesamtänderungen im Jahr 2021 auf weniger als 101 TP3T im Jahr 2024 zurückging und dass die Duplikation um das Achtfache zunahm: Es wird mehr gebaut und weniger strukturiert, was in einem kritischen System zu einer Belastung wird.
Werden Sie ein System aufbauen, von dem Ihr Betrieb abhängen wird? Wir definieren Architektur, Datenmodell und Verträge, bevor wir mit dem Programmieren beginnen, und übergeben Ihnen den Code und die Dokumentation vertraglich. Lass uns reden → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
