IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Du wirst es nicht brauchen - Wie finde ich das richtige Maß für eine Architektur

Kategorie: Trends des Monats
Wavebreak Media | © ThinkstockYou Ain’t Gonna Need It (YAGNI) – Du wirst es nicht brauchen – ist eines der ältesten Design-Prinzipien der Software-Entwicklung. YAGNI hat unter anderem in das eXtreme Programming (XP) Eingang gefunden: Never add functionality early. Es empfiehlt, keine Annahmen über die zukünftige Entwicklung einer Software zu treffen, sondern nur das zu entwerfen und zu entwickeln, was tatsächlich benötigt wird. Nicht nur in der IT tun wir uns schwer, verlässliche Annahmen über die Zukunft zu treffen. Warum kann ich als Architekt den Blick in die Glaskugel nicht einfach lassen und mich auf die Realität konzentrieren? Eine gute Praxis ist es, Entscheidungen so spät wie gerade noch vertretbar zu teffen. Warum? Weil wir gerade in der IT in einer stark veränderlichen Welt leben und die Gültigkeit einer Entscheidung mitunter nur wenige Wochen, Tage oder Stunden beträgt.

In meiner Rolle als Architekt bin ich in den vergangenen Jahren häufig der Versuchung erlegen, Überlegungen wie „diese Anforderung kommt garantiert im nächsten Release, also können wir das System auch gleich darauf vorbereiten.“ ernst zu nehmen und vorsorgliche Veränderungen zum Beispiel im Komponentenschnitt meiner Systeme vorzunehmen. Genauso häufig habe ich diese Veränderungen, die immer anders benötigt wurden, als von mir prognostiziert, wieder zurück gebaut. Alternativ hat mich die vorsorgliche Veränderung später so stark behindert, dass ich sie komplett zurückbauen musste. Ich weiß, dass viele Architekten vor demselben Problem stehen.

Für YAGNI gibt es eine Reihe bekannter Anti-Patterns. Hinter dem Swiss Army Knife verbirgt sich beispielsweise ein Stück Software oder ein Artefakt, dass „alles“ kann. Es ist natürlich auch geeignet, ohne Anpassung zukünftige Anforderungen abzudecken. In der Realität verbirgt sich hinter einer solchen Software hochkomplexer, unwartbarer Code, den ein Architekt, ein Entwickler oder ein ganzes Team in einem Rausch von kreativer Planung und Entwicklung verursacht hat und für den es nur zwei valide Visionen gibt: Refactoring mit hohem Aufwand oder schnellstmögliche Entsorgung. Die Ansätze von Big Design Up-Front (BDUF) oder Big Modeling Up-Front (BMUF) aus der Welt der plangetriebenen Vorgehensmodelle entsprechen dem Anti-Pattern des Swiss-Army-Knife. Bei beiden Ansätzen erzeuge ich mit viel Aufwand Artefakte auf Architektur oder fachliche Modelle, die nach meiner Erfahrung immer mit noch mehr Aufwand gepflegt und an veränderte Anforderungen und Rahmenbedingungen angepasst werden müssen.

Ein Vorteil bei YAGNI ist zweifellos, dass weniger Aufwand in Artefakte investiert wird, die sich, bis sie benötigt werden, verändern werden. Aus vielen Jahren Projektalltag weiß ich, dass dies potenziell alle Artefakte betrifft. Generell ist aber auch beim YAGNI-Ansatz Aufwand erforderlich. Wenn ich jetzt eine Architektursicht benötige, fertige ich diese an. In dem Moment, in dem ein konkretes, aktuelles Problem bearbeitet wird, entsteht unter Umständen Mehraufwand, der mit etwas vorausschauender Planung hätte minimiert werden können.



YAGNI vs. Big Design Up-Front © Capgemini

Im Kontext Architektur macht es sich aus meiner Sicht über einen längeren Zeitraum bezahlt, einen Mittelweg zwischen BDUF und YAGNI zu finden. Dabei ist das ideale Maß aus vorausschauender Planung und kurzfristiger Entscheidung vom konkreten Problem abhängig und kann nicht pauschal bemessen/benannt werden.

Was denken Sie über diesen Ansatz? Schreiben Sie ihre Meinung.

Weiterführende Gedanken zur Reduzierung oder Minimierung von Aufwänden im Kontext Architektur haben Matthias Ehlert und ich im Artikel Änderbarkeit auf Lebenszeit – Lean-Prinzipien in der Architektur für das OBJEKTspektrum niedergeschrieben.



Bildnachweis: Wavebreak Media | © Thinkstock

Über den Autor

Ramon Anger
Ramon Anger
Ramon Anger bewegt sich zwischen mehreren Stühlen: Sitzt er auf dem linken Stuhl, arbeitet er als technischer Architekt an Entwicklungsprojekten mit. Sitzt er rechts, schreibt er Artikel für Fachzeitschriften oder seinen Blog. Der Stuhl vor ihm steht für Konferenztourismus. Auf dem Platz in der Mitte treibt er für Capgemini die Themen Agilität und Lean voran. Still sitzt er selten, denn dafür gibt es zu viele spannende Themen und neue Ideen zu entdecken.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.