Gergely Orosz 23.09.2019, 07:50 Uhr

Software Architektur wird überschätzt

Gergely Orosz ist professioneller Entwickler, hat an großen Projekten gearbeitet und vertritt die These: Software Architektur wird überschätzt, Simples Design dagegen unterschätzt.
Wikimedia Server Architektur
(Quelle: wikimedia.org )
Entwickler Gergely Orosz hat an großen Systemen mitgearbeitet, beispielsweise an der Neugestaltung von Ubers verteilten Zahlungssystemen, der Entwicklung und dem Versand von Skype auf Xbox One und Ubers Framework für mobile Architektur. Alle diese Systeme, so sagt er, hatten gründliche Designs, durchliefen mehrere Iterationen und hatten viel Whiteboarding und Diskussion. Alle Entwürfe wurden dann zu einem Designdokument eingedampft, das an die Entwickler verteilt wurde. Hunderte Entwickler bauten an den Systemen oder auf sie auf, und Millionen von Menschen benutzen die Systeme Tag für Tag. Die Neufassung des Uber-Zahlungssystems musste zwei bestehende Zahlungssysteme ersetzen, die von Dutzenden anderen Systemen und Dutzenden von Teams genutzt wurden. An dieser App arbeiteten mehrere hundert Ingenieure gleichzeitig, um bestehende Funktionen auf eine neue Architektur zu portieren. All diese Projekte, sagt Orosz, kamen ohne einen Software Architekten aus. Bei Uber beziehungsweise Microsoft/Skype gäbe es überhaupt keine Position eines Software Architekten. Und seine Gespräche mit Entwicklern anderer großer FANG-Companies (FANG = Facebook, Amazon, Netflix, Google) ergaben, dass diese dort dieselben Erfahrungen gemacht haben. Auch die typischen strukturierten Architektenwerkzeuge, wie etwa UML oder konkrete Design-Patterns kamen nicht zum Einsatz. Wie die Projekte dennoch erfolgreich beendet werden konnten erklärt Orosz in seinem ausführlichen Blogbeitrag. Im Zentrum stehen die folgenden sechs Schritte:
  1. Mit dem Business-Problem beginnen. Was ist zu lösen, welches Produkt soll entstehen. Wie kann man den Erfolg messen.
  2. Den Ansatz per Brainstorming im Team diskutieren. Dabei vom höheren Level zu niedrigeren Leveln voranschreiten.
  3. Den Ansatz auf einem Whiteboard festhalten.
  4. Eine einfache Dokumentation mit einfachen Diagrammen erstellen.
  5. Über Nachteile und Alternativen sprechen. Keine Design-Entscheidung ist von sich aus gut oder schlecht, es kommt auf den Kontext und die Ziele an.
  6. Das Design-Dokument zur Diskussion stellen (bei Uber wurde es an alle 2.000 Ingeniere verschickt), Feedback sammeln und Korrekturen einbauen.
Dieser Ansatz ist gar nicht so anders als in vielen Architektur-Büchern gefordert. Die Hauptunterschiede: Die genannten Firmen nutzen einfache Design-Werkzeuge, etwa Office 365 oder Google Docs und es gibt eine sehr flache Hierarchie. Dies alles mündet bei Orosz in der Forderung: "Simple, jargonless software design over architecture patterns".
Lesen Sie mehr im umfangreichen Beitrag von Gergely Orosz.


Das könnte Sie auch interessieren