Erleichterung der Software-Architektur

Vorwort

Wir entwickeln Software heute ganz anders als zu der Zeit, als ich vor mehr als 20 Jahren als Entwickler anfing.

Die Veränderungen, die stattgefunden haben - Agile, DevOps und der Übergang vom Projekt zum Produkt - haben alle eine zunehmende Dezentralisierung und Unabhängigkeit mit sich gebracht. Die Teams geben jetzt in der Regel ihren eigenen Code frei, betreuen ihre eigenen Systeme und entscheiden, wie sie die geschäftlichen Anforderungen lösen wollen.

Meiner Erfahrung nach ist die Rolle des Architekten diejenige, die am schwierigsten zu klären ist.

Als ich vor mehr als einem Jahrzehnt monolithische Systeme baute, arbeiteten die Architekten in einem separaten Team und entwarfen die Architektur für das gesamte System, legten Standards fest und entschieden, welche Datenbank, Programmiersprache oder welcher Bereitstellungsmechanismus verwendet werden sollte. Es gibt mehrere Gründe, warum das in modernen Unternehmen nicht mehr funktioniert: Diese Entscheidungen werden zu einem Engpass, der die Teams daran hindert, Fortschritte zu machen.

Aber was ist die Alternative? Du kannst den Teams erlauben, ihre eigenen architektonischen Entscheidungen zu treffen, indem du entweder Architekten beauftragst, direkt mit den Teams zusammenzuarbeiten, oder indem du "Architektur" zu einer Aufgabe machst, die von leitenden Ingenieuren erledigt wird (wie alles andere auch). Das kann jedoch zu sehr unterschiedlichen Ansätzen führen. Das kann riskant sein: Sind alle verschiedenen Datenspeicher ...