Sizing? Was ist das?

Vor nicht allzu langer Zeit wurde ich zu einem Projekt hinzugerufen. Es war ein kleines Projekt mit einer an sich kleinen Aufgabe und kurzer Laufzeit. Daten sollten von einem Quellsystem an SAP übergeben werden und dort in eine Tabelle geschrieben werden. Anschließend sollten sie von dort weiterverarbeitet werden. An der Weiterberarbeitung saß man schon etwas länger dran. Ab hier wurde es kompliziert da etliche Regeln und Logiken angewendet werden mussten. Man war aber zumindest im Projekt schon so weit endlich das Quellsystem anzuschließen. Endlich mal sehen was für Daten denn eigentlich wirklich so reinkommen würden.

Das Quellsystem band wiederum mehrere weitere Systeme an und sendetet die konsolidierten Daten dann an SAP weiter. Dazwischen gab es noch eine Middleware und die Schnittstellen waren SOAP Web Services. An sich ziemlich Standard in der SAP-Welt.

Bei der Besprechung ging es dann hauptsächlich um die Felder, Datentypen, ob ein Mapping notwendig ist, Fehler- und Statuscodes. Da ich mich jetzt nicht so direkt in der einfachen Entwicklerrolle sehe, sondern gerne auch mal etwas mitdenke, fragte ich dann: und das Sizing? Die Antwort war ernüchternd: Sizing? Was ist das? Ich meinte das ich gerne wissen würde was für eine Menge an Daten denn eigentlich über die Leitung gehen: was kommt wie oft in welcher Menge rein? Die Antwort war hier leider nur ein: keine Ahnung. Wer sich fragt: Warum? Einfach: Sizing macht man nicht. Die Teilnehmer – Entwickler, Projektleiter, Anforderer – wussten nicht was das ist. Sie wussten auch nicht über welche Datenmenge man spricht. Man war gewohnt das so ein Thema gar nicht zur Sprache kommt. Sollte etwas aufgrund der Menge nicht funktionieren, so würde man dies ja entweder in QA oder in der Produktion merken. Und dann ist es hoffentlich erstmal das Problem der Systemverantwortlichen. Diese Vorgehensweise lässt mein Architektenherz leiden. Ich setzte mich durch das man die Datenmenge in Erfahrung bringt.

Ein paar Wochen danach kam es zur nächsten Besprechung. Die erwartete Datenmenge waren etliche tausend Nachrichten aus den angeschlossenen Systemen und mehrere zig MB Payload. Dies wollte man abends einmal an das SAP-System schicken. Diese Nachricht führte auf der Middleware Seite zu dem Einwand das der Payload nicht größer als 1 MB sein darf, da ansonsten die Middleware abstürzt. Auf der SAP-Seite kam der Einwand das die Logik, die man implementiert hatte, gut für kleine Datenmengen funktionierte. Kamen mehrere tausend Datensätze auf einmal, so war die Ausführungszeit viel zu lange, da Abhängigkeiten zwischen den Datensätzen aufgelöst wurden. Kurz: die Idee einfach Daten zu senden war nach dem ersten Sizing schon gescheitert.

Die Lösung war die Datensätze zu verkleinern: je nach Quellsystem wurden sie geclustert. Die Daten wurden mehrmals die Stunde gesendet, so dass die Logik es schaffte die Daten in kleinen Stücken zu verarbeiten. Der Payload wurde auf wenige KB pro Aufruf reduziert. Im Endeffekt waren dies alles Aufgaben, die man so oder so hätte machen müssen. Nur wurden sie Dank des Sizings schon in der Entwicklungsphase berücksichtigt. Es wäre besser gewesen dies schon in der Planungsphase zu tun. Aber man lernt ja nie aus, oder?

Einige Monate später wurde ich zu einem ähnlichen Projekt gerufen. Meine Frage ob man die erwartete Datenmenge schon kenne wurde beantwortet mit: Nein, wieso?