Leistung /4
Softwarearchitektur: Beratung in Salzburg, bevor gebaut wird.
Der Bauplan steht vor der ersten Zeile Code. Wir prüfen ihn, und wo noch keiner existiert, erstellen wir ihn.
Software-Architektur ist die Menge der Entscheidungen, die sich später nur noch teuer ändern lassen. Welche Systeme miteinander sprechen und über welchen Weg. Wo Daten geführt werden und wer sie ändern darf. Was in einem Stück laufen muss und was getrennt betrieben werden kann. Diese Entscheidungen fallen in den ersten Wochen eines Vorhabens und bestimmen die Kosten der folgenden Jahre.
In den meisten Projekten fallen sie nebenbei. Der Grund ist Termindruck: Zuerst gebaut wird, was man vorzeigen kann. Die Architektur entsteht dann als Nebenprodukt aus vielen Einzelentscheidungen, von denen jede für sich vernünftig war.
Wir bieten diese Leistung in zwei Formen an. Als Review eines bestehenden oder geplanten Systems, mit schriftlichem Befund und festem Ende. Und als Begleitung über ein laufendes Vorhaben hinweg, in der wir von der Planung über die Implementierung bis zur Integration ansprechbar bleiben, ohne die Umsetzung selbst zu übernehmen. Beides ist auch dann buchbar, wenn Ihre Software von einem anderen Anbieter stammt oder im eigenen Haus entwickelt wird.
Der Vergleich, der im Haus seit 2003 gilt
Bei einem Gebäude käme niemand auf die Idee.
Niemand lässt ein Bürogebäude errichten, indem er Maurer und Elektriker bittet, einfach anzufangen. Es gibt einen Plan, der Statik, Leitungswege und Nutzung zusammenbringt, und dieser Plan entsteht, bevor die erste Fuhre Beton kommt. Er kostet einen Bruchteil des Baus und verhindert die Fehler, die im Rohbau nicht mehr korrigierbar sind.
Bei Software wird derselbe Schritt regelmäßig übersprungen, weil der Bau unsichtbar ist. Man sieht einem laufenden System nicht an, ob es tragfähig gebaut ist. Man merkt es erst, wenn ein weiterer Bereich angebaut werden soll und die Statik nicht mitspielt.
Der Unterschied zum Gebäude ist tückisch: eine schlechte Software-Architektur stürzt nicht ein. Sie wird nur jedes Jahr ein Stück teurer, und weil die Steigerung schleichend kommt, wird sie als normales Wachstum verbucht.
Woran Sie erkennen, dass die Architektur bremst.
Alle vier Anzeichen lassen sich in Ihren eigenen Aufwandszahlen nachrechnen.
- Anzeichen 1
- Jede Änderung dauert länger als die letzte. Der Aufwand für vergleichbare Anforderungen steigt über die Jahre. Das ist das verlässlichste Anzeichen, weil es sich in Ihren eigenen Aufwandszahlen nachlesen lässt.
- Anzeichen 2
- Kleine Änderungen erzwingen große Tests. Eine Anpassung an einer Stelle macht einen vollständigen Testdurchlauf nötig, weil niemand ausschließen kann, was sonst noch betroffen ist. Die Testkosten übersteigen dann regelmäßig die Entwicklungskosten.
- Anzeichen 3
- Dieselbe Information steht an mehreren Stellen. Kundenstammdaten, Preise oder Bestände werden in mehreren Systemen gepflegt und laufen auseinander. Der Abgleich passiert per nächtlichem Abgleichlauf, per Tabelle oder gar nicht.
- Anzeichen 4
- Neue Vorhaben scheitern an der Anbindung. Ein Portal, eine Auswertung oder eine KI-Anwendung ist fachlich unstrittig und technisch trotzdem nicht umsetzbar, weil die Daten nicht in brauchbarer Form herauskommen.
Diese Anzeichen sind messbar, und genau darin liegt ihr Wert für die interne Diskussion. Sie müssen niemanden von einem Gefühl überzeugen, wenn Sie die Aufwände vergleichbarer Anforderungen aus drei Jahren nebeneinanderlegen. Steigt die Kurve, hat das eine Ursache in der Struktur, und die Struktur ist veränderbar.
Wer prüft
Die Prüfung macht der Architekt selbst.
Die Prüfung macht Walter Raboch persönlich, Geschäftsführer und Softwarearchitekt. Er hat ingen 2003 gegründet und seither Projekte für mittelständische Unternehmen, Konzerne und öffentliche Auftraggeber verantwortet, von der Planung über die Implementierung bis zur Integration in gewachsene Landschaften.
Das ist der Unterschied, auf den es bei dieser Leistung ankommt: Sie sprechen mit der Person, die die Bewertung erstellt, und nicht mit einem Vertrieb, der sie anschließend an ein Team weitergibt. Rückfragen zu einer Empfehlung beantwortet derselbe Mensch, der sie getroffen hat, auch zwei Jahre später noch.
Wer über zwanzig Jahre Systeme gebaut hat, die heute noch laufen, bewertet einen Entwurf anders als jemand, der nur die Bauphase kennt. Die Fragen, die dabei zuerst kommen, betreffen selten die Technologie. Sie betreffen den Betrieb: Wer hält das in fünf Jahren am Laufen, und woran merkt er, dass etwas nicht stimmt?
Geschäftsführer und Softwarearchitekt
Das Architektur-Review als abgegrenzte Leistung.
Keine offene Beratung nach Aufwand, sondern ein Auftrag mit festem Umfang, festem Ergebnis und festem Ende.
- Gegenstand
- Ein bestehendes System, ein geplanter Neubau oder die Architektur eines laufenden Vorhabens, das ins Stocken geraten ist. Ein Altsystem ist keine Voraussetzung. Der häufigste Anlass ist eine anstehende Entscheidung mit langer Wirkung: eine Neuentwicklung, eine Ablösung, eine weitere Anbindung.
- Dauer
- Bei einem mittelgroßen System zwei bis vier Wochen ab Bereitstellung der Unterlagen. Ihr eigener Aufwand liegt bei etwa zwei bis drei Terminen zu je zwei Stunden.
- Grundlage
- Quelltext, Datenmodell, Schnittstellenübersicht, Betriebsumgebung und Gespräche mit den Personen, die das System täglich benutzen und betreuen.
- Ergebnis
- Ein schriftlicher Befund: tragende Struktur, Risiken nach Auswirkung geordnet, Empfehlungen mit Aufwandsklassen und eine begründete Reihenfolge für die nächsten zwölf Monate.
- Präsentation
- Eine Vorstellung des Befunds für Geschäftsführung und IT-Leitung gemeinsam, in einer Sprache, die beide Seiten prüfen können.
- Nicht enthalten
- Umsetzung. Das Review bewertet und empfiehlt, es baut nicht. Die Trennung ist beabsichtigt.
Ein Review ist damit ein abgeschlossener Vorgang mit Anfang und Ende. Sie wissen vorher, was es kostet, wie lange es dauert und was am Ende auf dem Tisch liegt. Für Vergabestellen und für Geschäftsführungen, die eine Ausgabe begründen müssen, ist genau das der entscheidende Unterschied zu einer Beratung nach Aufwand.
Was danach passiert.
Der Befund gehört Ihnen, vollständig und ohne Einschränkung. Er ist so geschrieben, dass ihn auch ein anderer Anbieter umsetzen kann: keine internen Kürzel, keine Verweise auf Werkzeuge, die nur wir bedienen, keine Passagen, die eine Beauftragung erzwingen.
Das ist die Bedingung dafür, dass die Bewertung unabhängig bleibt. Ein Review wird bei uns gleich abgerechnet, ob ein Folgeauftrag daraus entsteht oder nicht. Wenn die richtige Empfehlung lautet, den Bestand zu belassen oder ein Standardprodukt zu kaufen, dann steht das so im Befund.
Häufig folgt auf ein Review eine schrittweise Ablösung des Bestands. Sie beginnt dann mit einer Bestandsaufnahme, die auf dem Befund aufsetzt und ihn nicht wiederholt: Das Review sagt, ob und in welcher Richtung, die Bestandsaufnahme sagt, welcher der vier Wege für das konkrete Altsystem trägt und wo der erste Schnitt liegt. Genauso häufig folgt zunächst nichts, weil das Ergebnis lautet: Die Struktur trägt, die Schmerzen liegen woanders. Beides ist ein brauchbares Ergebnis für den Preis eines Reviews.
Wenn eine Umsetzung folgt, ist der Befund zugleich die Grundlage der Ausschreibung. Sie können ihn Anbietern vorlegen und bekommen Angebote, die sich vergleichen lassen, weil alle denselben Umfang bepreisen. Das ist bei Softwarevorhaben selten und ein guter Teil des Nutzens, den ein Review über die reine Bewertung hinaus bringt.
Häufige Fragen zur Architektur-Beratung.
Die Fragen, die vor einer Beauftragung regelmäßig gestellt werden.
Was liefert ein Architektur-Review konkret?
Einen schriftlichen Befund. Darin stehen die tragende Struktur des Systems, die Risiken nach ihrer Auswirkung geordnet, Empfehlungen mit Aufwandsklassen und eine begründete Reihenfolge für die nächsten zwölf Monate. Dazu kommt eine Präsentation für Geschäftsführung und IT-Leitung gemeinsam. Der Befund ist so geschrieben, dass ihn auch ein anderer Anbieter umsetzen kann.
Lohnt sich ein Review auch bei kleinen Systemen?
Es lohnt sich immer dann, wenn eine Entscheidung mit langer Wirkung ansteht: eine Neuentwicklung, eine Ablösung, eine Anbindung an ein weiteres System. Bei einer Anwendung mit wenigen Anwenderinnen und Anwendern und ohne Anbindung ist ein vollständiges Review meist zu groß. In diesen Fällen genügt oft ein einzelner Termin, und darauf weisen wir vorher hin.
Was kostet ein Architektur-Review?
Der Preis richtet sich nach Umfang und Alter des Systems und nach der Frage, wie viel Dokumentation vorliegt. Weil der Auftrag einen festen Umfang und ein festes Ende hat, nennen wir vor der Beauftragung einen Festpreis und keinen offenen Stundenrahmen. Die Größenordnung erfahren Sie im Erstgespräch, ohne dass Sie dafür Unterlagen herausgeben müssen.
Sind Sie unabhängig, wenn Sie anschließend die Umsetzung anbieten?
Review und Umsetzung sind getrennte Aufträge, und das Review ist ohne die Umsetzung vollständig. Der Befund darf zu dem Ergebnis kommen, dass nichts zu tun ist oder dass ein Standardprodukt die bessere Wahl wäre. Sie können ihn außerdem jedem anderen Anbieter vorlegen, weil er keine Passagen enthält, die nur wir umsetzen können.
Wer führt das Review durch?
Walter Raboch, Geschäftsführer und Softwarearchitekt, persönlich. Er hat ingen 2003 gegründet und verantwortet seither Projekte für mittelständische Unternehmen, Konzerne und öffentliche Auftraggeber. Sie sprechen also mit der Person, die die Bewertung erstellt, und nicht mit einem Vertrieb.
Wie viel Zeit müssen wir selbst einbringen?
Rechnen Sie mit zwei bis drei Terminen zu je zwei Stunden, dazu die Bereitstellung von Quelltext, Datenmodell und Schnittstellenübersicht. Beteiligt sein sollten eine Person aus der IT und eine Person aus dem Fachbereich, weil sich viele Risiken erst im Abgleich beider Sichten zeigen.
Wann brauche ich stattdessen eine Legacy-Bestandsaufnahme?
Wenn das abzulösende System bereits feststeht und die Entscheidung für eine Modernisierung im Grundsatz gefallen ist. Dann ist die Frage nach der Tragfähigkeit der Struktur bereits beantwortet, und offen bleibt, welcher von vier Ablösewegen für dieses System der richtige ist und wo der erste Schnitt liegt. Genau das beantwortet die Bestandsaufnahme auf der Seite zur Legacy-Modernisierung, und sie geht dafür tiefer ins Datenmodell und in die Nachtläufe. Das Review ist die Stufe davor: Es bewertet die Struktur, ordnet Risiken und legt eine Reihenfolge für zwölf Monate fest, auch für Systeme, die nie abgelöst werden.
Lassen Sie den Bauplan prüfen.
Ein Review ist eine abgegrenzte Leistung mit festem Ende und einem Ergebnis, das Ihnen gehört. Im Erstgespräch klären wir in einer halben Stunde, ob sich der Aufwand für Ihr System lohnt.
