Software Architektur und was sie bedeutet

If you think good architecture is expensive, try bad architecture.
(Brian Foote & Joseph Yoder)

Software-Entwickler arbeiten zu 80% an bestehendem Code. Das bedeutet, dass sie sich in 20% der Fälle die Architektur auf der grünen Wiese erstellen können. Leider ist die Wiese oft gar nicht so grün, denn es gibt schon im Vorfeld viele Restriktionen, die die Software-Architektur beeinflussen.

Viel schwieriger ist es in den restlichen 80%. Dabei gilt es bestehende Architektur zu erkennen, zu bewerten und gegebenenfalls zu verbessern.

Die Aufgabe, eine qualitativ hochwertige Software-Architektur zu bauen beziehungsweise zu pflegen, ist anspruchsvoll. Die Anforderungen, die dabei an den Architekten gestellt werden, sind mittlerweile nicht mehr nur programm-technischer Natur. Der Software-Architekt muss nicht nur die Design-Patterns kennen, die Programmier-Technologie, die Speichertechnologie, die Leistungsfähigkeit der Algorithmen, er muss auch die Server-Technologie berücksichtigen, die Domain-Sprache der Fachanwendung verstehen und viele Softskills besitzen. Diese benötigt er, um die Architektur nach Conways-Law an die Firmenstruktur anpassen zu können und andersherum die Architektur gegenüber den Stakeholdern aufgrund der technologischen Notwendigkeiten zu verteidigen.

Die Software-Architektur nutzt nicht mehr nur den Entwicklern, sondern ist Basis für die Beurteilung des Systems nach außen und hilft Produktmanagern, Stakeholdern und Systemadministratoren. Dazu muss sie leicht verständlich sein und an die Sprache des Zielpublikums angepasst werden.

• ist verantwortlich für die innere und äußere Qualität des Systems,
• bewahrt das System davor, zu scheitern oder unflexibel für zukünftige Anpassungen zu werden
• definiert die technologische Vision des Systems und passt diese gegebenenfalls aufgrund seiner Analysen an.

Die Systeme sind zu komplex geworden, und die Wechselwirkungen mit anderen Bereichen zu stark, als dass der Software-Architekt Blaupausen von fertigen Systemen anfertigen könnte. Die Fertigkeiten, die er früher für die Erstellung der Blaupausen hatte, benötigt er heute aber weiterhin.

Aber seine täglichen Aufgaben sind viel weiter gesteckt:

• Er hält Ausschau nach möglichen Problemen und bewertet diese bevor sie zu großen Problemen werden.
• Er hilft anderen Entwicklern, sich zu verbessern und im System zurecht zu finden.

If an architect tries to know the whole system, he is the bottleneck.

Der Software-Architekt kann nicht mehr das ganze System kennen. Dafür sind die Systeme zu komplex und zu schnelllebig geworden. Er muss sich auf sein Entwickler-Team verlassen können. Er muss auf das Wissen im Team aufbauen können, das er selbst dort implementiert hat.

It is expensive to know everything.

Software-Architektur ist Kommunikation. Der Software-Architekt muss authentisch sein, sonst kommen seine Themen nicht an, und er bekommt nicht die notwendigen Rückmeldungen für die weitere Beurteilung des Systems.

Trust is the bandwidth of communication.
(Karl-Erik Sveiby)

Das Architektur-Antipattern 'Big Ball of Mud' wurde mehr oder weniger erfolgreich bekämpft, nur manchmal kommt dabei ein 'big ball of microservice mud' heraus. Manchmal ist es schwierig, herauszufinden, welcher Service nun genau den Mehrwert für den Benutzer bringt, im Gegensatz zu den Services, die einen rein technologischen Zweck zu erfüllen haben. Die Systeme werden so komplex, dass es unmöglich scheint, den genauen Prozess abzubilden, der zur Erfüllung einer Benutzer-Anforderung notwendig ist. Dem Software-Architekten bleibt die Aufgabe, auf grundsätzliche Werte wie Qualität, Leistungsfähigkeit, Sicherheit, Flexibilität und Ausfallsicherheit zu achten.

Architecture is a hypothesis, that needs to be proven by implementation and measurement.
(Tom Gilb)

Die Lebenszyklen bei der Software-Produktion werden immer kürzer und sind geprägt von: build, unit-test, deploy to test, integration-test, deploy to production and measure. Dabei kommt den Systemen, auf denen entwickelt, getestet, ausgeliefert und bereit gestellt wird, eine immer größere Bedeutung hinsichtlich Zuverlässigkeit, Konsitenz, Flexibilität und Einfachheit zu. Das bedeutet, dass DevOps ein Thema ist, mit dem sich der Software-Architekt auseinander setzen muss.

Letztendlich werden die Benutzer darüber entscheiden, wie erfolgreich ein System ist. Der Architekt kann noch ein so gutes System bauen, er muss es für den Benutzer tun, und es an dem feedback und den Bedürfnissen des Benutzers ausrichten.

Aufgrund der genannten Anforderungen kann man sagen, dass sich die feste Rolle des Software-Architekten mehr und mehr auflöst. Dies findet zugunsten von flexibel nicht fest zugeordneten Fähigkeiten in Entwickler-Teams statt, in denen die Aufgaben des Architekten von allen übernommen werden. Dabei können Spezialisierungen auftreten, müssen aber nicht. Da es ja auch auf Kleinigkeiten ankommt, liegt die Verantwortung bei jedem und kann nur durch eine gute Kommunikation getragen werden.

Kevlin Henney und Frank Buschmann bringen es in ihrem Talk auf der OOP2017 auf den Punkt:

Software Architects are dead! Long live Software Architects!