IT Architect thinking about horizontal and vertical scaling in a cloud based IT world400x400

IT Architektur ist Teamwork / Architecture is team work

cropped Andreas Hartig 003Veröffentlicht von

IT-Architektur ist eine komplexe und wichtige Komponente jeder Organisation und erfordert die Zusammenarbeit verschiedener Teams und Abteilungen. “IT Architecture is Team Work” ist ein Grundsatz, der betont, dass die Planung und Implementierung einer effektiven IT-Architektur eine gemeinsame Anstrengung verschiedener Teams erfordert.

Ein wichtiger Aspekt von “IT Architecture is team work” ist die Notwendigkeit einer umfassenden Zusammenarbeit und Koordination zwischen den Teams. Dies bedeutet, dass die Teams eng zusammenarbeiten müssen, um die Anforderungen der verschiedenen Stakeholder zu verstehen und sicherzustellen, dass die IT-Architektur alle notwendigen Anforderungen erfüllt.

Was für IT Architektur Ansätze für Organisationen gibt es?

Wie können die IT Architektur Teams in den zunehmend agilen Strukturen aussehen? Diese Definitionen basieren auf Beschreibungen zu dem Thema von “Stefan Toth”. Zur weiteren Vertiefung kann ich diesen Artikel von ihm empfehlen.

Klassicher Architekt*innen

In diesem klassischen Ansatz treffen die Enterprise Architekt*innen oder das Enterprise Architekturboard die “wichtigen” Entscheidungen zu den Architekturfragen. Die Rolle der Entwickler*innen beschränkt sich auf Feedback und Umsetzung der entsprechenden Architekturvorgaben.

klassische Architekten
klassische Architekt*innen

Unterstützender Architekt*innen

Bei diesem Ansatz liegt der Fokus der Architekt*innen auf dem Bereich Unterstützung und Mentoring. Hier wird Architektur bereits zu einer Rolle welche oft nicht in Vollzeit ausgefüllt wird.

Unterstuetzende Architekten
Unterstuetzende Architekten

Architekturagenten und Architekturagentinnen

Von Architekturagenten spricht man, wenn bestimmte Themenbereiche (SQL, .Net, Datenmodelle, …) von Entwickler*innen mit Spezialwissen aus Architektursicht begleitet oder kontrolliert werden.

Architekturagenten
Architekturagenten und Architekturagentinnen

Kein benannter Architekt

Hier treffen und kommunizieren (hoffentlich) die jeweils involvierten Entwickler selbständig die Entscheidungen.

Kein benannter Architekt
Kein benannter Architekt*innen

Die Komponenten Kommunikation

Eine weitere wichtige Komponente von “IT Architecture is Team Work” ist die Notwendigkeit einer klaren Kommunikation zwischen den Teams. Es ist wichtig, dass die Teams regelmäßig kommunizieren, um sicherzustellen, dass alle Beteiligten über den Fortschritt und die Herausforderungen der IT-Architektur informiert sind.

Darüber hinaus ist es wichtig sicherzustellen, dass die beteiligten Teams über die notwendigen Kenntnisse und Fähigkeiten verfügen, um die IT-Architektur effektiv zu planen und umzusetzen. Dies kann bedeuten, dass Schulungen und Weiterbildungen angeboten werden, um sicherzustellen, dass alle Teammitglieder über die notwendigen Fähigkeiten und Kenntnisse verfügen.

Die Kommunikation wird am besten über so genannte Architectural Decision Records dokumentiert und nachvollziehbar abgelegt. Dieses Thema der Kommunikation im Rahmen der Digitalisierung ist sehr komplex und es gibt wenige immer gültige Ansätze, sondern hier ist der Kontext wichtig. So kann es z.B. in einem Berater- und Entwicklerunternehmen sinnvoll sein, dass diese Entscheidungen im Repository, also z.B. Github abgelegt werden.

Architectural Decision Records (ADR)

Ein Architecture Decision Record (ADR) ist ein Dokument, das eine wichtige architektonische Entscheidung eines Teams festhält, einschließlich ihres Kontexts und ihrer Konsequenzen. ADRs haben einen Lebenszyklus und werden verwendet werden, um jede Entscheidung im Zusammenhang mit der Architektur einer Anwendung zu dokumentieren. Mit ADRs erfassen wir sowohl funktionale als auch nicht-funktionale Anforderungen, die einen messbaren Einfluss auf die Architektur und Qualität eines Softwaresystems haben. Die Sammlung von ADRs in einem Projekt bilden das Entscheidungsprotokoll.

Wer sich für das Thema ADRs interessiert, der schaut sich diese Quelle auf Github an und den Artikel von Eltjo Poort zu diesem Thema.

Es hilft häufig ADRs als Story darzustellen und nicht zu technisch zu gestalten, damit alle Stakeholder die Ergebnisse mit tragen können. Dabei ist es empfehlenswert auch die Nachteile und die nicht gewählten Lösungen zu erfassen.

ADR Story Deutsch
ADR Story Deutsch

Zusammenfassung von IT-Architektur als Teamwork

Zusammenfassend lässt sich sagen, dass “IT Architecture is Team Work” ein wichtiger Grundsatz ist, der betont, dass die Planung und Implementierung einer effektiven IT-Architektur die Zusammenarbeit verschiedener Teams erfordert. Es ist wichtig sicherzustellen, dass diese Teams eng zusammenarbeiten, klar kommunizieren und über die notwendigen Fähigkeiten und Kenntnisse verfügen, um eine sichere und effektive IT-Architektur zu planen und zu implementieren.

Literaturempfehlung

Wer sich mit den Quellen beschäftigen will, dem empfehle ich das Buch “Vorgehensmuster für Softwarearchitektur: Kombinierbare Praktiken in Zeiten von Agile und Lean” von Stefan Toth.

Hier der Link zu Amazon mit einer Leseprobe und auch einer Beispielzeichnung. Dabei handelt es sich um einen Affiliate (gesponsorten) Link. Diesen müsst ihr nicht nutzen, sondern kommt hier auch direkt zum Buch.

https://www.amazon.de/Vorgehensmuster-f%C3%BCr-Softwarearchitektur-Kombinierbare-Praktiken/dp/3446460047?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=X55A0E3AFT7J&keywords=stefan+toth&qid=1682235852&sprefix=stefan+toth%2Caps%2C84&sr=8-1&linkCode=li2&tag=bloggingbroth-21&linkId=6fc397f26cd182469721dcf923e7535a&language=de_DE&ref_=as_li_ss_il” target=”_blank”><img border=”0″ src=”//ws-eu.amazon-adsystem.com/widgets/q?_encoding=UTF8&ASIN=3446460047&Format=_SL160_&ID=AsinImage&MarketPlace=DE&ServiceVersion=20070822&WS=1&tag=bloggingbroth-21&language=de_DE” ></a><img src=”https://ir-de.amazon-adsystem.com/e/ir?t=bloggingbroth-21&language=de_DE&l=li2&o=3&a=3446460047
“Vorgehensmuster für Softwarearchitektur: Kombinierbare Praktiken in Zeiten von Agile und Lean” von Stefan Toth.

Für die Komponente Kommunikation möchte ich das Buch “The Software Architect Elevator” von Gregor Hohpe empfehlen. Hier der Link direkt zum Buch.

https://www.amazon.de/Software-Architect-Elevator-Redefining-Architects-ebook/dp/B086WQ9XL1?keywords=gregor+hohpe&qid=1682240476&s=digital-text&sprefix=gregor+ho%2Cdigital-text%2C80&sr=1-1&linkCode=li2&tag=bloggingbroth-21&linkId=f193de1cd8a9d64016d11704b9748e4f&language=de_DE&ref_=as_li_ss_il” target=”_blank”><img border=”0″ src=”//ws-eu.amazon-adsystem.com/widgets/q?_encoding=UTF8&ASIN=B086WQ9XL1&Format=_SL160_&ID=AsinImage&MarketPlace=DE&ServiceVersion=20070822&WS=1&tag=bloggingbroth-21&language=de_DE” ></a><img src=”https://ir-de.amazon-adsystem.com/e/ir?t=bloggingbroth-21&language=de_DE&l=li2&o=3&a=B086WQ9XL1

Kommentar hinterlassen