Get best of the week

Checkliste für einen Architekten

In diesem Artikel erfahren Sie, wie Sie den Prozess des Aufbaus einer effektiven Entwicklung in einem verteilten digitalen Unternehmen organisieren, wie Sie dies durch Expertenkommunikation tun und wie dies am Beispiel von MTS geschieht.

MTS hat wie viele andere moderne Unternehmen die sogenannte digitale Transformation durchlaufen. In einfachen Worten, die Einführung digitaler Prozesse und Produkte ist zu unserer Priorität geworden.

Für mich als Technikfreak bedeutet dies, dass die Ausrichtung des Geschäfts im Unternehmen vollständig von der Qualität der IT-Systeme und ihrer Fähigkeit abhängt, sich schnell zu entwickeln.

Natürlich ist dies eine falsche Definition, und Vermarkter können mit mir streiten - und sogar streiten! Aber für alles, was Sie unten lesen, ist es völlig ausreichend.



Weniger Bürokratie - einfachere Entwicklung


Was sich geändert hat: Zunächst das Modell der Unternehmensführung. Wenn früher die Mitarbeiter der zentralisierten Unternehmensarchitektur (Unternehmensarchitektur) jedes Projekt überprüft haben, veröffentlichen sie jetzt eine technische Richtlinie (ein großes und cleveres Dokument) und schulen Architekten darin. Und wie man es anwendet, ist bereits eine persönliche Angelegenheit jedes Produktarchitekten aus mehr als hundert Teams.
 
Einerseits ist dies eine gute Bürokratie, die die Entwicklung erheblich vereinfacht. Auf der anderen Seite interagieren alle Produkte auf die eine oder andere Weise miteinander, und ein Fehler in einem von ihnen kann sich auf den anderen auswirken.

Zum Beispiel schreiben Eoin Woods und Nick Rozanski in Software Systems Architecture: Arbeiten mit Stakeholdern unter Verwendung von Gesichtspunkten und Perspektiven über das grundlegende Sicherheitsprinzip, um das schwächste Glied zu sichern. Wenn Ihre IT-Landschaft über mindestens ein schwach geschütztes IT-System verfügt, ist die gesamte IT-Landschaft gefährdet. Nur weil ein hypothetischer Angreifer für dieses System ungestraft arbeiten kann.

Es gibt viele weitere Beispiele, bei denen es nützlich ist, Qualität und Konsistenz beim Entwurf und der Entwicklung von IT-Systemen zu gewährleisten.

Introvertierte Experten


Was wir uns ausgedacht haben: Eine Community schaffen, um Wissen auszutauschen und Best Practices zu verbreiten. Die Idee ist nicht neu und nicht sehr revolutionär, erfüllt aber die Anforderungen und Besonderheiten der Entwicklung digitaler Produkte.

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • Organisation der Rotation in einem Team von „Auditoren“, damit möglichst viele Teamvertreter die Möglichkeit haben, Wissen und Erfahrung auszutauschen.

Zu Beginn des Prozesses haben wir ein Team von Enthusiasten zusammengestellt, eine Liste mit Diskussionsthemen für jede der Rollen erstellt und das Team unserer spontanen Auditoren geschult. Das Training war übrigens die schwierigste Phase, denn oft sind auch sehr gute Spezialisten auf unserem Gebiet auch sehr gute Introvertierte :-)

Was ist das Ergebnis?




  • Die Recherche der Produktteams verlief eher gemächlich. Im Durchschnitt dauert es ungefähr 31 Tage für ein Team. Während dieser Zeit schaffen wir es, mit Vertretern aller Bereiche der Teamaktivitäten zu kommunizieren, einen Memo-Bericht zu erstellen und ihn dem Product Owner zu erklären, damit er ihn für Maßnahmen planen kann.
  • Das Ergebnis der Arbeit hängt stark vom Experten ab. Daher ist es wichtig, dass es für jede Rolle mehrere gibt: zwei Analysten, zwei Architekten usw.; wo einer bereits eine Reihe von Interviews durchgeführt hat und der andere nur an der Kommunikation beteiligt ist;
  • Es ist auch notwendig, die Methodik der Befragung ständig anzupassen, da einige Themen ihre Relevanz verlieren und an ihrer Stelle Fragen stehen, an die noch niemand gedacht hat.

Schauen wir uns zum Beispiel die Ergebnisse einer Studie in Richtung "Architektur" an.
 
Was haben wir getan:

  • Kommunikation mit 20 Teams;
  • Jeder verbrachte durchschnittlich 31 Tage. Angesichts der Tatsache, dass wir gleichzeitig mit mehreren Teams interagierten, dauerte der gesamte Prozess sechs Monate.
  • Enthüllte 180 mit der Architektur verbundene Risiken.

 Innerhalb unserer Teams wurden die Risiken wie folgt aufgeteilt:


Risiko 1: Design

Es ist wichtig zu verstehen, dass alle von uns untersuchten Softwaresysteme eine ziemlich strenge Kontrolle der Ausgabequalität durchlaufen (z. B. haben Telekommunikationssysteme einen längeren Überwachungszeitraum als der Entwicklungszeitraum), aber es gibt keine Grenzen für Perfektion und Effizienz .

Um zu verstehen, was wir als Risiken betrachten, schauen wir uns die TOP-3 anhand von Beispielen an.

Für junge Produktteams ist die Situation ganz normal, wenn die Softwarearchitektur auf einer Restbasis entwickelt wird. Auf den ersten Blick scheint alles einfach zu sein, und der Zeitpunkt von Projekten bietet selten die Gelegenheit, ernsthaft über die Organisation der Architektur nachzudenken. Und dann kommt die Bottom-up-Entwurfsmethode ins Spiel - wenn wir die einzelnen Komponenten der Lösung entwickeln und sie dann zu einem Ganzen zusammenfügen.

Zum Beispiel haben wir beschlossen, ein digitales Produkt für die Telemedizin herzustellen. Was wird dafür benötigt?

  • Wir brauchen wahrscheinlich eine Komponente für Videoanrufe zwischen dem Patienten und dem Arzt - wir machen eine Komponente für Anrufe;
  • Manchmal benötigen Sie einen regelmäßigen Chat - das heißt, wir erstellen eine Komponente für den Chat.
  • Wir müssen die Krankengeschichte aus automatisierten medizinischen Systemen entnehmen - wir erstellen die entsprechende Komponente;
  • Wir müssen einen Zeitplan für die diensthabenden Ärzte einhalten - auch dafür stellen wir eine Komponente her.

Usw.

Alles scheint einfach zu sein, bis wir anfangen, alles zusammenzusetzen. Und hier gibt es Probleme mit der Verdoppelung von Funktionen - zum Beispiel sind Chat- und Videoanrufe sehr enge Anwendungen für sich (zumindest im Hinblick auf den Kontext der Arzt-Patienten-Interaktion). Jene. Das Risiko besteht darin, dass wir unsere Anwendung aufgrund der großen Menge an doppeltem Code erheblich wiederholen müssen.

Oder Probleme mit dem Datenmodell. Jede Komponente bietet standardmäßig Schnittstellen in diesem Modell, die zum Speichern und Verarbeiten dieser bestimmten Komponente und nicht der gesamten Anwendung geeignet sind.
 
Daher lohnt es sich, sich an einige einfache Regeln zu erinnern:

  • Die Bottom-up-Entwurfsmethode eignet sich für kleine Projekte mit geringer technischer Komplexität, kleinen Teams und volatilen Anforderungen.
  • Bei großen Projekten und Teams erfolgt die Entwurfsmethode von oben nach unten, dh wenn wir zuerst das Bild als Ganzes entwerfen und dann mit der Codierung fortfahren.

Bevor Sie sich kopfüber in ein neues Projekt stürzen, stellen Sie sich daher die Frage: Zu welchem ​​Typ gehört es?
 

Risiko 2: Sicherheit

Es scheint, dass Sicherheit heutzutage sehr ernst genommen wird. Jeder erinnert sich an solche Banalitäten als Notwendigkeit:

  • Benutzer authentifizieren
  • ermächtigen sie, Handlungen durchzuführen;
  • den Grundsatz der geringsten Privilegien einhalten;
  • Wahrung der Vertraulichkeit von Daten;
  • Führen Sie ein Protokoll über die Prüfung von Benutzeraktionen.

Aber hier ist eine Überraschung! Für Teams, die Services für die interne Automatisierung bereitstellen, ist dies nicht so offensichtlich wie für alle anderen. Wenn die Anwendung bereits im internen Unternehmensnetzwerk ausgeführt wird, warum sollte sie dann noch geschützt werden? In der Tat ist es notwendig, insbesondere wenn die Daten, mit denen die Anwendung arbeitet, als persönlich eingestuft werden. Ja, die Wahrscheinlichkeit, dass ein Eindringling in das interne Netzwerk eindringt, ist sehr gering, aber es gibt nicht viel Schutz.
 
Und bei externen Anwendungen können auch Nuancen auftreten. Stellen Sie sich eine einfache, rein hypothetische Beispiel-Webanwendung vor, die einen Benutzer mit einem Kennwort authentifiziert. Welche Probleme kann es geben:

  • Mit der Anwendung können Sie möglicherweise zu einfache Kennwörter eingeben, die dann leicht abgerufen werden können.
  • Die Anwendung ist möglicherweise nicht selbst vor Brute-Force-Passwörtern geschützt (es gibt kein Captcha oder ähnliches).
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

  1. - session tokens , ;
  2. - session fixation- (. . session token );
  3. - HttpOnly Secure browser cookies, session tokens;
  4. - .


Daher besteht hier das Risiko, dass jemand Zugriff auf Daten erhält, die nicht für ihn bestimmt sind. Dies kann zu Problemen in der Anwendung führen. 
Dies sind nur Beispiele dafür, worüber Sie im Sicherheitsbereich sprechen können. Die ideale Option wäre natürlich die Implementierung des Secure Development Life Cycle-Prozesses, wie er beispielsweise von Microsoft empfohlen wird .


Risiko 3: Leistung
 
Eine der Herausforderungen bei der schnellen Erstellung von Produktteams besteht aus drei Buchstaben. Dies ist ein MVP oder ein minimal wertvolles Produkt. Solche Teams bemühen sich, so schnell wie möglich eine Anwendung zu erstellen, die Einnahmen für das Unternehmen generiert. Da zu Beginn der Anwendung nur sehr wenige Benutzer vorhanden sind, denken sie normalerweise im letzten Moment über Leistungsparameter nach. Wenn die erstellte Anwendung jedoch plötzlich populär wird, müssen Sie überlegen, was als Nächstes zu tun ist.

Die Empfehlungen hier sind einfach: Die Anwendungsleistung ist umgekehrt proportional zur Anzahl der Anforderungen für langsame Ressourcen. Dementsprechend zielen alle Taktiken entweder darauf ab, die Anzahl der Anforderungen zu verringern oder die Ressourcen selbst zu beschleunigen. In diesem Fall werden Ressourcen als Prozessor, Speicher, Netzwerk, Festplatten verstanden. Manchmal ist es auch praktisch, eine Datenbank oder einen Anwendungsserver als Ressource zu betrachten.
 
  • Zunächst prüfen wir, ob es möglich ist, einen Client-Cache in einer verteilten Anwendung zu erstellen, damit wir nicht jedes Mal die benötigten Daten anfordern / berechnen. Wenn dies möglich ist, sparen wir Netzwerkanforderungen, laden Serverressourcen und alles, was er dort tut.
  • Aber es ist sehr selten ein Glücksfall, also schauen wir, ob wir einen Server-Cache erstellen können. Damit ist das Prinzip dasselbe wie beim Client, aber der Leistungsgewinn ist etwas geringer, da Netzwerkanforderungen weiterhin bestehen bleiben.
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

Nun, natürlich müssen wir uns daran erinnern, dass der Cache selbst das Problem des Zugriffs auf Daten löst, aber ein neues Problem mit dem Algorithmus für seine Ungültigmachung und Vorladung erzeugt. In einigen Systemen kann das Caching völlig nutzlos sein. In CRM-Systemen (Customer Relationship Management) ist es beispielsweise sehr selten möglich, Kundendaten effektiv zwischenzuspeichern. Ein Spezialist, der im Büro arbeitet, wechselt sehr schnell von einem Client zum anderen, und der Cache wird einfach nicht verwendet.

Daher besteht hier das Risiko, dass wir, ohne zuerst über die Strategie nachzudenken, wie wir unsere Anwendung „übertakten“, in Zukunft möglicherweise sehr hohe Kosten für das Umschreiben der Anwendung haben.

Zusammenfassen


In diesem Artikel habe ich versucht zu sprechen, wie Sie den Prozess des Aufbaus einer effektiven Entwicklung in einem verteilten digitalen Unternehmen durch Expertenkommunikation organisieren können. In unserer Zeit der Fernentwicklung werden solche Prozesse besonders relevant. Sie ermöglichen es Ihnen, das Gesetz von Conway zu zerstören oder zumindest zu minimieren.
 
Wenn Sie sich dazu entschließen, Ihre eigenen Checklisten zu erstellen, würde ich empfehlen, nicht alles von Grund auf neu zu machen, sondern etwas aus der vorhandenen Literatur zu übernehmen. Zum Beispiel zur Architektur ist das Überprüfungsmaterial Software Architect's Handbook von Joseph Ingeno ISBN sehr nützlich: 9781788624060

Mein Bericht ist hier zu finden .

Autor des Artikels: Dmitry Dzyuba, Leiter des Forschungs- und Entwicklungszentrums
 

More articles:


All Articles