Architektura w skali to model mentalny
Twojej organizacji przybywa inżynierów. Liczba zespołów przekracza już coraz mocniej możliwość manualnego koordynowania wszystkimi pracami. Pozostaje jedno rozwiązanie: delegować część pracy w dół. Tylko jak to zrobić, by nie zabić efektywności?
Architektura w skali
Przy pracy w każdej większej organizacji prędzej czy później pojawia się problem jak pracować architektonicznie, wspólnie i w jednym kierunku. Możesz kojarzyć ten popularny obrazek z artykułu Balancing Autonomy and Alignment with Accountability:
Zwykle na początku dajemy inżynierom dużą autonomię. A to rodzi swoje problemy.
Problemy pracy zespołowej
W miarę rozrastania się organizacji, coraz więcej zespołów zaczyna pracować równolegle nad różnymi elementami systemu. Każdy zespół chce działać autonomicznie i efektywnie. W rezultacie, często obserwujemy sytuację, gdzie każda grupa:
Wypracowuje własną, lokalną architekture.
Dobiera narzędzia i serwisy według własnych preferencji.
Buduje rozwiązania w sposób, który uważa za najbardziej odpowiedni.
Ta swoboda na pierwszy rzut jest oka korzystna dla produktywności poszczególnych zespołów. Długofalowo niesie ona jednak ze sobą poważne wyzwania na poziomie całej organizacji. Prowadzi to do:
Tworzenia silosów technologicznych.
Duplikacji pracy.
Trudności w integracji systemów.
Niespójności w stosowanych technologiach i praktykach.
Opóźnień w dostarczaniu funkcjonalności.
A takie techniczne bolączki mogą ostatecznie wpływać na biznes powodując:
Spowolnienie rozwoju firmy.
Zwiększenie kosztów operacyjnych.
Problemy ze skalowaniem systemów.
Część organizacji rozwiązuje ten problem przez dodanie dodatkowej warstwy procesów i struktury organizacyjnej na pracę zespołową. Chcemy mieć swego rodzaju spoiwo ponad zespołami, aby architektonicznie na pewno szły w jednym kierunku.
Jednak takie podejście może się okazać krótkowzroczne.
Dlaczego same procesy nie wystarczą
Z drugiej strony, jeśli skupimy się tylko na procesach i strukturze, doprowadzi to do szeregu problemów:
Przepalanie czasu
Nadmiarowe procesy prowadzą do przepalania czasu na nieefektywne działania. Zespoły tracą całe godziny na wypełnianie formularzy, uczestniczenie w spotkaniach i przygotowywanie dokumentów. A wtedy nie skupiają się na faktycznym rozwiązywaniu problemów technicznych.
W efekcie, zamiast przyśpieszać pracę, procesy ją spowalniają i utrudniają wprowadzanie zmian w architekturze.
Brak myślenia krytycznego
Nadmierne poleganie na procesach zastępuje krytyczne myślenie. Inżynierowie działają mechanicznie, podążając za ustalonymi procedurami, zamiast rozumieć sytuację architektoniczną. To prowadzi do powielania nieefektywnych wzorców i hamuje nowe podejścia do rozwiązywania problemów technicznych.
A to łączy się z kolejnym punktem…
Tylko architekci myślą
Decyzje architektoniczne są podejmowane tylko przez architektów i menadżerów. Jednak wiele istotnych wyborów architektonicznych dzieje się na poziomie codziennej pracy programistycznej - w sposobie strukturyzowania kodu, projektowania interfejsów czy integracji komponentów.
Bez wiedzy i zrozumienia szerszego kontekstu architektonicznego, deweloperzy nie są w stanie podejmować tych decyzji w sposób spójny z ogólną wizją systemu. To prowadzi do fragmentacji architektury i tworzenia rozwiązań, które trudno później zintegrować w spójną całość.
Niska elastyczność
Sztywne procesy hamują szybkość reakcji na zmieniające się wymagania techniczne. Organizacja traci zdolność do adaptacji architektury w odpowiedzi na nowe wyzwania technologiczne. Wszystko musi przejść przez warstwę “architektów”.
Rozmycie odpowiedzialności
Nadmiar procesów rozprasza odpowiedzialność za architekturę. Gdy każda decyzja architektoniczna musi przejść przez wiele szczebli zatwierdzenia, trudno określić, kto faktycznie odpowiada za dany obszar. To prowadzi do sytuacji, gdzie nikt nie czuje się w pełni odpowiedzialny za spójność i efektywność architektury systemu.
Uważam, że same procesy nie są rozwiązaniem problemu architektury w skali. Potrzebne jest podejście, które
pozwoli zachować elastyczność i innowacyjność,
jednocześnie zapewniając spójność na poziomie całej organizacji.
To właśnie tutaj kluczową rolę zaczyna odgrywać architektura jako wspólny model mentalny.
Architektura jako model mentalny
Architektura jako wspólny model mentalny to podejście rozszerzające tradycyjne procesy i dokumentacje. To sposób myślenia o systemach, którymi żyje organizacja.
Kluczowe elementy tego podejścia to:
Jasne zrozumienie, co jest możliwe i pożądane, a co niemożliwe i niepożądane w kontekście architektury.
Kryteria dotyczące oceny nowych rozwiązań, sposobów wdrażania - dostępne dla każdej osoby.
Spójne wyznaczenie celów, ograniczeń i wartości architektonicznych.
Podobne metody pracy / dyskusji / wizualizacji architektury.
Wspólny język i nomenklatura wykorzystywana w dyskusjach.
Gdy cała organizacja podziela ten sam model mentalny, przynosi to szereg korzyści:
Offloadowanie części dyskusji - wiele decyzji architektonicznych zapada “w tle”.
Praca z architekturą na każdym poziomie - od niskopoziomowych decyzji po strategiczne wybory.
Uproszczenie dyskusji i wyborów architektonicznych przez ograniczenie możliwych wyborów.
Szybsze dochodzenie do konsensusu w kwestiach architektonicznych.
Tworzenie bardziej spójnych i przemyślanych rozwiązań w całej organizacji.
Aby lepiej zrozumieć, jak taki model mentalny może wyglądać w praktyce, przyjrzyjmy się przykładom z Amazona i AWS.
Amazon i modele mentalne
Przykłady wspólnego modelu mentalnego na podstawie:
Frugality Architect od CTO Wernera Vogelsa,
pokazują, jak spójne zasady mogą kształtować kulturę organizacyjną i wpływać na decyzje architektoniczne.
Przyjrzyjmy się trzem kluczowym elementom:
“Frugality” - Oszczędność jako podstawa architektury
Amazon promuje kulturę oszczędności, która przekłada się bezpośrednio na decyzje architektoniczne:
Koszt jako wymaganie niefunkcjonalne: Każda decyzja architektoniczna musi uwzględniać aspekt kosztowy.
Alignment kosztów z biznesem: Systemy, które przetrwają, to te, których koszty są ściśle powiązane z modelami biznesowymi.
Obserwowalność kosztów: Nieobserwowane systemy prowadzą do ukrytych kosztów, dlatego monitorowanie jest kluczowe.
Ta zasada sprawia, że każdy inżynier w Amazonie myśli o kosztach operacyjnych, a nie tylko o dostarczeniu funkcjonalności.
“Ownership” - Poczucie własności w architekturze
Amazon promuje kulturę własności, która ma głęboki wpływ na podejście do architektury:
Długoterminowe myślenie: Liderzy nie poświęcają długoterminowego zysku dla krótkoterminowych rezultatów.
Odpowiedzialność za całość: Działają w interesie całej firmy, nie tylko swojego zespołu.
You build it, you run it: Odpowiadasz za to co budujesz, aby działało poprawnie, a nie tylko przerzucasz pracę do innego zespołu.
Takie podejście sprawia, że zarówno architekci, jak i inżynierowie czują się odpowiedzialni za długoterminowy sukces systemów, które tworzą.
Architektura jako seria kompromisów
W Amazonie rozumie się, że każda decyzja architektoniczna wiąże się z kompromisami:
Balansowanie wymagań: Koszt, odporność i wydajność często stoją w konflikcie.
Znajdowanie równowagi: Kluczowe jest znalezienie punktu równowagi między potrzebami technicznymi i biznesowymi.
Szeroki kontekst: Inżynierowie myślą o tym, jak ich decyzje wpłyną na szerszą skalę organizacji.
To pomaga w podejmowaniu świadomych decyzji architektonicznych, które uwzględniają różnorodne aspekty i konsekwencje.
Dzięki tym zasadom, Amazon stworzył kulturę, w której każdy pracownik, od inżyniera po architekta, musi się przede wszystkim skupiać na istotnych aspektach architektury. Dzięki temu jest też większa szansa, że podejmie decyzje zgodne z długoterminową wizją firmy.
Rola liderów
Liderzy są tymi, którzy kształtują modele mentalne w organizacji. Dyrektorzy, managerowie i liderzy liniowi mają możliwość bezpośredniego wpływania na sposób, w jaki cały zespół myśli o architekturze i podejmuje decyzje techniczne.
Możemy tutaj wyróżnić 4 obszary tej odpowiedzialności:
Określanie jasnych wytycznych:
Definiowanie kryteriów, na które należy zwracać uwagę przy podejmowaniu decyzji architektonicznych
Ustalanie “złotych ścieżek” dla typowych scenariuszy, w tym wyboru technologii i sposobów wykorzystania nowych narzędzi
Regularne komunikowanie wizji architektonicznej, języka, nomenklatury.
Promowanie spójnego podejścia do architektury:
Regularne przeglądy architektoniczne i analizowanie rozbieżności pomiędzy zespołami.
Podejmowanie interwencji, gdy różnice powodują straty w działaniach organizacji.
Gromadzenie grup praktyków wokół kluczowych obszarów architektonicznych.
Upraszczanie procesu decyzyjnego:
Opracowywanie checklist dla kluczowych decyzji architektonicznych.
Tworzenie szablonów dokumentacji architektonicznej.
Ustanowienie jasnych ścieżek eskalacji dla trudnych decyzji architektonicznych.
Wprowadzanie prostych narzędzi do oceny i porównywania rozwiązań.
Zarządzanie różnicami w tempie rozwoju obszarów i zespołów:
Umożliwienie szybkiego testowania nowych technologii i wzorców.
Definiowanie procesów do stabilnego wdrażania sprawdzonych rozwiązań.
Ustanawianie mechanizmów płynnego przejścia od eksperymentu do produkcji.
Efektywne wdrożenie tych praktyk tworzy kulturę, w której decyzje architektoniczne są podejmowane świadomie, spójnie i z myślą o długoterminowym sukcesie organizacji.
Co dalej?
Aby nie tworzyć artykułów-tasiemców tutaj na dziś postawię kropkę. W kolejnych wydaniach porozmawiamy dokładniej o tym, jak to wdrożyć w życie. Będzie o kierunku architektury, staff engineerach, gildiach architektonicznych, review boardach, czy ADRach.
Stay tuned, a w między czasie daj znać, jak wygląda podejmowanie decyzji w skali u Ciebie 😊