Bei einem früheren Arbeitgeber habe ich Werkzeuge für den Workflow einer großen, regionalen Tageszeitung entwickelt. Mein bisher größtes Projekt (und mein erstes ernsthaftes Projekt in Python): Jede Nacht mussten ca. 400 Zeitungsseiten (als PostScript-Dateien von ca. 10–250 MB) in PDF umgewandelt werden, jeweils in zwei verschiedenen Auflösungen für Archivierung und Internet. Dabei hat sich herausgestellt, dass der Adobe Distiller weitaus die effektivsten PDFs erzeugt, allerdings mit diesen Datenmengen oft überfordert ist. Nach einem halben Jahr Entwicklungszeit lief meine Lösung so stabil, dass ich mich arbeitslos gemacht hatte (es wurde auf ein neu gekauftes System umgestellt, das diese Funktionen allerdings erst nach einem weiteren halben Jahr dazu bekam, obwohl sie von Anfang an bezahlt waren, während mein System ohne Betreuung offenbar problemlos weiter im Einsatz war). Ein paar Stichworte dazu:

• Dynamische Lastverteilung über mehrere Workstations (virtuelle Windows-Server), asynchron gesteuert von einem Twisted-Server.
• Auf jeder Workstation lief ein Distiller, der von einem Twisted-Client beschickt, überwacht und ggf. neugestartet wurde. Vor dem „Destillieren“ musste der PostScript-Code gepatcht werden, da er für die Druckplatten-Belichter zugeschnitten war und auf dem Distiller nicht immer funktionierte (Drehung, richtiges Setzen der Bounding Box, PDF-Zusatzbefehle, Korrektur von Sonderfarben).
• Die Mitarbeiter in der Produktionssteuerung konnten mit einem grafischen Werkzeug (Oberfläche mit wxPython) verfolgen, welche Seiten sich in welchem Zustand befanden (fehlend, in Verarbeitung, fertig) und ggf. eingreifen, um sie zu überprüfen oder neu anzufordern. Jede Seite wurde dabei durch einen farbigen Button symbolisiert. (Sie mussten jeweils warten, bis alles „grün“ war, d.h. alle Seiten fehlerfrei verarbeitet waren.) Eine erste Version mit Perl/Tk war unerträglich langsam.
• Die Daten über die Zusammenstellung der jeweiligen Regionalausgaben kamen zunächst aus manuell ausgefüllten Excel-Tabellen (hier waren eine hohe Fehlertoleranz und entsprechend sinnvolle Fehlermeldungen an die Mitarbeiter gefordert), später aus dem neuen Blattplanungs-System (wo zunächst monatelang sehr schwer zu parsende Textdaten zur Verfügung gestellt wurden, bis ich herausfand, wie ich die benötigten Daten direkt aus dem System abrufen konnte – ich war entsetzt, dass ein „großes, professionelles“ Workflowmanagement-System intern hauptsächlich aus einem Haufen Shellskripte bestand...).
• Die Daten wurden in einer MySQL-Datenbank gehalten; da der ursprüngliche Server mit der Fülle der Anfragen überfordert war und wir außerdem zur Sicherheit ein Backup haben wollten, gingen schließlich nur noch die Schreib-Anfragen zum Master-Server und die Lese-Anfragen an einen Slave.