IT-Architektur wichtig ist. Lassen Sie mich Ihnen sagen, warum

Wir lieben das Zeichnen !!

(Miguel Angel Coll) (2. Juli 2020)

Ich habe die letzten 5 Jahre in meine Karriere im Bereich IT-Architektur investiert. In all den Jahren musste ich die bloße Existenz der Architekturfunktion selbst für mich selbst rechtfertigen. Manchmal fühlen wir uns auch als Eindringlinge, umgeben von den Leuten, die wirklich die Arbeit machen (Entwickler und System-Ops).

Nach 5 Jahren bin ich immer noch davon überzeugt, dass Architektur wichtig ist, lassen Sie mich einige Argumente anführen Beweisen Sie es.

Bestes Preis-Leistungs-Verhältnis

Wenn ich nur eine Mission für die IT-Architektur auswählen muss, werde ich diese auswählen. IT-Abteilungen und -Plattformen wachsen normalerweise nur. Einige davon, weil das Unternehmen wächst, andere, weil sich das Unternehmen mitten in einer digitalen Transformation befindet. In jedem Fall ist das Ergebnis das gleiche, Jahr für Jahr haben Sie mehr Systeme, mehr Teams, mehr Komplexität.

Ich möchte eine IT-Plattform wie folgt übermäßig vereinfachen:

Die Hauptfunktion der Architektur besteht darin, die Beziehung zum Die Kosten der IT-Plattform und der Wert, den sie liefert, sind in einem guten Zustand.

Vor einiger Zeit arbeitete ich in einem Reiseunternehmen mit einem Geschäftsmodell, das auf der Online-Produktverteilung über APIs basiert. Diese APIs waren stark mit einem riesigen Monolithsystem gekoppelt, das auf Oracle Exadata basierte. Das bedeutet, dass wir jedes Mal, wenn der API-Verkehr wächst (und der Verkehr mehr als die Conversion-Rate wächst), unsere Datenbank vertikal skalieren müssen.

Architektur steigert die Effizienz der IT-Plattform

Der damalige Architekturvorschlag bestand darin, API-Dienste zu entkoppeln und eine neue Mikrodienstschicht zu erstellen die Cloud, um den gesamten Datenverkehr mit geringeren Kosten abzuwickeln und gleichzeitig die Datenbankinfrastruktur nur für die Buchung und den Betrieb zu behalten (die leider nicht exponentiell wachsen). Das Ergebnis war, dass in den folgenden Jahren keine neue Infrastruktur mehr für die Datenbank benötigt wurde und ein besseres Verhältnis zwischen Datenverkehr und IT-Kosten bestand.

Verwenden Sie dieselbe Sprache

Keine Sorge, ich bin es Ich spreche nicht über Programmiersprachen (Java, Python usw.). Als Architekt bin ich mehr als offen für Vielfalt mit etwas Kontrolle (nicht Chaos). Hier beziehe ich mich auf Conceptual Integrity , einen Begriff, den ich zum ersten Mal in Mythical Man Month und anderen Aufsätzen zum Thema Software Engineering von Frederick P gelesen habe Brooks Jr.

In dem Buch erklärt Fred Brooks, wie IT-Teams wachsen und wie sich diese wachsenden Auswirkungen auf ihre Produktivität auswirken. Für Fred ist die Kommunikation zwischen Teams eines der größten Probleme, die beim Skalieren eines IT-Teams zu lösen sind. Um Aufgaben zu parallelisieren, müssen die Teams so unabhängig wie möglich sein. Sobald jedoch alle Teams auf einer miteinander verbundenen Plattform arbeiten, benötigen wir eine gewisse Kommunikation zwischen den Teams. In diesen Szenarien ist eine gemeinsame Sprache der Schlüssel zum Erfolg.

Ich erinnere mich noch an endlose Gespräche mit meinen ehemaligen Teamkollegen, in denen es um ein System, eine Technologiekomponente, eine Schnittstelle oder einen Baustein ging. Wenn Sie in einer großen IT-Abteilung arbeiten, wissen Sie wahrscheinlich, wie frustrierend es ist, dass Teams die Dinge anders benennen. Manchmal ist es sogar am schlimmsten, wenn sie denselben Namen für verschiedene Dinge verwenden.

Ein häufiges Beispiel für diesen letzten ist die Benennung einer Monolith-Anwendung mit nur einem Namen. Auch wenn es sinnvoll ist (da es sich um einen Monolithen handelt), benötigen Sie mehr Details, wenn Sie diesen Monolithen zerbrechen möchten. Das Einführen verschiedener Namen für die Datenbank, das Frontend, das Datenmodell usw. hilft dabei.

Selbst wenn Sie sich in einer kleinen oder einer größeren IT-Abteilung befinden, ist es immer ein guter Zeitpunkt, um zu beginnen mit einer Namenskonvention, einem Service- / System- / Lösungskatalog usw. Sie wissen nie, wie groß Sie in Zukunft sein werden.

Informationen zur konzeptionellen Integrität, Mit mir, je früher, desto besser.

Designkonversationen erzwingen

In meinen Augen beginnt jede Lösung eines Problems immer mit einem Analyse der Situation und des Entwurfs der Lösung vor der Implementierung. Die Realität für ein Entwicklungsteam ist, dass wir jede Woche neue Probleme auf dem Tisch haben, die gelöst werden müssen. Nach einigen Monaten Business as Usual-Routinen beginnen die Teams mit dem Autopiloten und finden nur Lösungen für Probleme, ohne über die mittel- und langfristigen Auswirkungen nachzudenken.

Die Integration der Architekturfunktion in die Entwicklungsteams hilft immer

Außerdem möchte ich den Entwicklungsprozess der alten Mode in Frage stellen, bei dem das Design als etwas angesehen wird, das erst zu Beginn eines Entwurfs zu tun ist Projekt.In dem Artikel Der Architektenaufzug – Besuch der oberen Stockwerke , Gregor Hohpe beschreibt mein Verständnis der Rolle der Architektur perfekt:

„… Anstatt alle wichtigen Entscheidungen einer Person anzuvertrauen, kann das Projektrisiko um Minimierung der Anzahl irreversibler Entscheidungen .

Architektur muss während des gesamten Entwicklungsprozesses vorhanden sein . Wenn Sie an Agile arbeiten, werden Sie bei jeder Iteration Entscheidungen treffen.

Strategiediskussionen

Als IT-Mitarbeiter werde ich gerne im Vorstand des Unternehmens sein und sehr spezifische Aspekte haben und ausführliche technische Diskussionen. Die Realität für mittlere und große Unternehmen ist, dass es sich die Vorstandsmitglieder nicht leisten können, zu tief in die Details zu gehen. Sollte der Unternehmensvorstand jedoch Entscheidungen über die Strategie treffen, ohne die IT-Situation zu verstehen?

In der heutigen Welt gibt es nur wenige Unternehmen, die sagen können, dass die IT nicht im Mittelpunkt ihrer Strategie steht. Wer ist dann für die Übersetzung der Strategie in die IT verantwortlich und umgekehrt? – Sie kennen die Antwort bereits.

Einer unserer größten Beiträge im Architekturteam von TUI Destination Experiences bestand darin, ein Zielarchitekturmodell zu zeichnen. Mit dem TAM können Nicht-IT-Mitarbeiter unsere wichtigsten Lösungen und Systeme verstehen und wissen, wie sie mit unseren Unternehmenswertströmen verbunden sind. Nach der Verteilung des TAM begannen die meisten unserer Strategiegespräche damit, wie unsere Architektur aussieht und wie wir uns an eine neue Situation anpassen sollten.

Aber seien Sie vorsichtig, ein Zielarchitekturmodell ist nicht als statisch gedacht Bild der Architektur „wie sie ist“ und „zu sein“. Der Versuch, diese Art von Übung zu machen, führt zu etwas Vergänglichem, das nur für ein bestimmtes Projekt geeignet ist. Meiner Meinung nach ist es besser, sich darauf zu konzentrieren, die Hauptkomponenten Ihrer Architektur zu zeichnen, die Dinge auszuwählen, die Sie erhalten möchten (weil sie den Kern Ihres Geschäfts bilden) und auf Dinge hinzuweisen, die Sie ändern oder weiterentwickeln müssen.

Erste Folie der TAM-Präsentation

Denken Sie immer daran, was Dee Hock, der Gründer von Visa, gesagt hat:

Einfache, klare Ziele und Prinzipien führen zu komplexem intelligentem Verhalten. Komplexe Regeln und Vorschriften führen zu einfachem dummem Verhalten.

Bis ins Unendliche und darüber hinaus

Die Besessenheit, agil zu sein, verwandelt die IT-Teams manchmal in kurzfristige Entscheidungsträger . Wie wir bereits besprochen haben, müssen wir sicher sein, dass die Entscheidungen, die wir heute treffen, zukunftssicher sind. Manchmal bedeutet es, langfristig eine klare Sicht auf die Strategie zu haben. Manchmal bedeutet es, vorsichtig zu sein, wenn Sie sich nicht auf eine Lösung festlegen, die nicht zu Ihrer Zukunft passt. In den meisten Fällen müssen Sie ein Standardqualitätsniveau sicherstellen und sich an alle Anforderungen anpassen können.

Wie wir bereits kommentiert haben, muss Architektur auch auf strategischer Ebene arbeiten. Dies bedeutet, dass wahrscheinlich neue Informationen über zukünftige Möglichkeiten vorliegen werden, die sich auf die IT-Plattform auswirken könnten. Manchmal sind diese strategischen Änderungen sogar vertraulich. Es ist manchmal eine schwierige Aufgabe, Einfluss auf einige Entscheidungen zu nehmen, die versuchen, Reuebewegungen zu vermeiden, da nicht informierte Menschen den wahren Grund dafür nie verstehen werden.

Irgendwann befanden wir uns mitten in der Krise Diskussion über die Verbesserung der Architektur der B2C-Plattform. Es ist wirklich sinnvoll, die Architektur stark zu verbessern. Einige von uns wussten jedoch, dass wir Gespräche führten, um ein Unternehmen zu erwerben, das unsere B2C-Plattform ersetzen wird.

Vertrauen Sie mir, es ist nicht immer einfach, Architekt zu sein, aber Sie müssen immer darüber nachdenken, was das ist Am besten für das Unternehmen.

Und auch…

… Auch wir lieben das Zeichnen und werden das Büro viel cooler machen.

Entwicklungsteam, das Diskussionen unter Verwendung eines Architekturdiagramms führt

Hoffe auf diesen bescheidenen Beitrag Tragen Sie in Zukunft dazu bei, einen so schönen Job zu verstehen.

Migue Coll, Leiter der Technologiedomäne bei Tui Destination Experiences.