BDUF

BDUF ist die Abkürzung für „Big Design Upfront“, also für einen umfassenden Lösungsentwurf vor der Realisierung.

Bevor ich kurz der Frage nachgehe, warum BDUF in der agilen Gemeinde gewöhnlich negativ konnotiert ist, möchte ich (ebenso kurz) anreißen, was für BDUF spricht: Einen umfassenden Entwurf für ein zu realisierendes System oder eines Teils davon vor der Realisierung zu erstellen, verursacht zwar höhere Aufwände vor der Realisierung, birgt jedoch das Potential, spätere Anpassungen (Restrukturierungen) durch Antizipation zu vermeiden und vereinfacht zudem die Zerlegung einer großen Aufgabe in kleinere entlang der Entwurfsstruktur. Ein BDUF wird meistens mit derartigen Kosten-Nutzen-Abwägungen begründet.

Dem gegenüber steht die Kritik, dass der Nutzen in der Praxis häufig gar nicht oder erheblich geringer eintritt und dass sich das tatsächliche Kosten-Nutzen-Verhältnis zu oft als negativ erweist. Folgende Argumente und Annahmen sind Teil dieser Kontroverse:

  • Es lassen sich sowieso nicht alle wichtigen Entwurfsentscheidungen vorweg sicher bestimmen, egal mit welchem Aufwand, d.h. sie erweisen sich später als unzureichend oder mangelhaft. BDUF ist also mehr oder weniger spekulativ.
  • Der Aufwand, Entwurfsentscheidungen vor der Realisierung abzusichern, wird häufig unterschätzt
  • Der Aufwand, fehlende oder mangelhafte Entwurfsentscheidungen nach einer ersten Realisierung zu korrigieren, wird häufig überschätzt. Testautomatisierung, testgetriebene Entwicklung, stetige direkte Kommunikation mit dem Kunden (bzw. Product Owner) und in kurzen Iterationen institutionalisiertes Feedback (Inkrementbegutachtungen) und weitere agile Techniken tragen erheblich dazu bei, Entwurfsentscheidungen viel kostengünstiger zu korrigieren und Entwurfsentscheidungen zu einem sehr frühen Zeitpunkt nach der Realisierung zu validieren.
  • Erst nach der Überprüfung der Realisierung ist eine objektive Aussage über die Brauchbarkeit von Entwurfsentscheidungen möglich.
  • Viele entscheidungsrelevante Erkenntnisse ergeben sich erst in der praktischen Auseinandersetzung mit dem Problemgegenstand, also während der Realisierung, und lassen sich nicht theoretisch vorweg nehmen bzw. antizipieren.

 

Schlagwörter: ,

Kommentare

  1. Das Konzept ist in der Automobilbranche für jedes Fahrzeug üblich!. Die Designentscheidung (meist vom Vorstand direkt) ist Voraussetzung dafür, dass ein Projekt aufgesetzt wird. Vielleicht hinkt der Vergleich, weil die meisten Fahrzeugprojekte ähnlich wie die Vorgängerfahrzeuge ausfallen, aber selbst bei kompletten Neuentwicklungen folgt man dieser Linie. Ohne BDFU würde kein Hersteller die Milliardensummen für das Fahrzeug freigeben, da hängt also viel Geld dran, deshalb will man natürlich wissen, wie das Ergebnis (ungefähr) aussieht. Das Design wird dann üblicherweise im Verlauf der 2-5 Jahre Produktentwicklung an die neuen Marktanforderungen angepasst, das kann bis kurz vor dem SOP Start of Production eines Fahrzeugs sein, hier ist dann ein durchgängiges Änderungsmanagement mit Einbezug aller (ca. 500) Partner gefragt…

  2. avatar Roland Spengler

    Ich habe leider zu oft auch in der IT Projekte erlebt, in denen das Zwiebelschalenmodell die Kosten extrem hat steigen lassen, gerade weil man am Anfang keinen BDFU-Ansatz gefahren hat.

    Ich weiss nicht warum immer wieder die Konzeption an sich in Frage gestellt wird, wenn Agilisten sich darüber unterhalten. Das Problem ist doch, dass man sich am Anfang überhaupt erst einmal selbst klar werden muss, was man erreichen will. Sonst hat man die Anforderung eines geländegängigen Ferrari mit Anhängerkupplung für 20 Tonnen Anhängerlast in military-grün und einer Beschleunigung von Null auf Hundert in 3 Sekunden …

    Man kann natürlich den BDUF perfektionistisch übertreiben und das Pareto-Prinzip vergessen. Aus solchen Negativ-Beispielen aber immer gleich den BDUF-Ansatz zu verdammen ist doch falsch.

    Ich glaube viele IT-Projekte scheitern weil man sich am Anfang eben keine umfassenden Gedanken darüber gemacht hat, was man eigentlich umsetzen will. Die Ignoranz des Managements und der Fachabteilungen eine gründliche Planung aufzusetzen kann man dann auch durch die besten Methoden nicht mehr gerade ziehen. Natürlich hilft der agile Prozess dann überhaupt ein Ergebnis zu erzielen, die Frage muss aber doch erlaubt sein, ob nicht auch in vielen dieser Fälle das Produkt wesentlich kostengünstiger und schneller hätte fertig werden können, wenn sich die entscheidenden Spieler vorher vernünftig Gedanken zum Was und Wie gemacht hätte.

    Also müsste die Diskussion nicht agil vs. klassisch und dann auch noch BDFU vs. kein BDFU lauten, sondern erfolgreiche, effiziente Projekte durch Anforderungsmanagement.

    Bei der Diskussion wird immer gerne ein Aspekt vergessen:
    – der Rechenzentrumsbetrieb und seine Kosten

    Es mag ja sein, dass im Projekt der Nutzen durch BDFU am Ende nicht kompensiert werden kann, wenn man aber dann wegen Design-Fallen 10-mal so viel Hardware hinstellt als nötig, dann wird in Zukunft (steigende Energiekosten) das Fehlen des BDFU richtig teuer.

    Fazit: So lange Blech und Energie viel billiger waren als Gehirnleistung waren die Aussagen noch tragbar, die Welt wandelt sich aber gerade.

  3. avatar Alfred Oswald

    Als ich den Beitrag gelesen habe, habe ich mich gefragt, was für mich denn ein BDUF sei. Als wir vor ca. 10 Jahren das erste Mal in unserem Unternehmen einen MDA-Ansatz (Model-Driven Architecture- Ansatz) verfolgt haben, hatten wir den Anspruch und auch den nötigen Enthusiasmus eine vollständige Softwarekomponenten Architektur zu erstellen, wobei jede (!) Komponente, bzw. jeder Service, mittels UML-Modellen beschrieben wurde. Dies ist für mich ein BDUF.
    Die damit verbundene Komplexität ist förmlich über uns hereingebrochen und wir haben seither keinen so verstandenen BDUF mehr durchgeführt. Da wir Business Systeme erstellen, sind unseren Realisierungen im Normalfall umfangreiche Geschäftsprozessanalysen vorgelagert. Den Geschäftsprozessanalysen folgen Anforderungsanalysen gefolgt von Konzepten zur Architektur und dem Design der IT-Systeme. Bezogen auf diese Analysen und Konzepte würde ich von einem Big Concept Up Front (BCUF) sprechen. Hierbei ist der Grad der Ausarbeitung bei der Geschäftsprozessanalyse sehr hoch und beim Design, verglichen mit einem oben geschilderten BDUF, gering. Das BCUF wird sehr oft von fachlichen oder technischen Prototypen begleitet, die entsprechende Risikobereiche vor der eigentlichen Realisierung beleuchten. Die Realisierung enthält agile Prozesselemente je nach Projekt und Kundenwunsch.
    Die BDUF/BCUF-Frage, die sich stellt, ist: Unter welchen Risiken könnte man das so verstandene BCUF zu Gunsten einer „reinen“ agilen Vorgehensweise „auflösen“ und würde man zusätzlich Zeit und Geld gewinnen sowie die Qualität steigern?
    Da wir bisher die gleichen Projekte nicht nach verschiedenen Vorgehensmodellen bearbeiten durften ;-), lässt sich meines Erachtens diese Frage nicht abschließend beantworten. Nach meinem bisherigen Erfahrungsstand würde ich jedoch davor abraten, BCUF zu sehr zu reduzieren, zumal wenn die Projekte innovativ oder komplex sind. In diesen Fällen kann es durchaus sinnvoll sein, diese Systeme in kleinere Teile zu zerlegen, und diese leichter verdaulichen Teile gemäß BCUF getrennt zu konzipieren und anschließend agil (!) zu realisieren. Eine größere Reduktion von BCUF zugunsten einer agilen Realisierung ist mir für komplex und innovative Projekte zu risikoreich.

  4. Hier stellt sich die Frage was ein „umfassenden Lösungsentwurf“ eigentlich ist? Eine Umschreibung unter der jeder was anders versteht. Bei einem mittleren 1000 Klassen Projekt müssen wie viel % der Klassen vorher entworfen werden?

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>