Fachbeitrag · Wirtschaftsinformatik ·
Architekturentscheidungen: Warum eine spätere Korrektur die ursprüngliche Begründung nicht löschen sollte
Ein Team entscheidet sich für eine bestimmte Integrationsform, weil Zeit, vorhandene Kenntnisse und erwartete Datenmengen dazu passen. Monate später ändern sich diese Rahmenbedingungen. Ohne dokumentierten Kontext erscheint die ursprüngliche Lösung dann schnell als bloßer Fehler. Ein kurzer Architekturentscheidungsnachweis hält fest, welche Frage gelöst wurde, welche Alternativen vorlagen und welche Folgen bewusst in Kauf genommen wurden. Er macht spätere Änderungen damit fachlich nachvollziehbar.
Eine Entscheidung statt eines Gesamthandbuchs
Ein Entscheidungsnachweis behandelt einen bedeutsamen Zusammenhang, beispielsweise die Wahl eines Synchronisationsverfahrens oder einer Systemgrenze. Er muss nicht die gesamte Architektur neu beschreiben. Hilfreich sind Kontext, betrachtete Optionen, Entscheidung, wesentliche Konsequenzen und Status. Gerade verworfene Alternativen können später wichtig sein. Ihre Beschreibung sollte zeigen, warum sie unter den damaligen Bedingungen weniger geeignet erschienen, statt andere Ansätze pauschal abzuwerten. So bleibt der Nachweis kurz genug, um im Arbeitsalltag tatsächlich gelesen zu werden.
Eine begrenzte Annahme sichtbar machen
Ein vereinfachtes Beispiel: Für einen ersten Ausbauschritt wird ein nächtlicher Datenabgleich gewählt. Die Annahme lautet, dass die Fachbereiche mit einem Aktualitätsrückstand bis zum nächsten Morgen arbeiten können. Später entsteht ein zeitkritischer Prozess. Die ursprüngliche Entscheidung muss dann nicht rückwirkend als allgemeingültige Empfehlung verteidigt werden. Stattdessen wird geprüft, ob ihre dokumentierte Voraussetzung noch gilt. Die neue Entscheidung kann einen anderen Abgleich vorsehen und ausdrücklich auf den veränderten Bedarf Bezug nehmen.
Historie und aktuellen Stand verbinden
Ein akzeptierter Nachweis sollte bei einer grundlegenden Änderung nicht stillschweigend überschrieben werden. Eine neue Entscheidung kann die frühere ersetzen und auf sie verweisen. Damit bleiben damaliger Wissensstand und heutige Lösung unterscheidbar. Das ist besonders bei technischen Schulden nützlich: Eine bewusste Vereinfachung bekommt erkennbare Grenzen, Prüfzeitpunkte oder Auslöser für eine Neubewertung. Ein Datum allein reicht nicht aus. Ebenso wichtig sind die betroffenen Systeme und die Stelle, die eine erneute Betrachtung anstoßen kann.
Dokumentation nicht mit Steuerung verwechseln
Ein sauberer Nachweis verhindert nicht automatisch schlechte Entscheidungen. Relevante Beteiligte müssen ihre Sicht einbringen, und getroffene Festlegungen brauchen einen Bezug zur Umsetzung. Prüfen lässt sich etwa, ob ein konkreter Systemaufbau noch zur akzeptierten Entscheidung passt oder ob eine Abweichung bewusst genehmigt wurde. Zu viele unverbundene Dokumente können ebenfalls unübersichtlich werden. Deshalb werden Nachweise auffindbar benannt, sinnvoll verknüpft und bei wesentlichen Änderungen herangezogen. Ihr Nutzen entsteht durch die Verbindung zwischen Begründung, tatsächlichem Systemzustand und späterer Weiterentwicklung.
Technical insight · Business information systems ·
Architecture decisions: Why a later correction should not erase the original reasoning
A team chooses an integration approach because its time constraints, skills and expected data volumes make it suitable. Months later, those conditions change. Without recorded context, the original solution can look like a simple mistake. A concise architecture decision record explains the question, the alternatives and the consequences that were knowingly accepted. It makes later changes easier to understand in business and technical terms.
Record one decision, not an entire handbook
A decision record addresses a significant issue, such as choosing a synchronisation method or defining a system boundary. It does not need to describe the complete architecture again. Useful elements include context, options considered, the decision, material consequences and status. Rejected options may be particularly useful later. Their description should explain why they appeared less suitable under the circumstances, rather than dismissing alternative approaches universally. This keeps the record short enough to be read during everyday work.
Make a bounded assumption explicit
Consider a first implementation that uses an overnight data synchronisation. Its assumption is that business teams can tolerate information that is not refreshed until the following morning. A time-critical process is introduced later. The original decision need not be defended retrospectively as a universal recommendation. Instead, the team checks whether its documented premise still holds. A new decision can select a different synchronisation approach and refer explicitly to the changed operational requirement.
Connect history with the current position
An accepted record should not be silently overwritten when the underlying choice changes. A new decision can supersede and reference the previous one. Earlier knowledge and the current solution then remain distinguishable. This is especially useful for technical debt: a deliberate simplification can have explicit limits, review points or triggers for reassessment. A date alone is insufficient. The affected systems and the owner able to initiate a review are equally important.
Do not confuse documentation with control
A well-written record cannot automatically prevent a poor decision. Relevant participants must contribute, and accepted decisions need a connection to implementation. Reviews can check whether a particular system still matches the accepted choice or whether a deviation was deliberately authorised. Too many disconnected records can also become confusing. Records should therefore have meaningful names, useful links and a role in significant changes. Their value comes from connecting the reasoning, the actual system state and subsequent evolution.