Architektura IT ma znaczenie. Powiem ci, dlaczego

Kochamy rysować !!

(Miguel Angel Coll) (2 lipca 2020 r.)

Ostatnie 5 lat poświęciłem na karierę, pracując wokół funkcji architektury IT. Przez te wszystkie lata musiałem uzasadniać samo istnienie funkcji Architektury nawet sobie. Czasami czujemy się, jakbyśmy byli intruzami otoczonymi przez ludzi, którzy naprawdę wykonują swoją pracę (programiści i operatorzy systemów).

Po 5 latach wciąż jestem przekonany, że architektura ma znaczenie, pozwólcie, że przedstawię kilka argumentów udowodnij to.

Najlepszy stosunek jakości do ceny

Jeśli mam wybrać tylko jedną misję dla architektury IT, wybiorę tę. Działy i platformy IT zwykle dopiero się rozwijają. Niektóre z nich, ponieważ firma się rozwija, inne, ponieważ firma znajduje się w trakcie cyfrowej transformacji. W każdym razie wynik jest taki sam, z roku na rok masz więcej systemów, więcej zespołów, większą złożoność.

Lubię nadmiernie upraszczać platformę IT w następujący sposób:

Główną funkcją architektury jest utrzymywanie relacji z Koszt platformy IT i wartość, jaką zapewnia w dobrej kondycji.

Jakiś czas temu pracowałem w firmie turystycznej z modelem biznesowym opartym na dystrybucji produktów online za pośrednictwem interfejsów API. Te interfejsy API były silnie połączone z ogromnym monolitycznym systemem opartym na Oracle Exadata. Oznacza to, że za każdym razem, gdy zwiększamy ruch w interfejsie API (a ruch wzrósł bardziej niż współczynnik konwersji), musimy skalować naszą bazę danych w pionie.

Architektura zwiększa wydajność platformy IT

Propozycja architektury w tamtym czasie polegała na oddzieleniu usług API, tworząc nową warstwę mikrousług na chmura do obsługi całego ruchu przy niższych kosztach, przy jednoczesnym zachowaniu infrastruktury bazy danych tylko do rezerwacji i operacji (które niestety nie rosną wykładniczo). W rezultacie nie była już potrzebna nowa infrastruktura dla bazy danych w kolejnych latach i lepszy związek między ruchem a kosztami IT.

Używaj tego samego języka

Nie martw się, jestem nie mówiąc o językach programowania (java, python itp.). Jako architekt jestem bardziej niż otwarty na różnorodność z pewną kontrolą (nie chaosem). Mam tu na myśli Integralność konceptualną , termin, który przeczytałem po raz pierwszy na Miesiąc Mythical Man and Other Essays on Software Engineering autorstwa Frederick P . Brooks Jr.

W książce Fred Brooks wyjaśnia, jak rozwijają się zespoły IT i jak ten rosnący wpływ na ich produktywność. Dla Freda jednym z największych problemów, z którymi należy się zmierzyć, próbując skalować zespół IT, jest komunikacja między zespołami. Aby zrównoleglać zadania, zespoły muszą być jak najbardziej niezależne. Ale gdy tylko wszystkie zespoły będą pracować na połączonej platformie, potrzebna jest komunikacja między zespołami. Czy w takich sytuacjach kluczem do sukcesu jest wspólny język.

Wciąż pamiętam niekończące się rozmowy z byłymi kolegami z zespołu, dyskutujące o tym, czym jest system, komponent technologiczny, interfejs lub element konstrukcyjny. Jeśli pracujesz w dużym dziale IT, prawdopodobnie wiesz, jak frustrujące jest to, że różne zespoły nazywają różne rzeczy. Czasami jest nawet gorzej, gdy używają tej samej nazwy do różnych rzeczy.

Typowym przykładem tego ostatniego jest nazwanie aplikacji monolitycznej tylko jedną nazwą. Nawet to ma sens (ponieważ jest to monolit), kiedy chcesz rozbić ten monolit, będziesz potrzebować więcej szczegółów. Wprowadzenie różnych nazw dla bazy danych, frontendu, modelu danych itp. Pomoże w tym procesie.

Nawet jeśli jesteś w małym lub większym dziale IT, zawsze jest dobry moment na rozpoczęcie z konwencją nazewnictwa, katalogiem usług / systemów / rozwiązań itp. Nigdy nie wiadomo, jak duży będziesz w przyszłości.

O integralności koncepcyjnej, gołe ze mną, im szybciej, tym lepiej.

Wymuś rozmowy projektowe

Myślę, że każde rozwiązanie problemu zawsze zaczyna się od analiza sytuacji i projekt rozwiązania przed wdrożeniem. Rzeczywistość dla zespołu programistów jest taka, że ​​co tydzień mamy nowe problemy do rozwiązania. Po kilku miesiącach rutyny Business as Usual zespoły zaczynają działać na autopilocie i po prostu znajdują rozwiązania problemów bez zbytniego myślenia o średnio- i długoterminowych implikacjach.

Integracja funkcji architektury w zespołach programistycznych zawsze pomaga zintensyfikować rozmowy projektowe, aby znaleźć najlepsze rozwiązania problemów, z którymi się borykamy.

Lubię też rzucać wyzwanie staromodnym procesom rozwoju, w którym projekt jest postrzegany jako coś, co należy projekt.W artykule Winda architekta – zwiedzanie wyższych pięter , Gregor Hohpe doskonale opisuję moje rozumienie roli Architektury:

„… Więc zamiast powierzać wszystkie kluczowe decyzje jednej osobie, ryzyko projektu można zmniejszyć o minimalizowanie liczby decyzji, które są nieodwracalne .”

Architektura musi być obecna podczas całego procesu rozwoju . Rzeczywiście, jeśli pracujesz nad Agile, będziesz podejmować decyzje w każdej iteracji.

Dyskusje o strategii

Jako informatyk z przyjemnością będę zasiadał w zarządzie firmy, mając bardzo konkretne i szczegółowe dyskusje techniczne. Rzeczywistość dla średnich i dużych firm jest taka, że ​​członkowie zarządu nie mogą sobie pozwolić na zagłębianie się w szczegóły. Ale czy zarząd firmy powinien podejmować decyzje dotyczące strategii bez zrozumienia sytuacji IT?

W obecnym świecie jest tylko kilka firm, które mogą powiedzieć, że IT nie znajduje się w centrum ich strategii. W takim razie kto jest odpowiedzialny za przełożenie strategii na IT i odwrotnie? – znasz już odpowiedź.

Jednym z naszych największych wkładów w zespół architektów TUI Destination Experiences było narysowanie Docelowego Modelu Architektury. TAM pozwala osobom spoza IT zrozumieć nasze główne rozwiązania i systemy oraz sposób, w jaki są one powiązane ze strumieniami wartości naszej firmy. Po rozpowszechnieniu TAM większość naszych rozmów dotyczących strategii rozpoczęła się od przyjrzenia się, jak wygląda nasza architektura i jak powinniśmy dostosować się do nowej sytuacji.

Ale bądź ostrożny, Docelowy Model Architektury nie ma być statyczny obraz architektury „taka, jaka jest” i „przyszła”. Próba wykonania tego rodzaju ćwiczeń zakończy się czymś efemerycznym, co po prostu pasuje do konkretnego projektu. Moim zdaniem lepiej skupić się na narysowaniu głównych elementów swojej architektury i wybraniu rzeczy, które chcesz zachować (ponieważ są one podstawą Twojej działalności) oraz wskazaniu rzeczy, które będziesz musiał zmienić lub ewoluować.

Pierwszy slajd prezentacji TAM

Zawsze pamiętaj, co powiedział Dee Hock, założyciel Visa:

Prosty, jasny cel i zasady prowadzą do złożonych inteligentnych zachowań. Złożone zasady i przepisy prowadzą do prostych, głupich zachowań.

W nieskończoność i dalej

Obsesja bycia zwinnym czasami przekształca zespoły IT w krótkoterminowych decydentów . Jak już omówiliśmy, musimy mieć pewność, że decyzje, które podejmujemy dzisiaj, będą przyszłościowe. Czasami oznacza to mieć jasny obraz strategii długoterminowej. Czasami oznacza to, aby uważać, aby nie znaleźć rozwiązania, które nie pasuje do Twojej przyszłości. W większości przypadków oznacza to zapewnienie domyślnego poziomu jakości i możliwość dostosowania się do tego, co nadejdzie.

Jak już powiedzieliśmy, architektura musi działać również na poziomie strategicznym. Oznacza to, że prawdopodobnie będą miały świeże informacje o przyszłych możliwościach, które mogą wpłynąć na platformę IT. Czasami te strategiczne zmiany są nawet poufne. Możliwość wpływania na niektóre decyzje, próbując uniknąć ruchów żalu, jest czasami trudnym zadaniem, ponieważ osoby nie poinformowane nigdy nie zrozumieją prawdziwego powodu.

W pewnym momencie byliśmy w środku dyskusja na temat ulepszenia architektury platformy B2C. Naprawdę warto znacznie poprawić architekturę. Ale niektórzy z nas wiedzieli, że rozmawialiśmy o przejęciu firmy, która zastąpi naszą platformę B2C.

Zaufaj mi, nie zawsze jest łatwo być architektem, ale zawsze musisz się zastanowić, czym jest najlepsze dla firmy.

A także…

… Uwielbiamy rysować i sprawimy, że biuro będzie dużo fajniejsze.

Zespół programistów prowadzący dyskusje przy użyciu diagramu architektury

Mam nadzieję, że ten skromny post przyczynić się w przyszłości do zrozumienia takiej pięknej pracy.

Migue Coll, szef działu technologii w Tui Destination Experiences.