Case · Architektur-Review einer B2B-Plattform
Frauenthal
Fünf Wochen, 15 Systeme, drei Dienstleister im Interview: eine schriftliche Bewertung der Frauenthal Business Plattform mit 13 priorisierten Handlungsempfehlungen — belastbar genug, um sie dem Vorstand vorzulegen.
Ausgangslage
Die Frauenthal Handel Gruppe ist die Nummer 1 im österreichischen Großhandel für Installateure, Bauherren, Bauträger, Architekten und Kommunen — mit den Großhändlern SHT und ÖAG, der Kontinentale, Elektromaterial.at, 25 Bad & Energie Schauräumen und über 75 ISZ Abholmärkten.
Zentraler Baustein der Digitalstrategie ist die Frauenthal Business Plattform: Sie stellt internen und externen Applikationen Daten und Services über eine einheitliche API bereit — den B2B-Apps auf Android und iOS ebenso wie dem E-Commerce-System, das die bisherigen B2B-Shops ablöst. Warenverfügbarkeit, Preise und Belege kommen dabei aus ERP und PIM.
Gebaut wurde die Plattform von einer externen Entwicklungsagentur, das CMS kam von einem zweiten Dienstleister, den Betrieb verantwortete ein dritter. Kurz vor dem Launch stellte sich für den Vorstand die Frage, die sich in dieser Konstellation immer stellt: Trägt das, was da entstanden ist? Und weiß das jemand, der nicht selbst daran verdient hat?
Aufgabe
Eine unabhängige Bewertung der Plattform entlang von vier Kriterien: Funktionsfähigkeit, Zukunftssicherheit, Sicherheit und Skalierbarkeit. Nicht als Momentaufnahme, sondern als Entscheidungsgrundlage — mit priorisierten Risiken und einer Handlungsempfehlung zu jedem einzelnen davon.
Der Prüfumfang: 15 Systeme und Komponenten — die Bausteine der Plattform selbst sowie die angebundenen Umsysteme rund um ERP, Produktdaten und die mobilen B2B-Apps. Dazu Hosting, Entwicklungsprozess, Testverfahren, Zugriffskonzept und Projektmanagement.
Architektur-Entscheidungen
Den Entwicklern zuhören, nicht nur den Code lesen
Kern des Reviews war ein zweitägiger Workshop vor Ort bei der Entwicklungsagentur, in dem wir jedes relevante Modul gemeinsam mit den Leadentwicklern durchgegangen sind. Ein Code-Review zeigt, was gebaut wurde. Erst das Gespräch mit denen, die es gebaut haben, zeigt warum — welche Annahme hinter einer Entscheidung stand, welcher Termindruck sie erzwungen hat und was das Team selbst für die schwächste Stelle hält. Diese Fragen beantwortet kein Repository.
Alle drei Dienstleister befragen, nicht nur einen
Die Plattform verteilte sich auf drei Häuser: Entwicklung, CMS und Hosting. Ein Review, der nur mit einem davon spricht, bekommt eine Version der Wahrheit. Wir haben mit allen dreien gesprochen — dazu mehrere Calls mit den Hauptentwicklern für Detailfragen. An den Nahtstellen zwischen den Dienstleistern lagen erwartungsgemäß die interessantesten Fragen.
Sich Zugang verschaffen statt Auskünfte einholen
Wir haben uns Zugang zu allen relevanten Git-Repositories und zur Infrastruktur-Dokumentation geben lassen, statt uns den Entwicklungsstand beschreiben zu lassen. Dazu die Analyse des bereits durchgeführten Lasttests. Ein Review, das auf Selbstauskunft beruht, bestätigt am Ende, was man ihm erzählt hat.
Jedes Risiko mit einer Handlungsempfehlung
Eine Liste von Problemen ist keine Entscheidungsgrundlage, sondern eine Beschwerde. Jedes gefundene Risiko wurde nach Kritikalität eingestuft und mit einer konkreten Handlungsempfehlung versehen — 13 insgesamt, sortiert nach Dringlichkeit. So kann der Auftraggeber entscheiden, was er angeht, was er terminiert und was er bewusst stehen lässt.
Auch sagen, was gut ist
Ein Review, das nur Mängel findet, ist wertlos: Er lässt offen, worauf man aufbauen kann. Die Bewertung benennt deshalb ausdrücklich die tragfähigen Entscheidungen — die gewählten Technologien, das Container-Setup, das Branching-Konzept und die Skalierungsstrategie des Hostings. Das ist keine Höflichkeit, sondern die halbe Information: Wer nicht weiß, was trägt, reißt im Zweifel das Falsche ein.
Ergebnis
Am Ende standen 49 Seiten: eine schriftliche Beurteilung des Entwicklungsstands und der Systemarchitektur, ein nach Kritikalität geordneter Risikenkatalog und 13 priorisierte Handlungsempfehlungen — jede mit Verweis auf das Kapitel, in dem der Befund im Detail steht.
Fünf Wochen lagen zwischen Projektstart und der ersten Fassung. Das Format ist bewusst so gewählt, dass es intern weitergereicht werden kann: Das Management Summary trägt die Entscheidung allein, die Detailkapitel halten der Rückfrage aus den Fachbereichen stand.
Frauenthal arbeitet seit 2022 mit WBFK.
„Das Jahr 2022 stand bei Frauenthal ganz im Zeichen des Launches unserer neuen Digitalisierungsplattform. WBFK hat hierbei tolle Arbeit geleistet und uns durch einen Architekturreview die verbleibenden Optimierungspotentiale aufgezeigt. Die Zusammenarbeit war äußerst professionell, fachlich und technisch fundiert sowie zuverlässig. Wir werden in weiteren Projekten gerne wieder auf die Unterstützung zurückgreifen.“
Häufige Fragen zum Frauenthal-Projekt
Was ist ein Architektur-Review und wann lohnt er sich?
Ein Architektur-Review bewertet eine bestehende Softwarelandschaft unabhängig auf Funktionsfähigkeit, Zukunftssicherheit, Sicherheit und Skalierbarkeit. Er lohnt sich immer dann, wenn viel Geld in einer Plattform steckt und die Beteiligten am Ergebnis mitverdienen — vor einem Launch, vor einer Budgetfreigabe, vor einem Dienstleisterwechsel oder wenn im Betrieb Probleme auftreten, deren Ursache niemand benennen kann.
Wie lange dauert ein Architektur-Review?
Bei der Frauenthal Business Plattform lagen fünf Wochen zwischen Projektstart und Maßnahmenkatalog — bei 15 geprüften Systemen und drei beteiligten Dienstleistern. Die Dauer bestimmt weniger die Größe des Codes als die Zahl der Häuser, mit denen gesprochen werden muss, und die Verfügbarkeit der Leute, die die Entscheidungen getroffen haben.
Kann man eine Plattform bewerten, die eine andere Agentur gebaut hat?
Ja — und das ist der Normalfall, denn wer selbst gebaut hat, kann sich nicht unabhängig prüfen. Entscheidend ist, wie der Review geführt wird: mit Zugang zu den Repositories statt mit Selbstauskunft, im direkten Gespräch mit den Leadentwicklern statt über Statusberichte, und mit einer Bewertung, die auch benennt, was tragfähig gebaut wurde.
Was bekommt man am Ende eines Architektur-Reviews in die Hand?
Eine schriftliche Beurteilung des Entwicklungsstands, einen nach Kritikalität geordneten Risikenkatalog und zu jedem Risiko eine konkrete Handlungsempfehlung. Bei Frauenthal waren das 49 Seiten mit 13 priorisierten Empfehlungen — in einem Format, das intern weitergereicht und dem Vorstand vorgelegt werden kann.
Reicht ein Code-Review, oder braucht es Workshops mit dem Entwicklungsteam?
Ein Code-Review zeigt, was gebaut wurde — nicht warum. Bei Frauenthal war der zweitägige Workshop vor Ort bei der Entwicklungsagentur der ergiebigste Teil des Projekts: Welche Annahme hinter einer Architekturentscheidung stand, welcher Termindruck sie erzwungen hat und was das Team selbst für die schwächste Stelle hält, steht in keinem Repository.
Zweifel, ob Ihre Architektur trägt?
Sie schildern den Stand, wir sagen, wo es trägt und wo nicht — belastbar begründet, ohne Verkaufsfolien.