Strategia technologiczna

Tę lukę wypełnia ta praca. Efektem jest niewielka liczba decyzji, każda z kontekstem i konsekwencjami spisanymi na papierze, oraz kolejność ich wprowadzania. Całość jest krótka celowo. Strategia dostatecznie obszerna, żeby robić wrażenie, jest zwykle dostatecznie obszerna, żeby nikt jej nie czytał.

Oczywista pomyłka to zbudowanie czegoś za małego: rozwiązania, które działa przy pierwszym tysiącu użytkowników i przewraca się przy dziesięciu tysiącach, więc płacisz za przepisanie akurat wtedy, gdy biznes wreszcie rośnie. Mniej oczywista to zbudowanie czegoś za dużego. Mały zespół sięga po architekturę rozproszoną, o której przeczytał, i nagle każda funkcja zajmuje trzy razy więcej czasu, bo prosta zmiana dotyka czterech usług i dwóch procesów wdrożeniowych. Nic się nie zepsuło. Po prostu praca stała się wolna i droga, co znacznie trudniej zauważyć i jeszcze trudniej odkręcić.

Sensowne pytanie nie brzmi „która technologia jest najlepsza”. Brzmi: którą Twój zespół obsłuży w gorszy dzień, na którą znajdziesz ludzi na swoim rynku i na którą Cię stać przy wolumenie, na jaki naprawdę się przygotowujesz. Czasem odpowiedź jest nudna, a nudne technologie bardzo często są tymi właściwymi.

Pomija integracje, dane, które kiedyś trzeba będzie stamtąd wyjąć, oraz koszt zmian w procesach, które wprowadzisz, żeby dopasować firmę do narzędzia. To ostatnie jest najdroższe. Gotowy system pokrywający większość potrzeb jest w porządku, dopóki luka leży tam, gdzie nie konkurujesz. Staje się problemem, gdy obejścia zaczynają dyktować sposób pracy, bo wtedy koszt zmiany obejmuje już przeszkolenie wszystkich od nowa.

Dlatego wyceniamy decyzję w całym jej cyklu, łącznie z wyjściem. Trudność opuszczenia narzędzia nie dyskwalifikuje go automatycznie. Musi być tylko świadomie zapłaconą ceną, a nie niespodzianką.

Roadmapa oparta na progach żyje dłużej. Rozdzielamy ruch odczytowy, gdy główna baza utrzymuje określone obciążenie. Wprowadzamy kolejkę, gdy synchroniczne zadanie zaczyna wpadać w timeout przy normalnym ruchu. Dokładamy drugi region, gdy podpiszesz klienta, którego umowa tego wymaga. Każdy punkt ma warunek, więc odpowiedź na pytanie „czy robić to teraz” da się sprawdzić, a nie tylko przedyskutować.

To chroni też przed zbyt wczesnym wydawaniem pieniędzy. Duża część architektury pod skalowanie jest słuszna w teorii i przedwczesna w praktyce, a próg jest tym, co utrzymuje właściwą kolejność.

Niektóre wybory naprawdę trudno odwrócić: sposób modelowania kluczowych danych, działanie tożsamości i uprawnień, to, kto przechowuje dane Twoich klientów. Tym warto zająć się poważnie od razu. Większość pozostałych (wersja frameworka, dostawca hostingu, narzędzie analityczne) da się zmienić później kosztem, który udźwigniesz, a traktowanie ich jak decyzji na zawsze tylko spowalnia pracę bez żadnej korzyści.

Rozdzielenie jednych od drugich bywa najbardziej użytecznym efektem całej strategii, bo mówi zespołowi, gdzie ma być ostrożny, a gdzie po prostu działać.

Bez tego podziału firmy popadają w jedną z dwóch skrajności. Albo każda decyzja urasta do rangi fundamentalnej i tygodniami trwa dyskusja o wyborze biblioteki, albo wszystko idzie na szybko, aż okazuje się, że model danych nie przewiduje drugiej waluty, a zmiana wymaga migracji wszystkich rekordów historycznych. Krótka lista rzeczy naprawdę nieodwracalnych chroni przed obiema.