Wenn wir in unserer Kindheit beispielsweise Arzt oder Ermittler werden wollen, kennen wir die Besonderheiten des Berufs kaum. Ähnliche Situationen passieren bei Erwachsenen: Die Idee eines Traumjobs in der Realität hat wenig mit der Realität zu tun. Aber wie kann man sicher herausfinden, wo die Fallstricke versteckt sind? Eine Möglichkeit ist, ehrlich mit dem Praktizierenden zu sprechen! Wir haben
Andrei Trubitsyn , der mit EPAM als Solution Architect des Java Competency Center zusammenarbeitet, eingeladen, gängige Mythen über die Arbeit eines Architekten zu entlarven.
Mythos Nummer 1. Der Lösungsarchitekt kümmert sich bei seinem Projekt nicht um Managementaufgaben. Sein Geschäft ist Technologie!
Die Realität - insbesondere bei neuen Projekten oder Streams - sieht oft anders aus. Zu Beginn des Projekts, an dem ich gerade arbeite, musste ich in die USA, zum Büro des Kunden, um an der Entdeckungsphase und der Planungssitzung teilzunehmen. Danach kam ich in Kharkov an, wo zwei Teams zusammengestellt wurden, die noch nie zuvor zusammengearbeitet hatten. In dieser Situation
war die Kombination der Rolle eines Architekten und eines Geschäftsanalysten erforderlich: Ich schlug nicht nur technologische Lösungen vor, lehrte den Umgang mit Microservices und führte Codeüberprüfungen durch, sondern fand und diskutierte auch verschiedene Anwendungsfälle und funktionale Details mit dem Team. Zusammen mit einem Kollegen, Eugene Efremov, PM und Scrum-Master an diesem Projekt, haben wir den Prozess der Arbeit am SAF-Framework eingerichtet.
Aufgrund der Erfahrung und der direkten Bekanntschaft mit dem Kunden war es für mich außerdem einfacher, die bevorstehende Situation vorherzusagen, dem Team zu sagen, wie man am besten mit dem Kunden kommuniziert, wie man auf schwierige Situationen reagiert und welcher Detaillierungsgrad in den Beschreibungen ausreicht (Ingenieure sündigen diesen Missbrauch manchmal technologische Feinheiten. Tatsächlich beginnt die Tirade, dass "... das JSON-Format, das von einem Drittanbieter-Service stammt, nicht mit dem erwarteten Charakter beginnt, und aus diesem Grund tritt eine Art Fehler auf ...", z Person zu Wer sein ganzes Leben in einem anderen Bereich arbeitet, wird entlassen.
Außerdem müssen Sie das Team unterstützen. Bei meinem Projekt - aufgrund der Microservice-Architektur - sehr häufige Veröffentlichungen und ein dynamischer Arbeitsrhythmus. Wir sind immer in guter Form und viele Leute mögen es so sehr. Umso wichtiger ist es
, den Ingenieuren für ihre Initiative zu danken, die Arbeit zu unterstützen und das Vertrauen in die Unternehmen zu stärken . Wenn der Teamgeist und der Fokus auf Ergebnisse stark sind, fallen nach einigen Iterationen Menschen auf, die gute Ergebnisse zeigen. Ich denke, einige von ihnen werden in ein oder zwei Jahren Architekten werden können.
Abgesehen von Projekten, bei denen die Situation im Managementteam so kompliziert ist, dass
SA für den gesamten Prozess der Produktverteilung verantwortlich ist.Mythos Nummer 2. Ein Architekt weiß alles über Technologie
Das ist nicht wahr. Der Architekt weiß nicht alles. Aber er muss sich wirklich bemühen, mehr Technologien und ihre Funktionen zu erlernen als jede andere technische Person im Projekt. Und doch - SA muss nach vorne schauen und über die Aussichten nachdenken. Kein Wunder, dass Ingenieure Hochgeschwindigkeitszüge sind und Architekten den Weg ebnen, damit sie nicht in einem Sumpf stecken bleiben.
Im Allgemeinen muss sich der Architekt ständig selbst trainieren.
Meine Norm ist es, mindestens 10 Stunden pro Woche nicht projektbezogene Technologien zu studieren . Dabei helfen insbesondere professionelle Architektengemeinschaften im Unternehmen. Es werden ständig Diskussionen über verschiedene Fälle und Sitzungen zum Wissensaustausch geführt.
Mythos Nummer 3. SA Post macht Sie standardmäßig zu einem Experten
Wenn Sie für einen Kunden die Rolle eines Architekten übernehmen, ist das Vertrauen in Sie in der Regel etwas höher als Null (und dies nur, weil sie erwarten, einen lächelnden Mann in einem Hemd zu sehen :)).
Die Hauptaufgabe von SA - und anschließend von Teams - ist
es, dem Kunden zu beweisen, dass er uns vertrauen kann . Und wenn es sich zunächst so anfühlt, als würde der Kunde alle Schritte und Maßnahmen, die Sie ergreifen, sorgfältig prüfen, haben Sie im Laufe der Zeit die Möglichkeit, den Kunden zu beraten, was und wie zu tun ist. Es ist das angesammelte Maß an Vertrauen, das es meinem Projektkonto ermöglicht hat, auf 200 Personen zu wachsen (von denen 70 in Kharkov arbeiten). Und wir wachsen weiter!
In einigen Monaten plant unser Team, Kubernetes und Istio als Plattform für Microservices zu nutzen. Jetzt muss ich mich eingehender mit dem Thema befassen, alle verwandten Technologien studieren, damit ich während des direkten Übergangs
technische Unterstützung für die Teams leisten und ihnen schnell und effizient
Wissen übertragen kann . Dies ist viel effektiver, als gemeinsam von Grund auf in ein Thema einzutauchen.
Gleichzeitig hat der
Architekt das Recht, einen Fehler zu machen und muss ihn erkennen, korrigieren und weitermachen können. Die direkte Kommunikation mit Leitprojekten hilft, diese zu vermeiden. Es ist notwendig, Teambremsen zu arrangieren und die Lösung von allen Seiten zu prüfen, um mögliche Schwierigkeiten bei der Einführung bestimmter Technologien im Projekt zu finden.
Ohne ein Team kann ein Architekt ein Projekt nicht zum Erfolg führen.
Mythos Nummer 4. Das Projektteam hört immer auf den Architekten
Das Konzept des
„Architekten in einem Elfenbeinturm“ - das heißt einer SA, die irgendwo hoch sitzt, sich mit etwas Eigenem beschäftigt und die Ingenieure befinden sich derzeit in realer Verteilung - ist nicht von Grund auf neu entstanden.
Ein Architekt dieser Art hilft dem Projekt nicht, sein Team braucht seine Hilfe nicht.Damit SA nicht als eine andere Person wahrgenommen wird, die zum Kommando kam, ist es wichtig, kein Besserwisser zu sein, sondern zu beobachten, was Kollegen an dem Projekt tun und zu helfen. Um nicht nur mit Ratschlägen, sondern auch mit „Händen“ zu helfen: Schreiben Sie bei Bedarf Code, tauschen Sie Erfahrungen aus, finden Sie Details und Details heraus, um im Kontext der direkten Entwicklung maximiert zu werden.
Wenn die Teams allmählich erkennen, dass die Handlungen des Architekten von Vorteil sind, beginnen sie ihm wirklich zu vertrauen. Dann wird die Interaktion so reibungslos wie möglich und ermöglicht es im Laufe der Zeit, auf eine höhere Abstraktionsebene zu gelangen und Architekturaufgaben an technische Leiter zu delegieren.
Im Allgemeinen muss ein
Architekt nicht alle Entscheidungen allein treffen . Tatsächlich ist er bei einem großen Projekt nicht in absolut alle Aspekte der Anwendung einer bestimmten Technologie eingetaucht. Erst nach einer ausführlichen Diskussion mit Schlüsselpersonen des Projekts kann ein entscheidender Schritt getan werden.
Mythos Nummer 5. Ein Architekt hat keine langweilige Routinearbeit
Es besteht die Meinung, dass Architekten immer etwas Neues tun, an endlosen F & E-Aktivitäten beteiligt sind und mit modernsten Technologien arbeiten. Aber nein.
Der Hauptteil der Arbeit des Architekten besteht darin, die Entwurfs- und Architekturentscheidungen zu dokumentieren, die für das Projekt verwendet werden. Einige mögen dies langweilig finden. Architekten sind daher Menschen, die darin etwas Faszinierendes finden.
Zum Beispiel macht es mir viel Freude, Diagramme zu zeichnen und sie von kompliziert und komplex zu sehr schön, einfach, mit gleichmäßigen und klaren Verbindungen zu machen. Die größte Belohnung ist, wenn der Lead dieses Diagramm sieht und sagt, dass alles einfach und sehr deutlich darin dargestellt ist.
Von Zeit zu Zeit nimmt der Architekt an „langweiligen“ Gesprächen teil, bei denen es notwendig ist, dem Kunden einige Details der Implementierung zu vermitteln und zu zeigen, warum dies erforderlich ist und nicht anders. Dies kann zu langen Korrespondenzfäden führen, aber ich interessiere mich für diese Aktivität. Wenn ich verstehe, dass ich die optimale Wahl unserer Lösung nachweisen konnte und dies zu einem Gewinn für den Kunden führte, macht es mir Spaß.
Wie dem auch sei, der
Lösungsarchitekt ist ein interessanter Job . Sogar eine Berufung. Es ermöglicht Ihnen, in die Technologie einzutauchen und nicht gleichzeitig in die Isolation zu geraten. auf Geschäftsreisen gehen und mit Kunden kommunizieren; eine Gemeinschaft talentierter Ingenieure aufzubauen und ihre eigenen Kompetenzen zu fördern.
Fragen Sie einen Freund des Architekten, ob er seine Berufswahl bereut. Wetten, dass er nein sagt? ;)
Interview und Text vorbereitet von Ksenia Bai, Kommunikationsexpertin bei EPAM Ukraine.