Mir wurde kürzlich die Rolle des technischen Architekten in meiner Organisation übertragen (ich werde auch einige Projekte projektverwalten und entwickeln, wenn die 10-12 leitenden Entwickler allzu beschäftigt sind).
Ich frage mich, ob ein technischer Architekt am Anfang eine starke Rolle bei der Definition der Projektarchitektur und der richtigen Entwickler für das Projekt haben sollte – aber dann während des eigentlichen Projekts in den Hintergrund tritt. Ist das vernünftig?
Wenn Sie an mehreren Projekten arbeiten, müssen Sie meiner Meinung nach sicherstellen, dass Ihr Fokus auf dem projektübergreifenden Bild liegt und nicht zu sehr auf einem Projekt. Wenn Sie der Hauptentscheidungsträger/architektonische Eigentümer für den Kern jedes Projekts werden, werden Sie schließlich zu einem Engpass, da Sie vom Team mit Fragen zu Ihrer Entscheidung überschwemmt werden.
Ich bin ein starker Befürworter, dass die Leute, die die letzte Entscheidung über die Architektur treffen, die Leute sein sollten, die mit der Implementierung und der Fehlerbeseitigung des Endprodukts stecken bleiben.
Angesichts der Tatsache, dass Sie projektübergreifend arbeiten, würde ich denken, dass Ihre Verantwortlichkeiten wie folgt sein sollten:
Wenn es nicht für jedes Projekt eine Person gibt, die die Hauptverantwortung für dieses Projekt trägt, dann haben Sie ein Problem. In dem Moment, in dem Sie der primäre Eigentümer eines bestimmten Projekts sind, müssen Sie die Entscheidung treffen, ob Sie sich auf dieses Projekt konzentrieren oder sich auf alle Projekte konzentrieren möchten.
Technischer Architekt ist eine spezifische Rolle, da die Erwartungen an die Person, die sie erfüllt, je nach Organisation und sogar bei derselben Organisation je nach Projekt sehr unterschiedlich sind.
Kurz gesagt, der technische Architekt sollte die volle Verantwortung für die Softwarearchitektur übernehmen. Es bedeutet nicht nur, es so zu gestalten, dass alle nicht-funktionalen Anforderungen, zB Skalierung, Performance, erfüllt werden, sondern es Entwicklern auch einigermaßen einfach zu machen, Software zu bauen. Sie erhalten keine Punkte für ausgefallene erstklassige Architektur, wenn das Entwicklungsteam Schwierigkeiten hat, die Anwendung zu erstellen und zu warten.
Wenn ich an Verantwortung denke, betrachte ich sie während des gesamten Projekts. Die Arbeit des Architekten ist nicht getan, wenn die Entwicklung beginnt, da sich die Architektur im Laufe der Zeit entwickeln kann und normalerweise auch entwickeln sollte.
Auch in vielen agilen Projekten finden Sie möglicherweise eine Architektur, die inkrementell aufgebaut wird – Sie legen nur allgemeine Grenzen im Voraus fest und fügen sie dann hinzu und ändern sie, wenn Sie neue Funktionen hinzufügen. Auch hier gilt: Wenn Sie planen, sich an sich ändernde Anforderungen in Bezug auf Funktionen anzupassen, sollten Sie dasselbe für die Architektur planen, damit die Arbeit nicht zu Beginn des Projekts erledigt ist.
Ich würde auch sagen, dass es der technische Architekt ist, der sich um technische Schulden im Projekt kümmern sollte . Ob es anfällt und wann, wenn überhaupt, es zurückgezahlt wird. Natürlich, solange sich überhaupt jemand für so etwas interessiert.
Normalerweise ist es nicht die direkte Verantwortung des Architekten, aber ich würde die Verantwortung für die Projektwartung hinzufügen, da wir oft sehen, dass Projekte sogar pünktlich fertig werden, aber dann die Wartungskosten in die Höhe schnellen und manchmal der Hauptgrund entweder ein schlechtes Architekturdesign oder eine schlechte Ausführung ist, dh keine Gewährleistung dass das Entwicklungsteam die Richtlinien befolgt.
Das Unbestimmte hier ist nun, wie wir Architektur verstehen . Es kann alles sein, von einigen allgemeinen Richtlinien auf hoher Ebene bis hin zu detaillierten Regeln, was getan und was nicht getan werden sollte, welche Tools, Bibliotheken, Entwurfsmuster, Codierungsstandards usw. verwendet werden und welche nicht. Unabhängig davon, wie Architektur in der Organisation oder im Projekt definiert ist, sollten alle architekturbezogenen Fragen an den technischen Architekten gerichtet werden.
Für mich ist es ein großes Warnsignal, dass Sie gebeten werden, der technische Architekt der Organisation zu sein (verantwortlich für die Architektur von X-Projekten), das Projektmanagement von Y-Projekten und Entwickler von Z-Projekten. Ich weiß nicht, wie Sie es schaffen werden, in allen 3 Rollen erfolgreich zu sein, in X+Y+Z Anzahl von Projekten.
Ich habe versucht, sowohl Entwicklung als auch Projektmanagement gleichzeitig zu machen, und normalerweise ging es darum, abwechselnd eine Rolle gegenüber der anderen zu vernachlässigen.
Die Tatsache, dass Sie gebeten werden, all diese Dinge zu tun, sagt mir, dass die Organisation Ihre Fähigkeiten und Ihr Wissen sehr schätzt, also ist das eine gute Sache! Aber nehmen Sie sich einfach nicht mehr vor, als Sie erfolgreich bewältigen können.
In RUP ist Software Architect für das Software Architecture Document (SAD) verantwortlich, das eine Brücke zwischen der Software Requirements Specification (SRS) und dem Software Design Document (SDD) bildet.
In der Praxis bedeutet dies, dass ein Architekt für den Informationstransfer zwischen Problemdomäne und Lösungsdomäne über den gesamten Projektlebenszyklus hinweg verantwortlich sein muss.
Als Technical Architect (TA) gehören folgende Aufgaben und Verantwortlichkeiten zu Ihren Aufgaben und Verantwortlichkeiten: Halten einer Design-, Build- und Test-Sichtweise zusammen mit der Bereitstellung von High-Level-Design-, Low-Level-Design- und testgetriebenen entwicklungsbezogenen Dokumentenaktualisierungen nach den geschäftlichen Anforderungen. Übernehmen Sie wichtige Rollen bei der Entscheidungsfindung.
Natürlich sollten alle oben genannten Maßnahmen das Team und das Projekt zu einem erfolgreichen Ende führen, wobei zu berücksichtigen ist, dass für den Kunden die erfolgreiche Durchführung des Projekts das Wichtigste ist. Daher ist es für den Architekten entscheidend, den Release-Plan zu kennen.
Auf der technischen Seite ist es neben dem richtigen Design auch wichtig, sich um betriebliche und infrastrukturelle Aspekte zu kümmern; Ohne konsistent konfigurierte Umgebungen, ein Code-Repository, ein Fehlerverfolgungssystem, einen auf das Projekt zugeschnittenen kontinuierlichen Integrations- und Bereitstellungsfluss kann die Projektabwicklung gefährdet sein. Offensichtlich muss der TA, wie in früheren Fällen, die mit der Umsetzung dieser Aspekte verbundene Arbeit nicht mit seinen eigenen Händen erledigen; Vielmehr arbeitet er mit dem Projektmanager und dem Freigabemanager zusammen, um sicherzustellen, dass alles in Ordnung ist, und um die Anforderungen des Teams zu erfüllen.
Technische Architekten, die in Entwicklungsprojekten arbeiten, sind letztendlich für die technische Lösung verantwortlich und stellen sicher, dass die technische Architektur im Kontext des Technologie-Stacks des Kunden geeignet ist und auf die Fähigkeiten und das Profil des Entwicklungsteams abgestimmt ist. Der Architekt muss sicherstellen, dass die Entwicklungsinfrastruktur den Anforderungen des Teams entspricht. Das ist die Verantwortung des TA: für die technische Qualität, für eine erfolgreiche Lieferung und für eine gute Beziehung zum Kunden.
In den meisten multinationalen Unternehmen haben wir einen Trend erlebt , der die Rolle des Softwarearchitekten Projektmanagern zuweist , die eine gute Anstellung ( 5 Jahre ) bei einem Unternehmen hinter sich haben . Dies geschah in diesem Fall, als der technische Architekt das Unternehmen wechselte und seinem Berichtsmanager, der seine Architektenrolle übernehmen wird, parallel zur Einstellung eines neuen Architekten die entsprechende KT zur Verfügung stellte. Dies geht an die Überzeugungsarbeit der Unternehmensleitung.
amelvin