© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Knigge für Softwarearchitekten

Kolumne: Knigge für Softwarearchitekten


Immer wieder jammern Kunden, dass Systeme schlecht seien und die IT die Anforderungen überhaupt nicht erfüllt habe. Entwicklungsteams verteidigen sich damit, dass ihnen niemand gesagt hat, was das Produkt wirklich können soll. Sie schieben die Schuld auf schlechte Anforderungen. Hätte man diese Wünsche rechtzeitig und klar geäußert, dann wäre die Lösung auch skalierbar, erweiterbar, performant und sicher. Fachbereiche oder Marketingabteilungen kontern: Es war doch klar, dass wir nach dem europäischen auch den asiatischen Markt erobern wollen. Selbstverständlich muss das Produkt leicht an neue Gesetze, Standards und Normen adaptiert werden können. Warum hätten wir das explizit sagen sollen?

Video: Know Your Enemies

Auch wenn wir heute zum Glück die leidigen Wasserfallprojekte hinter uns gelassen haben – haben wir? –, so gilt weiterhin eine Aufgabentrennung zwischen Beteiligten. Architekten und Entwicklungsteams verantworten hauptsächlich die Lösungen von Problemstellungen. Die Problemstellung in Form von mehr oder weniger präzisen Anforderungen sollte als Input für die Architekturarbeit vorhanden sein. Wir wissen seit Langem, was zu einer guten Requirements-Spezifikation gehört [1], [2]. Im Wesentlichen sind das die treibenden Kräfte für Projekte und Produktentwicklung: Die Ziele oder die Vision, wo wir hinwollen, die Mitspieler (neudeutsch: Stakeholder), denn sie sind die Quellen für alle Wünsche und Anforderungen, sowie die Festlegung des Scopes (Kontext), denn unsere Spielwiese ist nicht beliebig groß. Teams sollten wissen, was sie gestalten dürfen, wovon sie die Finger lassen müssen und welche Dinge außerhalb ihres Einflussbereichs liegen. Außerdem müssen Teams die gewünschte Funktionalität des Systems sowie die Prozesse und Aufgaben kennen, die ein System unterstützen soll. Dazu gehören auch die Daten und Informationen, die das System verwalten und verarbeiten muss. Last but not least müssen sie die gewünschten Qualitäten kennen und alle technologischen und organisatorischen Randbedingungen, die sie bei der Entwicklung oder Weiterentwicklung einhalten müssen. Wir betrachten, wie Input heute typischerweise für Entwicklungsprojekte vorliegt.

Der (traurige) Stand der Praxis

Wir beide sind geteilter Meinung, wie gut oder schlecht unsere Branche heute in Bezug auf die Vorgabe guter Anforderungen ist. In Tabelle 1 ist ein Kompromiss zwischen Peter, der die Anforderungswelt etwas positiver sieht, und Gernot, der oft noch viel Schlimmeres in Projekten erle...

Java Magazin
Kolumne: Knigge für Softwarearchitekten

Kolumne: Knigge für Softwarearchitekten

Immer wieder jammern Kunden, dass Systeme schlecht seien und die IT die Anforderungen überhaupt nicht erfüllt habe. Entwicklungsteams verteidigen sich damit, dass ihnen niemand gesagt hat, was das Produkt wirklich können soll. Sie schieben die Schuld auf schlechte Anforderungen. Hätte man diese Wünsche rechtzeitig und klar geäußert, dann wäre die Lösung auch skalierbar, erweiterbar, performant und sicher. Fachbereiche oder Marketingabteilungen kontern: Es war doch klar, dass wir nach dem europäischen auch den asiatischen Markt erobern wollen. Selbstverständlich muss das Produkt leicht an neue Gesetze, Standards und Normen adaptiert werden können. Warum hätten wir das explizit sagen sollen?

Peter Hruschka, Gernot Starke


Immer wieder jammern Kunden, dass Systeme schlecht seien und die IT die Anforderungen überhaupt nicht erfüllt habe. Entwicklungsteams verteidigen sich damit, dass ihnen niemand gesagt hat, was das Produkt wirklich können soll. Sie schieben die Schuld auf schlechte Anforderungen. Hätte man diese Wünsche rechtzeitig und klar geäußert, dann wäre die Lösung auch skalierbar, erweiterbar, performant und sicher. Fachbereiche oder Marketingabteilungen kontern: Es war doch klar, dass wir nach dem europäischen auch den asiatischen Markt erobern wollen. Selbstverständlich muss das Produkt leicht an neue Gesetze, Standards und Normen adaptiert werden können. Warum hätten wir das explizit sagen sollen?

Video: Know Your Enemies

Auch wenn wir heute zum Glück die leidigen Wasserfallprojekte hinter uns gelassen haben – haben wir? –, so gilt weiterhin eine Aufgabentrennung zwischen Beteiligten. Architekten und Entwicklungsteams verantworten hauptsächlich die Lösungen von Problemstellungen. Die Problemstellung in Form von mehr oder weniger präzisen Anforderungen sollte als Input für die Architekturarbeit vorhanden sein. Wir wissen seit Langem, was zu einer guten Requirements-Spezifikation gehört [1], [2]. Im Wesentlichen sind das die treibenden Kräfte für Projekte und Produktentwicklung: Die Ziele oder die Vision, wo wir hinwollen, die Mitspieler (neudeutsch: Stakeholder), denn sie sind die Quellen für alle Wünsche und Anforderungen, sowie die Festlegung des Scopes (Kontext), denn unsere Spielwiese ist nicht beliebig groß. Teams sollten wissen, was sie gestalten dürfen, wovon sie die Finger lassen müssen und welche Dinge außerhalb ihres Einflussbereichs liegen. Außerdem müssen Teams die gewünschte Funktionalität des Systems sowie die Prozesse und Aufgaben kennen, die ein System unterstützen soll. Dazu gehören auch die Daten und Informationen, die das System verwalten und verarbeiten muss. Last but not least müssen sie die gewünschten Qualitäten kennen und alle technologischen und organisatorischen Randbedingungen, die sie bei der Entwicklung oder Weiterentwicklung einhalten müssen. Wir betrachten, wie Input heute typischerweise für Entwicklungsprojekte vorliegt.

Der (traurige) Stand der Praxis

Wir beide sind geteilter Meinung, wie gut oder schlecht unsere Branche heute in Bezug auf die Vorgabe guter Anforderungen ist. In Tabelle 1 ist ein Kompromiss zwischen Peter, der die Anforderungswelt etwas positiver sieht, und Gernot, der oft noch viel Schlimmeres in Projekten erle...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang