Hauptgedanke

Will man ein Werkzeug an einem anderen Ort schreiben lassen — zum Beispiel einen Chat-Assistenten auf einen persönlichen Server —, lautet die spontane Frage: Wie bringe ich es dazu, meinen Dienst aufzurufen? Sie führt dazu, eine Schnittstelle zu bauen, dann festzustellen, dass sie sich nicht aufrufen lässt, und dann nach einem Umweg zu suchen.

Die andere Frage, an ihrer Stelle gestellt, verändert die Ausgangslage: Wo kann dieses Werkzeug bereits schreiben? Sie verlangt nicht mehr, einen Weg zu öffnen, sondern die vorhandenen Wege zu erfassen. Die Antwort kann eine Tabelle sein, ein Dateispeicher, ein bereits verbundener Dienst — etwas Mittelmäßiges aus Sicht der angestrebten Architektur, aber sofort verfügbar.

Die erste Frage richtet sich auf ein Hindernis, die zweite auf eine Ressource.

Warum das wichtig ist

Es ist ein billiger Perspektivwechsel: Er kostet nur eine Umformulierung, und er kommt in dem Moment, in dem man am stärksten festgefahren ist — nach einem technischen Fehlschlag, wenn alle Energie in den Umweg fließt.

Er bringt auch ein Ergebnis anderer Art hervor. Was man erhält, ist nicht die gewünschte Architektur, sondern ein Weg, der sofort funktioniert und den man später ersetzen kann.

Nuancen und Grenzen

Die Bestandsaufnahme der vorhandenen Wege kann leer ausfallen, und dann bleibt die Frage ohne Antwort.

Und was sie liefert, ist ein Kompromiss: ein Werkzeug hinzunehmen, das man nicht gewählt hätte, mit seinen Grenzen. Die Gefahr ist, sich dauerhaft darin einzurichten, statt es als Zwischenschritt zu behandeln.

Offene Fragen

• Wann entscheidet man, dass ein Ausweichweg zur endgültigen Architektur wird?