Fallstudie
Downtown Auto Sales, ein Gebrauchtwagenhändler in Anchorage, Alaska, kauft beschädigte Fahrzeuge, repariert sie und verkauft sie. Das ist das System, mit dem der Betrieb arbeitet — und das Produkt, das daraus wurde.
Der Händler hatte eine Website voller Fahrzeuge und Tabellen voller Zahlen, und dazwischen keine Verbindung. Jedes Auto wurde zweimal erfasst: einmal im Büro mit Einkaufs- und Reparaturkosten, einmal auf der Website mit dem Verkaufspreis. Ein Auto, das am Dienstag verkauft wurde, stand am Freitag noch online.
Die naheliegende Lösung — alles in ein Online-System — war die falsche, und der Grund dafür hat die ganze Architektur bestimmt. Der Bürodatensatz enthält, was jedes Auto gekostet hat, was die Reparatur gekostet hat und wie hoch die Marge ist. Ein Teil davon darf für die Verkäufer nie sichtbar sein, und nichts davon gehört auf einen geteilten Server, nur weil es bequem wäre.
Zwei Hälften, die sich an genau einem Punkt treffen. Eine Windows-Anwendung auf dem Bürorechner hält alles. Eine Website zeigt nur, was ein Kunde sehen soll. Die Naht dazwischen ist eine Einbahnübertragung einer festen Liste öffentlicher Felder.
Die Entscheidungen
Einkaufspreis, Teile, Arbeit, Marge und der ausgehandelte Verkaufspreis bleiben in einer verschlüsselten Datenbank auf dem Rechner des Händlers. Was zur Website geht, wird aus einer Liste erlaubter Felder gebaut — eine nächstes Jahr ergänzte Spalte kann also nicht dadurch nach aussen gelangen, dass jemand sie vergisst. Es ist an drei Stellen durchgesetzt, und der Build schlägt fehl, wenn der Test das nicht bestätigt.
Ein Auto wird auf dem Platz als verkauft markiert, und der Datensatz wird geschrieben und festgeschrieben, bevor irgendetwas irgendwohin geht. Ist die Website nicht erreichbar, hat der Verkauf trotzdem stattgefunden und die Übertragung wird später wiederholt. Die Kasse eines Händlers darf nicht auf den Server eines anderen warten.
Der Verkaufsleiter sieht jedes Auto und keine Kosten. Das ist keine ausgeblendete Spalte in der Oberfläche — die Datensätze, die er bekommt, haben die Zahlen nie enthalten. Auf seinem Bildschirm gibt es nichts aufzudecken.
Jeder Fehlschlag sagt, welches Glied gebrochen ist und was zu tun ist: die Seite hat nicht geantwortet, dem Zertifikat wird nicht vertraut, das Passwort wurde abgelehnt, dieses Konto darf nicht veröffentlichen. Mit „Verbindung fehlgeschlagen“ kann niemand etwas anfangen, der auf einem Platz in Anchorage steht.
Im Büro
Auf der Website des Händlers
Die Anwendung ist täglich im Einsatz. Fahrzeuge erscheinen und verschwinden von selbst, die Dokumente drucken aus dem Datensatz, und das Ganze öffnet sich an einem Morgen, an dem das Internet es nicht tut.
Die Website ist fertig und wartet auf eine einzige Sache, die kein Code ist: den Tag, an dem die Domain darauf zeigt. Das ist eine Entscheidung des Inhabers, getroffen an einem ruhigen Tag mit einer Sicherung in der Hand — nichts, das man nebenbei einschiebt.
Das System begann als Bürowerkzeug eines einzigen Händlers und ist heute ein Produkt. Nichts über diesen Händler — kein Name, keine Adresse, kein Logo — steht irgendwo im Code; alles liegt in einem Profil, das der Inhaber beim ersten Start ausfüllt. Genau das lässt dieselbe Anwendung beim nächsten Händler laufen, ohne dass eine Zeile geändert wird.
Ausserdem gebaut
Zweimal getippt, oder in einer Tabelle, die sonst niemand öffnen kann. Erzählen Sie uns, was es ist.