Softwarearchitektur als Hebel für erfolgreiche Projekte

Warum Softwarearchitektur immer wichtiger wird
Kommentare

Wie würden Sie beim Hausbau auf einen Handwerkertrupp reagieren, der nicht lang fackelt und gleich loslegt – ohne sich groß um Statik, Grundriss oder Leitungsplan zu kümmern – und das mit Termindruck begründet? Was beim Hausbau inakzeptabel ist, kommt in der Softwareentwicklung als Quick-and-Dirty-Vorgehen gar nicht so selten vor. Etliche Unternehmen haben die Risiken dieser Methode erkannt, worauf die in den letzten fünf Jahren steigende Nachfrage an Softwarearchitekten hinweist. Dieser Artikel erläutert, warum in Softwareprojekten die Architektur immer wichtiger wird.

Immer höhere und umfangreichere Kundenanforderungen machen Softwaresysteme zunehmend komplexer. Oftmals bemerken wir als Benutzer gar nicht, was für eine Unmenge an Software hinter den Kulissen arbeitet. Denken Sie an die Mercedes-S-Klasse, die 20 Millionen Zeilen Code allein im Radio- und Navigationssystem aufweist – ganz zu schweigen von der Software für Cruise Control, Einparkhilfe, Spurhaltesystem oder Motor- und Getriebesteuerung. Es wird geschätzt, dass ein moderner Oberklassewagen bis zu 100 Millionen Zeilen Code aufweist. Direkt wahrnehmbar ist die Evolution des Windows-Betriebssystems als Basis für zunehmend anspruchsvollere Anwendungen: Windows NT 3.1 kam noch mit 4 bis 5 Millionen Zeilen Code aus, Windows NT 4.0 mit 11 bis 12 Millionen, Windows XP benötigte schon 40 Millionen Zeilen Code und es wird vermutet, dass Windows 7 über 50 Millionen Zeilen Code besitzt. Denken Sie an die Fortentwicklung des statischen Internets hin zum Social-Media-Zeitalter und daran, was Sie früher von einer Webanwendung erwartet haben und was Sie heute als selbstverständlich voraussetzen können!

Softwarearchitektur immer wichtiger

In dem Maße, wie Komplexität und Umfang der funktionalen und nicht funktionalen Anforderungen steigen und technische und vor allem auch organisatorische Einflussfaktoren zunehmend berücksichtigt werden müssen, wird die Architektur der Systemlösung mit ihren Szenarien, Bau- und Ablaufplänen immer relevanter. Bereits mittelgroße Softwaresysteme besitzen oftmals matrixartige Systemstrukturen aus Modulen, Subsystemen und Schichten mit fachlichen und technischen Querschnitten, die mithilfe der Architekturdokumentation beschrieben, geplant und umgesetzt werden. Lösungsideen, technische Konzepte, Entwurfsentscheidungen und vor allem Qualitätsanforderungen wie Ausfallsicherheit, Zusammenspiel verteilter Systemkomponenten, Richtigkeit, Effizienz und Flexibilität sind wichtige Bestandteile der Softwarearchitektur. Einen guten Überblick über die Qualitätsmerkmale von Software gibt die ISO 9126 als ein Modell für Softwarequalität.

Zum Scheitern verurteilt

Dabei gilt: Die Missachtung zentraler Architekturaspekte kann Projekte scheitern lassen. Denn was passieren kann, wenn Qualitätsanforderungen oder Einflussfaktoren nicht genügend berücksichtigt werden, zeigen drei prominente Beispiele aus der Praxis der vergangenen Jahre.
Das Jobportal der Bundesanstalt für Arbeit beispielsweise hielt bei seinem Livegang 2003 dem Ansturm der Benutzer nicht stand, da man auf eine Million Zugriffe pro Tag nicht eingestellt war. Suchkriterien wurden teilweise ignoriert, und es wurden Stellen angezeigt, deren Bewerbungsfrist bereits abgelaufen war. Nach viel Kritik ging knapp sechs Jahre und viele Millionen Euro später im August 2009 eine neue, überarbeitete und ausgereiftere Internetjobbörse online.
Auch die Verwaltungssoftware für das Arbeitslosengeld II namens A2LL war von Anfang an mit Mängeln behaftet und verursachte Zusatzkosten in dreistelliger Millionenhöhe. „Die Software A2LL ist nicht so anpassungsfähig und flexibel programmierbar, wie wir es brauchen“, kritisierte Heinrich Alt, Vorstand der Bundesagentur für Arbeit, in der Computerwoche. Vor allem sei es schwierig, gesetzliche Änderungen zügig in dem System abzubilden. 2013 soll A2LL durch eine neue Software ersetzt werden.
Ein weiteres prominentes Beispiel ist der elektronische Entgeltnachweis Elena, der es zum Ziel hatte, Bürokratie abzubauen und das Meldeverfahren zu automatisieren. Hierfür sollten die notwendigen Informationen wie Verdienst- und Arbeitsbescheinigungen zur Beantragung von Sozialleistungen zentral gespeichert werden. Aber auch Kündigungsgründe, Abmahnungen oder Fehlzeiten waren ursprünglich zur Speicherung vorgesehen. Mit Hinweis auf die fehlende Verbreitung elektronischer Signaturen stoppte das Bundeswirtschaftsministerium 2011 das neun Jahre zuvor gestartete Projekt. Hintergrund war aber nach Meinung vieler Kritiker wohl auch der juristische Widerstand gegen die zentrale Datenspeicherung sensibler Arbeitnehmerdaten. Die Arbeitgeberverbände bezifferten ihre Kosten durch das Scheitern des Projekts auf mehrere hundert Millionen Euro. Zusätzlich entstanden Projektkosten im mittleren zweistelligen Millionenbereich.

Aufarbeitung – häufig Fehlanzeige

Interessanterweise werden die Ursachen fehlgeschlagener Projekte in der Praxis selten genauer untersucht und aufgearbeitet; auch nicht durch das betroffene Unternehmen selbst, obwohl das Wissen um die Hintergründe helfen könnte, das Risiko weiterer scheiternder Projekte zu verringern. Vermutlich sind die Motive hierfür oft pragmatischer Natur: Welche Firma möchte schon noch mehr Geld und Zeit in erfolglose Projekte investieren und welcher Mitarbeiter seine eigene Karriere gefährden? Sehr wahrscheinlich ist, dass ein Teil der Verantwortung auch auf das Konto der Softwarearchitekten geht – sofern sie denn existieren, wovon man in größeren Projekten allerdings ausgehen kann –, denn sie sind es, die letztendlich für die Beachtung von technischen und organisatorischen Rahmenbedingungen und für die Produktqualität verantwortlich sind – letztere gemessen an den Qualitätsanforderungen des Kunden. Allerdings können auch die besten Architekten kein Projekt retten, wenn sie nicht die Unterstützung des Managements haben und für die Projektziele ungeeignete Rahmenbedingungen herrschen, die sie wegen fehlender Befugnisse nicht in der Lage sind zu beeinflussen.

Aufmacherbild: Portrait of worker in a construction site von Shutterstock / Urheberrecht: Minerva Studio

[ header = Seite 2: Softwarearchitektur auch in kleinen und mittelgroßen Projekten notwendig ]

Softwarearchitektur auch in kleinen und mittelgroßen Projekten notwendig

Nicht nur in Großprojekten wie den aufgeführten, sondern auch in kleinerem Kontext ist Architektur, also die Dokumentation der Softwarelösung, unerlässlich. Als Maßstab, ab welcher Systemgröße Sie eine Architekturdokumentation benötigen, mag Ihnen die Abschätzung dienen, ob ein Chefentwickler allein in der Lage ist, den vollständigen Überblick über das System zu haben. Wenn nicht, benötigen Sie eine Dokumentation allein schon deshalb, damit die Entwickler überhaupt in der Lage sind, an den verschiedenen Subsystemen, Modulen und Komponenten der Applikation zu arbeiten, ohne als einzige Referenz nur den Quellcode zu haben und viel Zeit (und damit Geld) mit der Einarbeitung in die Fachlichkeit und Technik zu verschwenden. Vergessen Sie auch nicht, dass hin und wieder neue Entwickler ins Projekt kommen, deren typische Fragen ein Architekturüberblick beantworten kann.
Kompetenzen eines Softwarearchitekten
Die bloße Existenz eines Softwarearchitekten im Projekt allein bewirkt noch nicht viel. Die Rolle muss mit den nötigen Kompetenzen ausgestattet sein und der Architekt über ein breites Wissen verfügen. Ein Architekt

• benötigt Soft Skills, vor allem Team- und Kommunikationsfähigkeit,
• besitzt idealerweise Führungskompetenzen, denn er übernimmt die Verantwortung für die Qualität der gelieferten Software und hat eine Vorbildfunktion im Team und
• muss in seiner Rolle von den Vorgesetzten anerkannt sein, um seine Entscheidungen im Entwicklungsteam durchsetzen können.

Er muss die Sprache der am Projekt beteiligten Stakeholder sprechen, mit ihnen im kontinuierlichen Informationsaustausch stehen und in der Lage sein, zur Erreichung der Projektziele auch unbequeme Entscheidungen zu treffen. Er darf nicht im Elfenbeinturm fernab der Technik residieren, sondern sollte von den Entwicklern respektiert werden und am besten einer der „ihren“ sein. Optimalerweise verfügt ein Architekt über ein breitgefächertes methodisches Wissen, fundierte Programmierkenntnisse und arbeitet in direkter räumlicher Nähe zum Entwicklungsteam.

Softwarearchitekten sollen sich die Hände schmutzig machen

Es gibt gute Gründe für das Anforderungsprofil des Softwarearchitekten. Moderne Softwaresysteme zeichnen sich durch eine Vielzahl verwendeter Sprachen, Frameworks und Libraries aus, deren Auswahl oder zumindest die fundierte Entscheidung über ihren Einsatz zu den Aufgaben des Softwarearchitekten gehört. Softwarearchitekten sollten in der Lage sein, als Grundlage ihrer technischen Konzepte oder machbarkeitsstudientechnische Durchstiche oder Prototypen zu implementieren – oder wenn sie diese Aufgaben delegieren, die Ergebnisse zu bewerten. Die Methoden und Werkzeuge von „früher“ – denken Sie zum Beispiel an die Softwareentwicklung, wie sie noch um die Jahrtausendwende stattgefunden hat! – haben sich in erheblichem Maße weiterentwickelt, um die Anforderungen moderner Softwaresysteme effizient umsetzen zu können. Leistungsfähige IDEs, Modellierungswerkezeuge, Build und Continuous Integration Tools, Codegeneratoren, objektrelationale Mapper (ORM), GUI-, Komponenten- und Application Frameworks sind heutzutage aus dem Projektalltag nicht mehr wegzudenken. Die Anwendung der Methoden (agile Softwareentwicklung, Test-driven Development (TDD), Pair Programming, Refactoring usw.) und die Auswahl der Werkzeuge haben einen erheblichen Einfluss auf das Projekt und seine Ressourcen.

Gute Dokumentation ist cool

In Entwicklungsteams hat Dokumentation einen schlechteren Ruf als sie verdient. Die unter Developern allseits bekannten Phrasen „Der Code ist die Dokumentation!“ oder „Der Code spricht für sich!“ sind in der Praxis eine Hürde, da sie es verhindern, sich zeitlich unabhängig einen schnellen Überblick zu verschaffen.
Erst die Architekturdokumentation macht Strukturen und Entscheidungen für alle Stakeholder nachvollziehbar und stellt die unterschiedlichen Sichten auf das Softwaresystem dar. Der Kunde kann ihr entnehmen, ob der Auftraggeber die Anforderungen verstanden hat und das Operating, wie die Softwareartefakte zu installieren oder Jobs zu planen sind. Neue Teammitglieder bekommen mit ihrer Hilfe eine Vorstellung davon, wie das Projekt strukturiert ist und warum bestimmte Designentscheidungen getroffen wurden. Für die Entwickler schafft sie einen Rahmen für die Implementierung, macht Vorgaben etwa hinsichtlich der verwendeten Architektur- und Entwurfsmuster und stellt Prinzipien auf (z. B. DRY – don’t repeat yourself).
Ein Softwarearchitekt sollte verständlich, kompakt und am besten anhand eines strukturgebenden Templates dokumentieren können. Eine kostenfreie, praxisnahe und gut dokumentierte Vorlage ist arc42.
Fertigen Sie hiermit parallel zur Umsetzung zumindest einen Architekturüberblick an (etwa vierzig Seiten inklusive aller Diagramme können hierfür bereits genügen)! Sie werden erleben, dass Sie zum Beispiel Fragen, warum Features auf eine bestimmte Art und Weise umgesetzt worden sind, in Zukunft besser beantworten können. Dass Eigenarten im Code darauf zurückzuführen sind, dass die Implementierung historisch gewachsen ist, werden Sie dann als Rechtfertigung nicht mehr benötigen!

Gesucht: Entwickler mit einem Gespür für Architektur

Aufgrund unvollständiger und sich ändernder Anforderungen oder Rahmenbedingungen ist es nicht möglich, bereits zu Projektbeginn die komplette Architektur fertigzustellen. Was für Programmcode gilt, trifft auch auf die Architektur zu: Ganz im Stil agiler Vorgehensmodelle sollte sie das Ergebnis eines iterativen und inkrementellen Rückkopplungsprozesses mit den anderen Projektbeteiligten sein, Reviews unterzogen und gegebenenfalls angepasst werden. Dies setzt voraus, dass nicht nur der Architekt, sondern vor allem auch die Entwickler ein Bewusstsein für die Notwendigkeit der Softwarearchitektur haben und über architekturrelevantes Wissen wie typische Architekturmuster, Design-Patterns, die wesentlichen Architektursichten und ihre Darstellung verfügen, damit sie einerseits Feedback geben und andererseits die Implementierung im Rahmen der vorgegebenen Architektur vornehmen können.
Entwickler mit Blick auf die Softwarearchitektur werden in desto höherem Maße benötigt, je komplexer das Softwaresystem und je stärker damit das Bedürfnis nach verständlichen, einfachen und effektiven Strukturen ist. Ohne ein entsprechend qualifiziertes Entwicklungsteam kämpft auch der beste Softwarearchitekt auf verlorenem Posten! Gegebenenfalls sollten Sie rechtzeitig vor Projektbeginn Weiterbildungsmaßnahmen ins Auge fassen. Während des Projektverlaufs bleibt hierfür in den seltensten Fällen Zeit.

Fazit

Schaut man sich die Verteilung der Kosten über die Lebensdauer einer Applikation an, so stellt man fest, dass nur etwa 20 Prozent der Kosten während der Planungs- und initialen Entwicklungsphase entstehen. 80 Prozent der Kosten dagegen fallen nach der Inbetriebnahme durch Betrieb, Maintenance und Weiterentwicklung an. Da sie im Gegensatz zu den einmalig auftretenden Projektkosten über viele Jahre wiederkehrend sind – denn Softwaresysteme haben in der Regel eine Lebensdauer höher als fünf Jahre (fünf Jahre beträgt allein die steuerliche Abschreibungsdauer) – sollten sie bereits von Projektbeginn an mit berücksichtigt und Maßnahmen ergriffen werden, um sie möglichst gering zu gehalten.
Softwarearchitekten und Entwickler können hierzu einen wichtigen Beitrag leisten, indem sie ein System entwerfen und implementieren, das möglichst langfristig einsetzbar ist und wartbar, verständlich und änderbar bleibt – eben nicht Quick and Dirty.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -