Ukryte pułapki związane z wyborem stosu technologicznego: przewodnik dla dyrektorów ds. technologii

Wskaźnik niepowodzeń projektów technologicznych w przedsiębiorstwach jest dość zaskakujący, ponieważ około 70% z nich kończy się niepowodzeniem z powodu złego doboru stosów technologicznych. Liderzy technologiczni zazwyczaj interesują się nowymi architekturami i najnowocześniejszymi narzędziami, ale takie decyzje często prowadzą do wysokiego zadłużenia technicznego i kosztownych przeróbek systemu. Najczęstsze błędy są dość przewidywalne: skupianie się na modnych technologiach zamiast na dostosowaniu do potrzeb biznesowych, ignorowanie konieczności utrzymania w czasie oraz wybieranie narzędzi, które nie pasują do wiedzy zespołu. Takie błędy powodują kosztowne udoskonalenia, wąskie gardła wydajności i obniżenie morale zespołów programistycznych. Analiza przedstawia rzeczywiste przypadki, w których projekty zostały zniweczone z powodu złych decyzji dotyczących technologii, oraz określa przyczyny niepowodzeń technologicznych. Na podstawie praktycznych studiów przypadków oferujemy praktyczne ramy, które mogą pomóc liderom technologicznym w podejmowaniu świadomych decyzji służących celom biznesowym, wykorzystaniu mocnych stron zespołu i umożliwieniu zrównoważonego wzrostu.

Kierownictwo działów technologicznych wielokrotnie wpada w rozpoznawalne pułapki, które podważają wasze wybory dotyczące stosowanych rozwiązań. Nowe technologie są tematem dyskusji, który zazwyczaj przesłania wizję długoterminowych skutków i kwestie praktycznego wdrożenia. Zadłużenie techniczne ma charakter kumulacyjny, ponieważ nie ma ostrzeżenia, że organizacja znajduje się w pułapce finansowej kosztownych i nieefektywnych systemów, które utrudniają rozwój biznesu zamiast go wspierać.

Urok popularnych technologii

Dyrektorzy ds. technologii regularnie wybierają technologie, które są popularne w branży, a nie te, które są potrzebne ze względów strategicznych. Taki styl powoduje ogromne rozbieżności między potrzebami biznesowymi a możliwościami technicznymi. Atrakcyjność nowych struktur często przeważa nad praktycznymi standardami oceny. Walidacja społeczna okazuje się szkodliwym substytutem podejmowania decyzji opartych na dowodach. Organizacje podążają za najnowszymi technologiami ze względu na presję, aby wyglądać modnie jak wszyscy, a także dlatego, że taka inicjatywa jest ambitna i kusząca. Konsekwencją tego stada mentalności jest wprowadzanie złożonych rozwiązań, które wymagają wielu obejść i dodatkowych nakładów na konserwację.

Niepisana zasada konserwacji

Organizacje często nie mają pełnego obrazu inwestycji technologicznych w tym sensie, że początkowy etap rozwoju nie jest końcem. Analiza oprogramowania dla przedsiębiorstw pokazuje, że w przypadku dużych baz kodu konserwacja zajmuje około 75 procent całkowitego nakładu pracy. To ciągłe obciążenie obejmuje:

• Testowanie
• Wykrywanie i naprawianie błędów
• Optymalizacja wydajności
• Testy zgodności
• Refaktoryzacja
• Obsługa klienta
• Dokumentacja

Subskrypcje oprogramowania generują nowe pułapki kosztowe. Chociaż na początku nie są one kosztowne, w dłuższej perspektywie generują koszty, zwłaszcza w przypadku rozbudowy zespołów i konieczności zakupu dodatkowych licencji. Funkcje premium, usługi wsparcia technicznego i aktualizacje pamięci masowej zazwyczaj wiążą się z ukrytymi opłatami, które nie były widoczne w momencie sprawdzania.

Brak zgodności w zakresie możliwości zespołu

Dostosowanie umiejętności zespołu jest jednym z ważnych aspektów, których nie należy pomijać przy wyborze technologii. Tworząc nowe struktury, organizacje mają tendencję do wybierania frameworków bez oceny ich twórców pod kątem doświadczenia w zakresie prawidłowego procesu wdrażania i utrzymania. Zespoły, które tworzą oprogramowanie przy użyciu technologii, których nie znacie dobrze, muszą zmagać się z następującymi problemami:

• Stroma krzywa uczenia się
• Wolniejsze cykle rozwoju
• Wyższe wskaźniki wadliwości
• Niska jakość wdrożenia

Kierownictwo może być techniczne i przeceniać koszty specyfikacji technicznych, a jednocześnie nie doceniać kosztów szkoleń, złożoności wdrażania nowych pracowników i spadku wydajności. Narzędzia, które nie są dostosowane do możliwości zespołu, prowadzą do słabej adopcji i niskiego zwrotu z inwestycji. Pomyśl o wyborze Ruby on Rails: często wybierany jest ze względu na szybkość rozwoju, łatwość obsługi i szeroką gamę bibliotek ułatwiających szybkie prototypowanie. Te zalety mają jednak znaczenie tylko wtedy, gdy zespoły posiadają już wiedzę na temat języka Ruby. Krzywa uczenia się musi być dostosowana do wiedzy specjalistycznej programistów, aby nie doszło do spadku wydajności. Wymuszone podnoszenie kwalifikacji w trakcie realizacji projektu może zniweczyć dotychczasowe osiągnięcia.

Kiedy projekty technologiczne kończą się niepowodzeniem, analizujemy studia przypadków z różnych branż i firm różnej wielkości, aby zrozumieć przyczyny niepowodzeń. Obie organizacje borykały się z poważnymi problemami technicznymi, które można bezpośrednio powiązać z decyzjami dotyczącymi stosu technologicznego. Przyczyny źródłowe okazały się nieoczekiwanie podobne, między zbyt skomplikowanymi architekturami a problemami z wydajnością i skalowalnością. W tej sekcji wskazano trzy ilustrujące przypadki, w których występuje niezgodność decyzji dotyczących stosu z wymaganiami produktu lub możliwościami zespołu.

Złożoność mikrousług w prostych aplikacjach

Startup SaaS poniósł straty z powodu przedwczesnego wdrożenia mikrousług. W ciągu ponad 18 miesięcy firma stworzyła różne, niekompatybilne ze sobą technologie, co doprowadziło do dyskusji na temat fragmentarycznego systemu, w którym własność przechodziła z rąk do rąk między członkami zespołu. Początkowo system ten wydawał się przemyślany, dzieląc aplikacje na mniejsze, które teoretycznie można było skalować. Jednak brak członków zespołu posiadających wiedzę specjalistyczną lub zwracających uwagę na skuteczne działanie platformy sprawił, że system stał się chaotyczny. Podstawowym błędem było wprowadzenie skomplikowanej architektury przed określeniem wymagań produktu. Mikroservisy są formą radzenia sobie ze złożonością, jednak nie jest to przywilej bezpłatny. Podejście oparte na mikroservisy, zamiast ułatwiać rozwój, okazało się kulą u nogi produktu, który wymagał szybkiej iteracji, w przeciwieństwie do obciążenia systemów rozproszonych. W pewnym momencie firma nie była w stanie dodać nowych pól i korzystać z niektórych wyzwalaczy API ze względu na ograniczenia platformy, co doprowadziło do awarii podstawowych funkcji. Rozwiązanie złożone zostało całkowicie porzucone z powodu frustracji członków zespołu, którzy zamiast korzystać z nadmiernie skomplikowanego stosu, przeszli na arkusze kalkulacyjne.

Ograniczenia wydajności w aplikacjach do gier

Firma zajmująca się grami przetestowała React Native w celu stworzenia wysokowydajnej gry mobilnej, co spowodowało niemożliwe do pokonania trudności techniczne związane z intensywnym wykorzystaniem grafiki. Chociaż React Native ma zalety związane z tworzeniem aplikacji na różne platformy, zasadniczo nie ma możliwości wydajnościowych pozwalających sprostać bardzo złożonym wymaganiom gier. Zespół programistów odkrył, że wydajność wątku JavaScript była znacznie ograniczona. Niezależnie od tego, jak bardzo React Native twierdzi, że jest w stanie zapewnić co najmniej 60 klatek na sekundę, aplikacja ciągle traciła klatki podczas korzystania ze skomplikowanych animacji i interakcji. Diagnostyka wydajności wykazała, że każdy proces wymagający więcej niż 100 ms powodował opóźnienia dla użytkownika. Ograniczenia te miały katastrofalne skutki dla gier wymagających bardziej złożonej fizyki lub renderowania. Załoga próbowała zoptymalizować moduły natywne, ale podstawowa rozbieżność między narzędziem a potrzebami nadal pozostawała. Chociaż React Native umożliwia tworzenie aplikacji na różne platformy przy użyciu tylko jednego zestawu kodów, stało się to mniej istotne, gdy produkt końcowy nie był w stanie spełnić nawet minimalnych standardów wydajności.

Luki w zabezpieczeniach dotyczących skalowania baz danych w aplikacjach finansowych

Aplikacja finansowa typu fintech została uruchomiona ze starszą monolityczną bazą danych SQL i początkowo działała dobrze. Jednak wraz ze wzrostem liczby transakcji system nie był w stanie działać i skalować się. Opóźnienia i zwłoki w przetwarzaniu wsadowym sprawiały, że analiza danych w czasie rzeczywistym była praktycznie niemożliwa. Głównym błędem popełnionym przez dyrektora ds. technologii było nieprzewidzenie potrzeb związanych ze skalowaniem przetwarzania danych finansowych. Projekt bazy danych nie został zaprojektowany do obsługi:

• Skalowanie poziome
• Metody równoważenia obciążenia
• Szczytowe wolumeny transakcji

Wydajność stała się bardzo niska, a czas odpowiedzi na zapytanie wydłużył się do kilku minut. To pogorszenie było katastrofalne w aplikacjach, w których szybkość transakcji jest bardzo ważna dla użytkownika, oraz w aplikacjach finansowych. Po przeprowadzeniu szeroko zakrojonej oceny technicznej firma przeszła na rozproszoną bazę danych o architekturze HTAP (Hybrid Transactional/Analytical Processing). Zmiana ta umożliwiła przetwarzanie tysięcy transakcji na sekundę z niewielkim opóźnieniem, a jednocześnie przeprowadzanie analiz w czasie rzeczywistym.

W studiach przypadków zaobserwowano trzy wzorce błędów powodujących awarie stosu technologicznego. Wszystkie wzorce wskazują na poważną rozbieżność w podejściu do wyboru i wdrażania technologii w organizacjach.

Niewłaściwe dopasowanie złożoności biznesowo-technologicznej

Jednym z najczęstszych błędów przy wyborze stosu technologicznego jest tworzenie przez organizacje sztucznie skomplikowanej architektury, która nie odpowiada wymaganiom biznesowym. Większość firm prezentuje kilka warstw i podsystemów, z których każdy ma być najlepszy w branży, ale cały system jest powolny, zawodny i kosztowny. Wynikiem tej praktyki jest:

• Spowolnienie działania aplikacji spowodowane dużą liczbą warstw
• Skomplikowane przez wielokrotne przekazywanie
• Niewiarygodne, ponieważ każda warstwa ma różne tryby awarii

W przypadku firm opartych na obsłudze klientów każdy zły wybór stosu technologicznego ma bezpośredni wpływ na doświadczenia klientów w postaci długiego czasu ładowania stron i awarii, co zwiększa wskaźnik rezygnacji.

Dług techniczny i refaktoryzacja

Wczesna inwestycja w niewłaściwą technologię powoduje powstanie długu technicznego, który staje się coraz trudniejszy do spłacenia. W rzeczywistości większość budżetów IT firm przeznacza się na utrzymanie i wsparcie oprogramowania, a nie na innowacje. Gdy organizacje zainwestują znaczne środki w problematyczne stosy, błąd utopionych kosztów może skutecznie powstrzymać je przed wprowadzeniem zmian. Refaktoryzacja musi być wartościowa i powinna koncentrować się na zaspokajaniu rzeczywistych potrzeb, a nie na spekulacjach. Refaktoryzacja na dużą skalę, której nie można przeprowadzić w ramach normalnych procesów programistycznych, stanowi wyzwanie dla wielu organizacji. Przebudowa podstawowych elementów architektury zazwyczaj wiąże się z usunięciem i ponownym utworzeniem zasobów, co naraża ważne dane biznesowe na niebezpieczeństwo.

Słabe strony dokumentacji i wdrażania nowych pracowników

Błędy i niedociągnięcia w dokumentacji firmy powodują wysokie ukryte koszty, ponieważ proces wdrażania nowych pracowników trwa dłużej niż to konieczne, gdy praktyki dokumentacyjne są słabe. Wiele działów inżynieryjnych pozostaje w tyle pod względem tworzenia wysokiej jakości dokumentacji wewnętrznej, ale cena niespójności jest znacznie wyższa niż koszt włączenia dokumentacji do procesów. Nowi członkowie zespołu tracą dużo czasu na wyszukiwanie i ponowne odkrywanie odpowiedzi lub popełniają błędy, których można uniknąć, jeśli informacje są odpowiednio udokumentowane. Taka sytuacja powoduje znaczny spadek wydajności, w wyniku którego niektórzy programiści nie są w stanie efektywnie pracować przez tygodnie, a nawet miesiące.

Aby uniknąć pułapek związanych z wyborem stosu, konieczne jest wyjście poza unikanie modnych haseł. Wymaga to dokładnego przemyślenia tego, co tworzysz, osoby, która to tworzy, oraz sposobu, w jaki twój system będzie się rozwijał.

Zdefiniuj zakres produktu

Przed porównaniem narzędzi określ cel i przewidywaną żywotność produktu. Czy jest to MVP, które szybko się rozwija i ma cele krótkoterminowe? A może platforma, która ma się stopniowo rozwijać w ciągu pięciu lat? Przewiduj też ewolucję. Jeśli przewidujesz integracje, analizy lub dodawanie ról użytkowników, wybierz stos, który będzie można wykorzystać w tych scenariuszach bez konieczności przebudowywania całego stosu.

• W przypadku produktów krótkoterminowych szybkie systemy programistyczne (np. MEAN lub Firebase) zapewnią szybkość i elastyczność
• W przypadku systemów długoterminowych skup się na modułowych, łatwych w utrzymaniu architekturach, które nie będą wymagały znaczących zmian.

Na papierze stos może wydawać się idealny, ale gdy nikt z twojego zespołu nie jest w stanie debugować niczego w środowisku produkcyjnym, ani nawet dostosować stosu, aby działał lepiej, staje się on obciążeniem.

• Wybierz technologie, które są już znane twoim inżynierom, na wypadek presji czasu związanej z terminem dostawy.
• Zaplanuj z wyprzedzeniem użycie stosu kompatybilnego z przyszłymi wersjami, ale zarezerwuj czas na audyt kodu, wdrożenie i szkolenie.

Weź pod uwagę wymagania zewnętrzne

Wybór stosu nie odbywa się w próżni. Wymogi dotyczące zgodności, budżetu i integracji są między innymi rzeczywistymi potrzebami, które powinny znaleźć odzwierciedlenie na wszystkich poziomach architektury. Zgodność i bezpieczeństwo: W branży fintech lub opieki zdrowotnej upewnij się, że twój stos jest przyjazny dla dzienników audytowych, posiada kontrolę dostępu opartą na rolach i zawsze kompatybilne w górę szyfrowanie. Budżet: Weź pod uwagę koszty licencji, infrastruktury, usług zarządzanych oraz inne ukryte koszty, takie jak korzystanie z API stron trzecich, a nawet koszty związane z blokadą. Integracja: Jeśli twój stos nie integruje się z innymi systemami, możesz napotkać problemy. Gromadź przepływ danych w górę i w dół.

Mierz długoterminową stabilność

To, co dziś jest trwałe, jutro może stracić na znaczeniu. Szukaj:

• Stabilne aktualizacje: Niestabilne aktualizacje lub brak wsparcia społeczności mogą stać się utrudnieniem.
• Dobrze udokumentowany i ugruntowany ekosystem: ułatwi to wdrożenie i zmniejszy zależność od wewnętrznej wiedzy specjalistycznej
• Prostota operacyjna: gdy twój stos wymaga poprawek lub konserwacji przez devops, może nie być skalowalny dla małego zespołu

Wydajność i złożoność operacyjna

Wybór stosu wiąże się z kompromisem:

• Model skalowalności: Czy możesz skalować się poziomo, dodając więcej instancji, czy też jesteś ograniczony do skalowania pionowego z monolitem?
• Wydajność pod obciążeniem: Niektóre stosy lepiej radzą sobie z jednoczesnym wykonywaniem transakcji i są lekkie (np. Node.js), a inne lepiej radzą sobie z wykonywaniem transakcji przy użyciu ciężkich procesorów transakcyjnych (np. Spring Boot)?
• Złożoność operacji: Czy twoja załoga działa i utrzymuje się w sposób niezawodny, czy też jest to operacja na granicy rentowności, którą wprowadzasz?

Podejmuj decyzje dotyczące stosu, które ułatwiają rozwój, a nie powodują zadłużenia technicznego.

Nie ma stosu, który byłby przyszłościowy, ale istnieją bardziej elastyczne rozwiązania. Prawidłowa decyzja jest zgodna z wizją biznesową, misją produktu oraz kompetencjami zespołu i wymaganiami dotyczącymi skali. Pozwala to na szybki rozwój w obecnych czasach i nie stanowi obciążenia w przyszłości. Najskuteczniejsi dyrektorzy ds. technologii nie ograniczają się do wyboru narzędzi. Budują systemy, które przetrwają próbę czasu.

Budowa stosu technologicznego jest jedną z najważniejszych decyzji, jakie dyrektorzy ds. technologii podejmują w swojej karierze. Prawidłowo przeprowadzona sprawia, że system jest skalowalny, wydajny i może działać szybciej. Nieprawidłowo przeprowadzona powoduje zadłużenie techniczne, stagnację innowacji i frustrację zespołów roboczych. Uważaj, aby na początku nie podejmować decyzji, które uniemożliwią ci działanie w przyszłości. Zastanów się, zanim zaczniesz działać, zaplanuj wszystko i zainwestuj w stos, który będzie się rozrastał wraz z tobą. Chodzi o kompromis między:

• Krótkoterminowe wymagania i długoterminowe perspektywy
• Umiejętności zespołu i potrzeby firmy
• Innowacyjność i zrównoważony rozwój

Liderzy technologiczni mogą podejmować strategiczne decyzje, które ułatwiają rozwój organizacyjny, zamiast go utrudniać, unikając pułapek i korzystając z ram strategicznych.