Softwarearchitekt: "Ein gutes Framework sollte einfach zu verwenden sein"

Im Interview spricht der Softwarearchitekt Peter Hruschka ĂĽber Framework-Architektur, Wiederverwendung und Wissensaustausch.

vorlesen Druckansicht 14 Kommentare lesen

(Bild: Zakharchuk/Shutterstock.com/heise medien)

Lesezeit: 4 Min.

(Bild: Peter Hruschka)

Peter Hruschka ist einer der Autoren und begeisterter Nutzer der Open-Source-Dokumentationsvorlage arc42 fĂĽr die Architekturkommunikation und -dokumentation. Die Vorlage req42 fĂĽr agile Business Analysts und Requirements Engineers hat er ebenfalls mitbegrĂĽndet. Er arbeitet als Partner bei der Atlantic Systems Guild, einem internationalen Think Tank.

iX: Welche Eigenschaften zeichnen ein gutes Software-Framework aus? Was gehört außer Dokumentation noch dazu?

Peter Hruschka: Frameworks und Bibliotheken sind nützliche Hilfsmittel für Entwickler, um sie von meist technischen Aufgaben zu entlasten. Daher sollte ein gutes Framework einfach zu verwenden sein und fehlerhaften Gebrauch verhindern – ähnlich wie gute Schnittstellen. Und ja: Damit sie leicht zu verwenden sind, sollten sie gut dokumentiert sein.

Mehr Infos
SAG-Logo mit Funkturm Berlin

(Bild: iSAQB)

Am 25. und 26. November 2025 findet das iSAQB Software Architecture Gathering erneut in Berlin statt. Das Programm der Konferenz bietet gut 40 englischsprachige Vorträge und Keynotes. Peter Hruschka hält die Eröffnungs-Keynote "Framework Architectures".

FĂĽr die Anwender des Frameworks sollte die Dokumentation alles abdecken, was Developer wissen mĂĽssen, um das Framework korrekt in eigene Systeme zu integrieren. Beim Entwickeln eines Frameworks gelten dieselben Regeln wie fĂĽr jedes System: Es sollte ausreichend Dokumentation vorhanden sein, um kĂĽnftige Erweiterungen zu entwickeln, ohne dass eine umfangreiche Ăśberarbeitung des bestehenden Frameworks erforderlich ist.

iX: Sollte man Frameworks erfinden, also am Reißbrett entwerfen, oder aus konkreten Lösungen extrahieren?

Hruschka: Da die meisten Frameworks technische Probleme lösen, denke ich, dass sie am Reißbrett entworfen werden können. Das Bereitstellen von Tools zum Erstellen von Webanwendungen, zur Vereinfachung von Datenbankinteraktionen, zum Erstellen von Benutzeroberflächen oder zur Unterstützung beim Schreiben automatisierter Tests betrifft allgemein bekannte Themen.

Wenn jedoch eine Organisation mehrere ähnliche Systeme oder Produktfamilien in einer bestimmten Domäne entwickelt, ist die Wahrscheinlichkeit hoch, dass das Team domänenspezifische Abstraktionen entdeckt und in Form von Frameworks herausarbeiten kann.

Ich würde daher schätzen, dass das Verhältnis zwischen technischen Frameworks und domänenspezifischen Frameworks bei 80 zu 20 liegt.

Videos by heise

iX: Würden Sie generell mehr Menschen dazu ermutigen, neue Frameworks aus ihrer Arbeit zu entwickeln, zu veröffentlichen und zu fördern, oder ist Framework-Engineering eine eher außergewöhnliche Tätigkeit?

Hruschka: Bezogen auf die zuvor genannten Beobachtungen würde ich Organisationen nicht dazu ermutigen, ins kommerzielle Framework-Business einzusteigen. Das Marketing von Frameworks sollte Unternehmen überlassen werden, die sich auf solche Produkte spezialisiert haben – oder Open-Source-Projekten.

Aber jedes große IT-Unternehmen sollte sich bemühen, wiederverwendbare Ideen zu entdecken und diese in Form von Frameworks und Bibliotheken herauszuarbeiten – nicht mit der Absicht, sie zu vermarkten, sondern um die interne Effizienz in der Produktentwicklung zu verbessern, statt in jedem Projekt das Rad neu zu erfinden.

iX: Hilft standardisierte und etablierte Terminologie dabei, die Abstraktheit von Frameworks zu bewältigen? arc42 ist recht weit verbreitet und bringt eine eigene Terminologie mit. Gibt es andere Quellen für gut verstandene allgemeine Konzepte?

Hruschka: arc42 ist eine generische Vorlage für alle Arten von Anwendungen – einschließlich Frameworks. Während Kapitel 5 von arc42, also die Bausteinsicht, für die meisten Anwendungen von zentraler Bedeutung ist, ist es für die Anwender von Frameworks weniger wichtig. Kapitel 8, das die Querschnittskonzepte behandelt, spielt eine wichtigere Rolle.

Solche übergreifenden Konzepte zu finden und zu dokumentieren ist immer noch eine Kunst und erfordert Abstraktionsvermögen von denjenigen, die Frameworks entwickeln. Wir empfehlen, dass die Dokumentation solcher Konzepte nicht nur deren zentrale Abstraktionen identifiziert, sondern auch sehr praktische Informationen wie Beispiele, Prototypen, Laufzeitszenarien und Testfälle mit Quellcode enthält.

iX: Gute Dokumentation findet die richtige Balance zwischen Text und visuellen Inhalten sowie zwischen konzeptionellen Beschreibungen und sehr konkreten Anweisungen. Der Zugang zu Experten, interaktivem Feedback und aktivem Lernen ist sehr hilfreich, wenn es darum geht, eine Technologie wie ein Framework oder eine Bibliothek zu ĂĽbernehmen. Was kann man tun, um diese Dimension abzudecken?

Hruschka: Der Zugang zu Experten ist definitiv viel hilfreicher als sich nur auf Dokumentation zu verlassen. Wenn kein direkter Zugang möglich ist, versucht die Open-Source-Initiative arc42 auf vielfältige Weise zu helfen – insbesondere mit umfangreichen, veröffentlichten FAQs und vielen praktischen Tipps.

Da Entwicklerinnen und Entwickler am besten dadurch lernen, dass sie erfolgreiche Lösungen kopieren, veröffentlichen wir außerdem vollständige Systemdokumentationen aus vielen verschiedenen Domänen auf Leanpub.

Nach zwei Bänden über kommerzielle Systeme und eingebettete Echtzeitsysteme, die bereits verfügbar sind, ist ein ergänzender dritter Band über Frameworks und Bibliotheken in Vorbereitung.

Das Interview führte Richard Wallintin von WPS – Workplace Solutions.

(rme)