Architektura to decyzja biznesowa. Tylko biznes jeszcze o tym nie wie.
Wyobraźmy sobie sytuację. Wtorek, 16:20. Programista wybiera bazę danych dla nowego, małego modułu. Klika, czyta, szuka – 20 minut. Wybiera tę, która fajnie brzmiała na konferencji, na której był w zeszłym miesiącu. Cztery lata później ta sama firma płaci 280 000 zł rocznie firmie konsultingowej, żeby ogarnąć migrację na inną bazę, bo ta pierwsza już nie pasuje do tego, co biznes z niej zrobił. Nikt z zarządu nie autoryzował tej pierwszej decyzji, bo była „techniczna”. Autoryzował dopiero tę drugą, bo była pieniężna i pojawiła się w budżecie. To jest klasyczna pułapka, w którą wpada większość firm. Architektura to decyzja biznesowa. Tylko biznes jeszcze o tym nie wie.
W skrócie
|
Architektura to nie kod. To decyzje, których nie da się tanio cofnąć
Najprostsza definicja, którą można spotkać w książkach: architecture is the stuff that’s hard to change. Architektura to zbiór decyzji projektowych o wysokim koszcie zmiany. Wybieracie raz i żyjecie z nimi długo. Są trudne do zmiany, bo jedna zmiana pociąga następne. Jeżeli wymienicie bazę danych, musicie zmienić wszystkie systemy, które z nią rozmawiają. Często sięga to aż do interfejsu użytkownika, bo na tych decyzjach buduje się wszystko, co wyżej.
Najprościej pokazać to na przykładach spoza IT. Kuchnia McDonalda i kuchnia restauracji z gwiazdką Michelin. Ta sama branża, te same składniki, ten sam cel: nakarmić klienta. Ale architektura całkiem inna. Przeniesienie kuchni McDonalda do restauracji z gwiazdką nie zadziała. W drugą stronę też nie. Albo Porsche i terenowy SUV. Oba drogie, oba „samochody”. Porsche świetne na proste drogi nad morzem latem. SUV świetny zimą w góry. Zamiana ról: katastrofa. Porsche nie zawiezie nikogo z nartami pod wyciąg. To są decyzje architektoniczne i one nie są wymienne.
W softwarze jest dokładnie tak samo. Wybór głównej technologii, model danych, granice między systemami, sposób komunikacji z dostawcami. Każda z tych rzeczy materializuje się potem w kodzie, w umowach, w SLA z dostawcami. Architektura to nie jest kod. Architektura to są konsekwencje, których nie widać przez pierwsze 18 miesięcy. A potem widać przez kolejne 5 lat.
Cztery dylematy, które wyglądają technicznie, a są biznesowe
Każda decyzja architektoniczna to tradeoff. Klasyczny trójkąt: szybko, dobrze, tanio – wybierz dwa. W architekturze softwarowej ten trójkąt ma więcej niż trzy wierzchołki, ale logika ta sama: architekt wybiera między różnymi rodzajami zła, a nie między dobrym a złym. Jego praca to wybrać to zło, które dla waszego biznesu jest najmniej dotkliwe. Bez znajomości waszego biznesu to jest gra w ciemno. Poniżej cztery decyzje, które na pierwszy rzut oka wyglądają na temat dla deweloperów. Każda ma w środku pytanie biznesowe.
Monolit vs. mikroserwisy
Mikroserwisy brzmią świetnie. Każdy zespół ma swój kawałek, każdy aktualizuje go niezależnie, każdy rośnie w swoim tempie. Cena: trzy razy więcej ludzi do utrzymania, dużo droższa infrastruktura, trudniej zrozumieć całość. Ten układ ma sens przy 50 osobach w IT i milionach userów. Przy pięciu deweloperach raczej nie. Pytanie biznesowe brzmi: gdzie chcemy być za 6, 12, 18 miesięcy? Czy te pięć osób to docelowy stan, czy mamy pieniądze i wiemy, że rośniemy? Bez tej odpowiedzi to wybór losowy.
Pewność danych vs. szybkość rozwoju
Po jednej stronie: saldo zawsze się zgadza, każda zmiana jest audytowalna, wszyscy użytkownicy widzą tę samą wersję danych w tym samym momencie. Cena: każda zmiana w systemie trwa dłużej, kosztuje więcej, trudniej ją cofnąć. Po drugiej stronie: szybkie testowanie hipotez i szybki rozwój. Cena: czasem kolega zobaczy zaktualizowane imię i nazwisko 5 godzin później. Na LinkedInie to nic wielkiego. Gdyby to był numer konta firmowego, na który ma przelać pieniądze, byłby problem. Konkretny biznes decyduje, którą stronę tego dylematu wybiera. Bank inaczej, startup testujący pomysł inaczej.
Budujemy vs. kupujemy
Budujemy własne: pełna kontrola, dopasowanie jeden do jeden, brak miesięcznych opłat. Cena: trzy miesiące zespołu programistów teraz, zamiast działającego rozwiązania w tydzień, oraz jeden wakat miesięcznie na maintenance. Kupujemy gotowe: szybko, ktoś inny utrzymuje, regularny koszt zamiast jednorazowej inwestycji. Cena: vendor lock-in, ryzyko, że dostawca upadnie albo podniesie ceny. Decyzja jest biznesowa, bo dotyczy waszego cashflow, ryzyka i tempa wejścia na rynek.
Szybko na rynek vs. solidnie
Startup, który robi usługę internetową, może dowieźć szybko, złapać feedback, mieć pierwszego klienta i żyć. Ten sam startup robiący „porządnie” przez dwa lata może odkryć, że ktoś inny wygrał szybciej albo że ich pomysł nie był nikomu potrzebny. Z drugiej strony „szybko” w fintechu może skończyć się audytem KNF i grzywną. Wybór należy do biznesu, nie do programisty.
Konkluzja: jeżeli wasz dostawca IT, software house albo własny zespół nie pyta o te rzeczy, to znaczy, że nie ostrzega. Robi architekturę pod siebie, pod swoje przyzwyczajenia albo pod to, co właśnie modne na LinkedInie. To rzadko pokrywa się z tym, czego potrzebuje wasz biznes.
Architecture drivers: sześć pytań, które powinniście usłyszeć od programistów
Zanim architekt podejmie decyzję, powinien znać odpowiedź na sześć pytań. Nie ma jednej globalnej odpowiedzi, bo każdy biznes daje inną. Powinniście rozpoznać te pytania, bo to wy macie na nie odpowiedź.
- Skalowalność. Ile userów, ile transakcji, jak nagłe są piki? E-commerce w Black Friday vs. wewnętrzne narzędzie HR to dwa różne światy.
- Dostępność. Co się dzieje, jak system padnie na godzinę? Duolingo przeżyje, system dyspozytorni karetek nie.
- Time to market. Jak szybko jesteśmy w stanie dowieźć zmianę? Startup szukający modelu biznesowego potrzebuje tygodni. Bank potrzebuje przewidywalności, audytu i bezpieczeństwa, nie tygodni na nowy feature.
- Koszt. Nie tylko budowy, ale całkowity koszt utrzymania przez 5 lat. System wdrożony za 300 000 zł, który potem sypie błędami i wymaga pół roku łatania, kosztuje 600 000 zł, nie 300 000.
- Bezpieczeństwo i compliance. RODO, KNF, HIPAA. Te ograniczenia siadają na architekturze jeszcze przed pierwszą linijką kodu. Spóźniony compliance to przepisywanie systemu i rozwiązania prowizoryczne.
- Talent. Kto utrzyma ten system za 2 lata, na jakim rynku pracy? Może warto wydać więcej teraz, żeby technologia była łatwa do utrzymania przez tańszych deweloperów albo agentów AI później.
Cztery biznesy, cztery architektury
Pokażę, jak te same pytania dają zupełnie różne odpowiedzi w czterech typach biznesu.
E-commerce sezonowy (typu Modivo, Allegro)
Liczy się: przeżyć Black Friday, działać 24/7, szybkie zmiany w katalogu, analityka lejka sprzedażowego. Pasująca architektura: chmura skalująca się automatycznie pod ruchem, dane blisko klienta (CDN), zapasy infrastruktury w gotowości. Niepasująca architektura: serwery w piwnicy firmy, do których w Black Friday trzeba pojechać i dokupić dyski. Brzmi jak żart, a tak ludzie nadal robią.
Fintech albo bank
Liczy się: integralność danych, audytowalność, compliance (KNF, PSD2). Nie możemy sobie pozwolić, że dwa razy wyślemy tę samą transakcję, że komuś się zapisze plus, a komuś nie zapisze minusa. Pasująca architektura: sprawdzone, nudne technologie, rygorystyczna spójność danych, baza SQL-owa, każda transakcja 100% spójna. Niepasująca: modny, eksperymentalny stack technologiczny z konferencji sprzed roku.
Wczesny SaaS B2B (3–5 deweloperów)
Liczy się: zdobyć pierwszego płacącego klienta, utrzymać niskie koszty, móc szybko pivotować, jeżeli rynek powie „nie tędy”. Pasująca architektura: prosty modularny monolit, popularny stack technologiczny (łatwo zatrudnić ludzi), gotowe usługi zamiast własnych (czat od Twilio, płatności od Stripe). Niepasująca: mikroserwisy „bo Netflix tak robi”. Pięciu deweloperów nie utrzyma trzydziestu mikroserwisów.
Healthcare
Liczy się: RODO, audytowalność każdej zmiany, separacja danych klientów (pacjent A nigdy nie zobaczy danych pacjenta B), retencja danych (czasem trzymać 5 lat, czasem usunąć zaraz po wizycie). Pasująca architektura: szyfrowanie wszystkiego, pełen log operacji, możliwość wdrożenia on-premise w infrastrukturze szpitala. Niepasująca: standardowy SaaS trzymający dane w US-East-1 na AWS. Audyt RODO wjeżdża i jest po projekcie.
To są cztery różne projekty, cztery różne odpowiedzi. Jeden architekt z jednym przepisem na wszystko to czerwona flaga. Dobry architekt zaczyna od pytania „co wy właściwie robicie i dla kogo”, a nie „jaką bazę danych macie zamiar użyć”.
Dług technologiczny: kredyt, którego odsetek nie widać aż do momentu, gdy widać
Każdy szybki shortcut w kodzie to pożyczka. Spłacacie ją odsetkami przez kolejne lata, ale w P&L tego nie widać. Aż do momentu, gdy widać. Wtedy widać aż za bardzo.
Są dwa typy długu i one różnią się skalą problemu.
Dług lokalny. W jakimś małym lub średnim kawałku kodu programiści zrobili skrót: nie napisali testów, hardcodowali parametr, pominęli walidację. Stosunkowo łatwy do naprawienia. Tydzień, dwa, czasem miesiąc.
Dług globalny, czyli architektoniczny. Tu już jest poważnie. Zbudowaliśmy system wokół konkretnego dostawcy zewnętrznego, który teraz podnosi stawki o 200%. Zespół mówi: „pół roku trzeba przepisywać, żeby się od niego odpiąć”. Albo: wybraliśmy bazę danych, która nie radzi sobie ze skalą i teraz wszystko zwalnia. Albo: nie mamy granic między modułami, więc każda zmiana w jednym miejscu psuje trzy inne.
Naprawianie długu lokalnego, gdy problem jest globalny, to ślepy zaułek. Programiści gaszą pożary, ale dom nadal się pali z innego powodu. Tym powodem jest decyzja architektoniczna podjęta dawno temu, której nikt świadomie nie zweryfikował.
I teraz pytanie, które warto sobie zadać: kto w naszej firmie obsługuje dług technologiczny i z jakiego budżetu? Jeżeli nie wiecie, to prawdopodobnie nikt go nie obsługuje, a on tylko rośnie. Jeżeli wiecie, że tym zajmuje się dyrektor IT z osobnej puli i to działa, to dobrze. Najgorsza odpowiedź to „pewnie się jakoś samo”.
Czerwone flagi. Jak rozpoznać, że architektura zjada wasz biznes
Tych sygnałów nie trzeba rozumieć z poziomu kodu. Widać je gołym okiem w codziennej pracy firmy.
- Wdrażamy tylko w piątek wieczorem albo tylko w poniedziałek rano. Zespół boi się własnego systemu. W piątek robią release, żeby zdążyć uciec na weekend. W poniedziałek, żeby mieć 5 dni na naprawę. Zdrowy zespół wdraża codziennie, automatycznie, bez udziału człowieka.
- „Tego nikt nie rozumie, tylko Marek”. Marek pojedzie na urlop i połowa firmy stoi. To nie jest zatrudnienie. To jest zakładnictwo. Jest taki wskaźnik bus factor: ile osób musiałoby wpaść pod autobus, żeby firma przestała działać. Wynik 1 to dość ryzykowna sytuacja..
- Roadmapa stoi, bo „najpierw musimy posprzątać”. Cały sprint poszedł na refaktor. Następny też. I jeszcze następny. Dług technologiczny blokuje backlog od środka i biznesowa rozmowa o priorytetach przestaje mieć sens, bo „i tak najpierw posprzątamy”.
- Każda nowa funkcja psuje trzy stare. Klasyczny objaw braku granic między modułami. Programiści zaczynają wpisywać do roadmapy „regresja” jako oddzielne zadanie.
- Estymacje rosną z miesiąca na miesiąc. Funkcjonalność, która rok temu kosztowała 5 dni, teraz kosztuje 20. Powód: każda zmiana wymaga obejścia trzech rzeczy z poprzednich kompromisów.
- Rachunki za infrastrukturę rosną szybciej niż liczba użytkowników. To znaczy, że gdzieś w środku marnuje się dużo zasobów, a architektura uniemożliwia optymalizację.
Jeżeli macie trzy z tych objawów albo więcej, jesteście w trudnej sytuacji. To się samo nie naprawi. Trzeba powołać zespół, załatwić budżet i oficjalnie powiedzieć: musimy się ogarnąć. I po tym, jak się ogarnie, jeszcze wymyślić, co zrobić, żeby do tego za rok nie wrócić.
Chcesz przejść przez to systematycznie?
Powyższa lista to sygnały, które widać gołym okiem. Pełna samoocena stanu technicznego produktu obejmuje 60 punktów w 6 obszarach: architektura, testy, CI/CD, obserwowalność, dane, bezpieczeństwo. Każdy punkt to jedna konkretna praktyka i konkretne ryzyko, któremu zapobiega.
Pobierz Technical Health Checklist i przejdź przez nią z zespołem.
Skala zabija słabą architekturę szybciej niż porażka
Tu jest paradoks, który warto zrozumieć. Słabe architektury nie wybuchają, jak projekt idzie źle. Wybuchają, jak idzie nadspodziewanie dobrze.
Czyli: dopóki macie 100 użytkowników dziennie, wszystko działa. Może nie idealnie, ale działa. Wchodzicie do telewizji śniadaniowej, robi się szum, w jeden dzień 100 000 użytkowników. Architektura, która zniosła setkę, na stu tysiącach pada. Wybitnie pamiętny przykład polski to mObywatel. Pierwszego dnia setki tysięcy instalacji, setki tysięcy wygenerowanych mDowodów w kilka godzin. Infrastruktura się wywaliła i przez weekend nie mogła wstać. Powód: architekt nie przewidział, że jak nas zasypią requestami, to musimy się umieć z tego podnieść. Plus big bang release – zmiany wdrożone wszędzie naraz, bez stopniowego włączania. Sukces ich położył, nie porażka.
To samo dzieje się w mniejszej skali. Influencer wrzuca posta o waszej aplikacji, ruch rośnie 30 razy w godzinę, biznes się cieszy, że ktos o nas napisał. A za godzinę padają serwery, użytkownicy wychodzą, recenzje 1/5 zaczynają lecieć. Większość zespołów nie wie, ile zniesie ich system. Bo nie ma czasu pisać testów obciążeniowych, bo biznes ich nie zamawia, bo „na razie działa”. Dopóki nie zadziała 10 razy intensywniej.
To jest pytanie do waszego CTO albo szefa IT, które warto zadać raz na kwartał: ile godzin przestoju nasz biznes wytrzyma, ile razy więcej ruchu zniesie nasz system i co przestaje działać, jak nasz dostawca chmury padnie na 4 godziny? Jeżeli odpowiedź to wzruszenie ramion, znaczy, że nikt tego nie sprawdzał. To nie jest informacja, którą da się wymyślić w głowie (da się wyhalucynować:)).
Trzy rzeczy do zapamiętania
Pierwsze. Architektura to decyzja biznesowa, nie techniczna. Techniczni ludzie powinni tłumaczyć biznesowi tradeoffy, a decyzje podejmować razem. Architekt powinien być doradcą, nie decydentem (chyba że to CTO na C-level, wtedy okej). Właściwe pytanie do IT nie brzmi „dlaczego wybrałeś tę bazę”, tylko „jak wybierałeś i kogo pytałeś”. To jest jedyne, co da się jednoznacznie ocenić: nie wynik decyzji, tylko sposób jej podjęcia.
Drugie. Nie ma dobrych wyborów architektonicznych. Są tylko gorsze i lepsze tradeoffy. Architekt wybiera między różnymi rodzajami zła. Jego praca to wybrać to zło, które dla waszego biznesu jest najmniej dotkliwe. Nie da się tego zrobić bez znajomości biznesu.
Trzecie. Sukces zabija słabą architekturę szybciej niż porażka. Skala wzmacnia każdy problem. Decyzje, które działały na 5 klientach, padają na 5 tysiącach. Im wcześniej biznes zacznie rozmawiać z IT o tym, dokąd zmierzamy, tym mniej drogich migracji za 4 lata.
I oneliner do zapamiętania: jeżeli wasz architekt męczy was wyborami baz danych, mikroserwisów i tradeoffami, których nie chce wam się słuchać, to bardzo dobrze. Już płacicie. Jeżeli nie męczy, to też płacicie, tylko dowiecie się o tym dopiero we wtorek o 16:20 za 4 lata.
Nie wiecie, jak stoją decyzje architektoniczne u was, albo widzicie, że IT podejmuje je bez was, a wy dowiadujecie się o tym przy okazji rachunku? Skontaktujcie się z nami po audyt architektury. Pomożemy zmapować, gdzie obecna architektura wspiera biznes, gdzie go ogranicza, i zaprojektować rozmowę między IT a zarządem tak, żeby kolejne duże decyzje zapadały na odpowiednim poziomie.
