Runder Tisch „Architekt des IT-Projekts“, September 2018

Am 5. September war Moskau Gastgeber des Runden Tisches „IT Project Architect“ an der HSE. Der Organisator des Runden Tisches, Maxim Smirnov, ist ein Blog über Architektur und den Facebook-Kanal .

Ich bin sehr froh, dass solche Veranstaltungen stattfinden. Ein cooler Architekt zu werden war und bleibt mein Traum. Ich habe sehr lange nicht verstanden, wie Architekten im Allgemeinen kommen, wie sie sich entwickeln und welche Richtungen sie wählen müssen, damit sie zur Architektur führen, und ich denke, solche Fragen stellen sich nicht nur für mich. Es ist großartig, dass es eine Community gibt, in der Sie Architektenfragen stellen können.

Am Runden Tisch wurden 4 Berichte von 15 bis 20 Minuten präsentiert, woraufhin Fragen des Publikums und der Diskussion gestellt wurden.

Die Berichte waren kurz und auf den Punkt gebracht, und die Diskussion war sehr lebhaft und umfangreich.



Weiter meine Notizen während der Berichte.

Bericht 1
Schlüsselkompetenzen eines Entscheidungsarchitekten in Projekten von Grund auf neu

Gennady Kruglov
Zertifizierter SOA-Architekt, ctn

Im Rahmen der Präsentation wurden die Hauptphasen des Architekturprozesses angesprochen:

1. Geschäftliches Engagement.
2. Ingenieure engagieren.
3. Prototyping.
4. Die Wahl des Architekturstils und des technologischen Stapels (Microservices, Monolith, SOA).
5. Entwicklung eines Architekturentwurfs.
6. Demonstration gegenüber dem Kunden.
7. Lösungsdesign.
8. Bogenlösungen dokumentieren.
9. Architektonische Aufsicht.

Höhepunkte der Leistung:

Es ist ratsam, einen Prototyp zu erstellen, um ihn dem Unternehmen zu zeigen. Wann immer möglich, müssen bei der Auswahl eines Architekturstils verschiedene Parteien einbezogen werden - Entwickler, Sicherheit, Betrieb. Beim Entwerfen einer Skizze müssen Sie verschiedene Abschnitte der Architektur erstellen - Geschäft, Technologie, Sicherheit.

Wenn möglich, ist es notwendig, Leute anzuziehen, die dann direkt mit diesem Teil des Systems arbeiten.

Nach Diskussion mit Interessenten wird ein Prototyp vorgeführt. Wenn das Projekt startet, wird eine detailliertere Untersuchung jeder Architekturebene durchgeführt.
Während der Entwicklung ist eine Synchronisierung mit dem Architekten erforderlich, um zu überprüfen, ob der Prozess dem ausgewählten Pfad folgt.

Die Fähigkeiten, die laut dem Sprecher vom Architekten benötigt werden:

• Kommunikationsfähigkeiten (Überzeugung, Verhandlung)
• Präsentationen
• Brainstorming und Workshops
• Kenntnis der Architekturstile
• Weite Horizonte moderner Technologie (es ist wichtig, die Stärken und Schwächen zu verstehen)
• Design- und Anwendungsfähigkeiten
• Entwicklungsfähigkeiten unter Verwendung verschiedener Frameworks, Produkte und Programmiersprachen
• Kenntnis der Entscheidungsdokumentationsrahmen
• Verständnis der verschiedenen Arten von SDLC (Systementwicklungslebenszyklus)
• Breites Netzwerk professioneller Verbindungen
• Fähigkeiten im Management von Entwicklungsteams

Bericht 2
Architekturunterstützung für IT-Projekte

Dmitry Romanov, ITSK

Entwerfen von IT-Lösungen, architektonische Unterstützung von Projekten, ca. 80 Projekte pro Jahr, ca. 50 Architekten sind in den Prozess involviert.

Der Service des Chef-IT-Architekten bestimmt die technische Politik im Bereich IT, die von IT-Projektarchitekten umgesetzt wurde. Bei der Beantwortung der Frage, wo der Architekt normalerweise das erforderliche Fachwissen sammelt, gab Dmitry die folgenden Quellen an:

1. Erfahrung - ähnliche Systeme schaffen
2. Kollegen - jemand innerhalb des Unternehmens oder in anderen Unternehmen
3. Anbieter - Konsultationen mit Entwicklern
4. Thematische Foren
5. Technopark - Zulassungen oder Sandbox auf Basis von Technopark

In Anbetracht der Notwendigkeit der Rolle eines Architekten in ITSK wies Dmitry darauf hin, dass der Architekt eines IT-Projekts benötigt wird, damit beispielsweise kein Projekt 1 Jahr lang abgeschlossen wurde, dann sechs Monate lang gearbeitet wurde und festgestellt wurde, dass es keine Skalierung gibt, und dann 2 Jahre lang erneuert wurde. Ein klares Verständnis ist wichtig, damit die vorgeschlagene Architektur implementiert werden kann. Abhängig von der Projektmanagementmethode tritt der Architekt in ITSK entweder in das Team ein (wenn es agil ist) oder in die Projektexpertengruppe.

Bericht 3
Architektur in den IT-Projekten des Unternehmens: Schwerpunkt

Ivan Lukyanov, Moskauer Ministerium für Informationstechnologien, Produkt „Staatliche Dienstleistungen und MFC“

Professionelle Biografie des Redners: Entwickler bei Diasoft, Leiter des Entwicklungsteams (BSC Praha), führender Berater (Neoflex), Leiter der Abteilung für Architektur und Strategie bei der Alfa Bank, Leiter der Abteilung für Architekturentwicklung (DIT).
Ivan empfiehlt, mit einer Beschreibung der vorhandenen Architektur (wie sie ist) zu beginnen, eine Zielarchitektur zu erstellen (zu sein) und den Unterschied zwischen den Punkten „wo sich die Organisation jetzt befindet“ und „wohin die Organisation gehen möchte“ zu analysieren, um die Schritte zu beschreiben, um das System in den Zielzustand zu bringen.
Der Schwerpunkt von IT-Projekten in der Architektur:

• Erklärung des zu lösenden Geschäftsproblems: Der Architekt muss sicherstellen, dass die Geschäftsaufgabe gut gestellt ist und in einer für die Gestaltung geeigneten Form beschrieben wird, die von den für das Geschäft Verantwortlichen vereinbart wurde
• Vision des Weges: Durch die Bemühungen der Architekten in der Organisation sollte die Zielarchitektur der Organisation für die spezifischen Anforderungen des Unternehmens entwickelt werden. Die Zielarchitektur sollte in konkrete Schritte (Projekte) unterteilt werden, um dies zu erreichen.
• Design: Alle Lösungen werden unter Berücksichtigung der entwickelten Zielarchitektur entworfen. Die Zielarchitektur wird schrittweise von Projekt zu Projekt implementiert. Der Architekt genehmigt die Entscheidung bezüglich der Architektur.
• Der Prozess der Projektimplementierung: Die Organisation sollte über einen Prozess verfügen, der die Analyse und Beschreibung von Geschäftsaufgaben, die Entwicklung der Zielarchitektur und den Entwurfsprozess umfasst (Entwicklung und Betrieb wurden im Bericht nicht behandelt). Der Prozess sollte von allen Beteiligten vereinbart und vom Management unterstützt werden.
• Methodische Unterstützung des Projektimplementierungsprozesses: Sehr oft ist es der Architekt, auf dessen Schultern die Entwicklung einer Methodik zur Implementierung von IT-Projekten in einer Organisation unter Berücksichtigung der Formulierung einer Geschäftsaufgabe und des Entwurfs liegt. Im Rahmen dieser Arbeit können Anpassungen am bestehenden Prozess der Implementierung von IT-Projekten in der Organisation (falls vorhanden) oder an der Erstellung eines neuen Prozesses von Grund auf (falls nicht vorhanden) vorgenommen werden. Das Ergebnis der methodischen Arbeit ist der beschriebene Prozess und die Belege, die in Form von Vorlagen formalisiert sind.

Das Unternehmen hat jetzt eine eigene Methodik entwickelt, einschließlich Vorlagen, die für die Arbeit von Dokumenten verwendet werden. Die Prinzipien von TOGAF und Gartner wurden verwendet.

Die architektonischen Prinzipien wurden genehmigt, das Dokument „Architektonische und technologische Lösung“ wurde entwickelt, das die Geschäftsanforderungen für Lösungen und das Projekt für deren Implementierung beschreibt.

Merkmale des Architekten:

• Geselligkeit. Die Kommunikation mit dem Management, mit den Darstellern, mit der Unterstützung, mit den Managern und Testern ist wichtig. Der Architekt muss die Rolle eines Übersetzers spielen - von der Geschäftssprache in die technische und umgekehrt übersetzen.
• Eine zwingende Voraussetzung ist die Erfahrung des Entwicklers (na ja, wenn auch Analytik).
• Respekt für Kollegen.
• Kontinuierliche Weiterentwicklung.

Architektur ist kein bewegungsloses Denkmal aus Granit, sondern eine lebendige, sich entwickelnde Sicht auf das, was wir in Bezug auf geschäftliche Unterstützung erreichen wollen.

Bericht 4
IT-Projektarchitekt: einer der möglichen Gesichtspunkte

Evgeny Aslamov Aslamov, Leitender Architekt, Lanit Unternehmensgruppe.

Eugenes Weg zur Rolle des Architekten: Entwickler, Analyst, Projektmanager. Während der Kurzgeschichte sprach der Autor verschiedene Fragen im Zusammenhang mit der Rolle des Architekten bei der kundenspezifischen Entwicklung an: Was ihn umgibt, was er tut und wie er es tut.

Nach Meinung von Eugene, der über den Architekten in der kundenspezifischen Entwicklung spricht, sind wir von verschiedenen Faktoren abhängig - dem Timing, dem Budget, dem Team, der Komplexität und dem Umfang der Aufgaben. In komplexen Projekten (mehrere tausend Benutzerszenarien, Integration in ein paar Dutzend Systeme, großes Datenvolumen, hohe Anforderungen an Hochverfügbarkeit und Notfallwiederherstellung) werden Architekturaufgaben in der Regel von einem Architektenteam abgeschlossen. Bei bescheideneren Projekten kann eine Person diese Aufgaben bewältigen, und der Architekt widmet sich nicht immer den Aufgaben - seine Rolle kann mit anderen Rollen kombiniert werden - dem leitenden Entwickler oder Analysten.

Ein Architekt arbeitet wie jedes Teammitglied in einem bestimmten Kontext. Ein Überblick über einen solchen Kontext:

Kunde

• das höchste (auf jeden Fall hoch genug für Schlüsselentscheidungen) Management des für das Projekt verantwortlichen Kunden;
• Kundenkomitees (Architektur, Design, Betrieb usw. - es passiert viel);
• Service oder Abteilung von Informationssicherheitsspezialisten;
• Mitarbeiter des Kunden, die ein System benötigen, das das Projekt „verbrennt“;
• Realitäten - eine eher banale Routine, menschlicher Faktor, Verfahrensprobleme, kleinere Meinungsverschiedenheiten usw.;

Das Team

• Manager
• Analysten
• Entwicklung;
• DevOps
• Qualitätsservice;

Der Vertrag

• Fristen;
• Budget
• rechtliche Zitate;
• neue Technologien, Ansätze, Chips, die ich wirklich anwenden möchte;
• Traditionen: Es funktioniert und es ist gut, bei uns ist alles in Ordnung - was zu ändern und dergleichen.

Als Teil des Kontexts führt ein Architekt oder eine Gruppe von Architekten Folgendes aus:

• Es bildet die Grenzen für das Team, in dem sich das Projekt entwickeln und leben wird. Zunächst geht es um Grenzen, die sich aus nicht funktionalen Anforderungen ergeben.
• Formuliert, unterstützt und aktualisiert Architekturlösungen unter Berücksichtigung der Ansichten der wichtigsten Stakeholder.
• Arbeitet als Dolmetscher - übersetzt vom Technischen ins Russische und umgekehrt. Tatsächlich sowohl für den Kunden als auch für das Team. Der Architekt muss alle Aspekte des Projekts verstehen (zusammen mit führenden Analysten und dem Projektmanager) und in der Lage sein, ihre Beziehung zu den technischen Teilen zu erklären.
• Stellt viele unangenehme Fragen. Es ist einfach so, dass einige Entscheidungen ohne die Teilnahme des einen oder anderen Teammitglieds getroffen wurden. Es ist in Ordnung. Wenn etwas getan wurde und die Architektur des Systems beeinflusst oder beeinflussen kann, müssen Sie die Gründe herausfinden, um herauszufinden, ob Sie etwas jetzt ändern müssen, einige Maßnahmen für die Zukunft vorsehen oder es einfach aufzeichnen und bis zu besseren Zeiten belassen.

Eugene beantwortete die Frage „Wie macht er das?“ Und ging zunächst auf das Problem der Entwicklung architektonischer Lösungen ein. Es wurden mehrere Komponenten identifiziert, die bei dieser Aufgabe helfen:

• Erfahrung und Analogien. Dies ist eines der wichtigsten Vermögenswerte des Architekten. Und es muss ständig erweitert werden - um nicht in einem Projekt, einer Technologie usw. zu stagnieren.
• Horizonte. Sie können Ihre eigene Erfahrung nicht nutzen - die Erfahrung von Kollegen, die Erfahrung von Communities, Standards.
• Prototypen. Bei Verwendung eines neuen, nicht getesteten oder mit sichtbaren Risiken ist ein Prototyping erforderlich. Gleichzeitig ist es wichtig, die Fragen, die der Prototyp beantworten muss, richtig und genau zu formulieren, da dies sonst die Situation nur verschlechtern kann.
• Schützen Sie Ihre Entscheidungen. Vor dem Projektteam, vor dem Architekturkomitee (Ihres oder des Kunden), vor Ihnen. Als eine der Lösungen kann die Einführung (vollständige oder einzelne Elemente) der ATAM - Architecture Tradeoff Analysis Method dienen . In einigen unserer Projekte wird beispielsweise der Entscheidungsschutz als Präsentation wichtiger Entscheidungen für Kollegen außerhalb des Projekts implementiert, um alternative Meinungen und Kommentare zu erhalten.

Anstelle einer Schlussfolgerung: Eine der informellen Aufgaben eines Architekten und eines jeden Spezialisten, der seine Arbeit liebt, besteht darin, Wissen, Technologien, Ansätze und Fähigkeiten bekannt zu machen, die es dem Team ermöglichen, Probleme in einem Projekt effizienter und bequemer zu lösen.

Eugenes Artikel über habr „ Wir bereiten ein Projekt bei Sparx Enterprise Architect vor. Unser Rezept . "

Fragen und Antworten

Als nächstes folgte ein Abschnitt mit Fragen und Antworten. Die am meisten in Erinnerung gebliebenen können unten gelesen werden.

Woher kommen Architekten?

Gennady:
Softwarearchitekten - ehemalige Teamleiter oder diese Leiter oder leitenden Entwickler.
Dmitry:
Architekten werden von Entwicklern von Beratern mit breitem Fachwissen übernommen.
Der Entwickler kann Präsentationen sprechen und zeichnen - Lösungsarchitekt.
Eugene:
Im Allgemeinen von jedem Teil - von Entwicklung, Test, Projektmanagement usw. In jedem Fall helfen jedoch einige technische Spezialisierungen - sie müssen nicht von Grund auf neu entwickelt werden.
Ein Beispiel aus persönlicher Erfahrung: Ein Student der Mechanikabteilung der Moskauer Staatlichen Universität, eine intelligente, gesellige Person ohne Sternenkrankheit, wurde zur Firma Lanit gebracht. Er arbeitete ein wenig in den Bereichen Analytik, Entwicklung und Kommunikation mit dem Kunden. Infolgedessen wurde er ein angewandter Architekt in unserem Unternehmen.
Ivan:
Von den Entwicklern. Wenn es einen guten Entwickler gibt, kann er sich weiter mit Programmiersprachen beschäftigen und sich tiefer entwickeln. Aber wenn er einmal neugierig war, wie die technische Aufgabe entstanden ist, wer analysiert, wer die Entscheidung trifft, ob dies getan werden soll oder nicht, dann ist dies ein Signal dafür, dass der Spezialist den Weg eines unerfahrenen Architekten eingeschlagen hat. Die nächste Stufe der Neugier ist, wie eine Lösung als Ganzes auf Unternehmensebene geboren wird. Wie können Sie dem Leiter der Organisation zeigen, dass er es braucht und was nicht? Gregor Hohpe beschreibt die Rolle des Architekten anhand der Aufzugsmetapher . Jede Etage, in der der Aufzug anhält, ist eine bestimmte Ebene in der Organisation: die erste Etage - der Maschinenraum - das sind Entwickler, Produktion; oberste Etage - Organisationsmanagement. Der Architekt erweckt die Architektur zum Leben und kommuniziert auf jeder Etage (von der ersten bis zur letzten). Auf jeder Etage muss er sich mit verschiedenen Schwierigkeiten auseinandersetzen - technologischer, politischer und kommunikativer.

Der Architekt kann die notwendigen Informationen sammeln und auf jede Ebene übertragen. Tatsächlich fungiert er als Vermittler zwischen den beteiligten Parteien.

Wie sollte die Autorität zwischen dem Projektmanager und dem Architekten geteilt werden?

Es muss ein Gleichgewicht zwischen Autorität bestehen. Die Autorität des Architekten liegt im technischen Teil und der Projektmanager im organisatorischen Teil.

Für den Fall, dass das Gleichgewicht in Richtung RP verschoben wird, können Sie das Projekt pünktlich erhalten, aber nicht funktionieren oder nicht skalierbar sein. Und wenn Sie dem Architekten gegenüber sind, können Sie ein wunderbares Projekt bekommen, wenn niemand es braucht. So beantworten Sie die Fragen "Wen liebst du mehr - Mama oder Papa?"

Wie kann man Unternehmensarchitekten sein, die einen großen Fluss unterschiedlicher Projekte haben?

Ivan:
In großen Organisationen erstellen mehr als 2.000 Personen eine Unternehmensarchitektur, und es ist fast unmöglich, dieser zu folgen. In DIT wird eine Unterteilung in Produkte (Dienstleistungen) vorgenommen, jedes Produkt hat seinen eigenen Technologie-Stack, seine eigene Architektur. Die Unternehmensarchitektur wird von den Aktionären mehr benötigt, damit sie verstehen, wohin sich die Organisation in Bezug auf die Architekturentwicklung bewegt. Zu diesem Zweck wird die Rolle des Chief IT Architect häufig in Organisationen hervorgehoben, deren Hauptaufgabe darin besteht, die Gesamtlandschaft der Unternehmensarchitektur zu bestimmen.

Wie ist die Interaktion zwischen dem Projektarchitekten und dem Unternehmensarchitekten aufgebaut?

Kommunikation ist wichtig. Sie müssen Kommunikation aufbauen und einfach kommunizieren. Ein Projektarchitekt benötigt möglicherweise keine Kenntnisse der Unternehmensarchitektur, aber es ist wichtig zu wissen, mit wem die Integration erfolgt und welche Auswirkungen dies haben wird. Es ist wichtig, Architekturkomitees zu bilden, es ist möglich, dort nicht nur Unternehmensarchitekten, sondern auch Designarchitekten zu kennen.

Sie können es in Bezug auf den Wert betrachten - wer bringt mehr Wert. Wenn die Lösungen funktionieren, gibt es einen Wert. Unternehmensarchitektur an sich bringt keinen Wert, aber sie bringt Wert durch eine Lösung von Architekten, die bereits bestimmte Aufgaben implementieren.

Niemand braucht Generalisten - immer weniger sind Menschen, die nichts über alles wissen. Es ist besser, bestimmte Fragen beantworten zu können, zum Beispiel, ob RabbitMQ hier ausreicht oder ob Kafka benötigt wird.

Wie sind Unternehmensarchitektur-Repositorys organisiert?

Gibt es komplexe Modelle, die berechnet, verifiziert usw. werden können?

Eugene: Wir haben ein Architektur-Repository, aber es gibt keine Automatisierung für die Berechnung von Metriken. Die Beziehungen zwischen den Modellen und den Modellen selbst ermöglichen es uns, Architektur als etwas Integrales und nicht als eine Reihe von Bildern zu betrachten. Eine der Aufgaben des Repositorys ist die Bereitstellung einer Auswirkungsanalyse. Auf dieser Basis können Sie den Wert der Änderungen schätzen.

Nachwort

Es ist großartig, dass Sie kommen und den Architekten zuhören und die Community kennenlernen können. Solche Treffen sind für mich immer eine Gelegenheit zu verstehen, wo ich graben muss, um das notwendige Wissen zu finden. Darüber hinaus können Sie Arbeitsfälle besprechen und eine Empfehlung erhalten.

Vielen Dank an Maxim Smirnov und HSE für die Organisation eines runden Architektentisches!
Vielen Dank auch an die Autoren der Berichte (Eugene Aslamov, Gennady Kruglov, Ivan Lukyanov) für die Erstellung dieses Textes , da die Originalnotizen während der Berichte verfasst wurden und Fehler und Ungenauigkeiten enthielten, die korrigiert wurden.

Auf dem Foto, Chambord Castle in Frankreich , heißt es, jeder Besitzer habe auf seinem Turm gebaut. Manchmal sieht die Architektur eines Projekts so aus. Meiner Meinung nach wird ein Architekt benötigt, damit alles schön und so einfach wie möglich ist, damit Sie auch mit einer Reihe von Türmen in verschiedenen Stilen ein schönes Schloss erhalten.