Czy zwinność ma TCO?

Data: 2021-07-21
Autor: Sebastian Konkol
Czy zwinność ma TCO?

Oczywiście, że ma, jak (prawie?) wszystko – a w naszej branży chyba wręcz „wypada, żeby miało”. Większość decyzji w IT podejmowana jest pod wpływem wyliczeń TCO. Byłem przez jakiś czas „w okolicy” szeregu takich decyzji. Upłynął jednak pewien czas, wystarczająco długi, aby pozwalał na wnioskowanie. No i coś poszło nie tak z tym TCO zwinności, bo nie wychodzi.

Jeśli spodziewasz się konkretnych współczynników, benchmarków i wyliczeń, to nie tym razem. Zamiast tego proponuję zmianę perspektywy, spojrzenie na zwinność we właściwym – moim zdaniem – otoczeniu. Wiele terminów – jak mikrousługi, CI/CD, konteneryzacja, Cloud, TDD, IaC, DevOps, OpenSource, API – bardzo często występują we wzajemnym towarzystwie oraz w towarzystwie Agile. Każdy z nich może wywierać pozytywny wpływ na TCO zwinności, na różne sposoby:

  • Zmniejszanie kosztów procesu wytwórczego (Agile, DevOps, OpenSource). Esencją efektu ekonomicznego agile jest zdolność do wykonywania niskokosztowych eksperymentów. Rzeczywistość bowiem pokazuje, że błędy w oprogramowaniu są i będą, bo człowiek jest istotą omylną. TCO zwinności nie buduje się na nieomylności, ale na zmniejszeniu „marnowania czasu”, bo wyniki małego eksperymentu można bez żalu „wyrzucić do kosza”, a półrocznego releasu się po prostu nie da.
  • Zmniejszenie kosztów inwestycyjnych (Cloud). Dziś wiadomo już, że opowieści o taniości rozwiązań chmurowych należy lokować razem z Andersenem, a może bardziej przy braciach Grimm. Tym niemniej, jak w każdej bajce, u podstawy chmury leży ziarno prawdy, bo chmura pozwala na „odwracanie” procesów zakupowych przy minimalnych kosztach transakcyjnych – można wynająć infrastrukturę na chwilę i oddać ją po czasie eksperymentu.
  • Eliminacja błędów człowieka (TDD, IaC, CI/CD). Od dłuższego już czasu rozwój oprogramowania kieruje się nie tyle jakością (choć tak o tym mówi się w uproszczeniu), co przyspieszeniem wykrywania i korygowania błędów popełnianych przez ludzi. To, co dla rozwoju oprogramowania w tej mierze wprowadza TDD, dla budowy infrastruktury w chmurze dostarcza IaC, zapewniając zdolność do weryfikacji poprawności tworzenia środowiska działania systemu. Jeśli do tego dodamy automatyzację (czyt. powtarzalność, brak niepewności „czynnika ludzkiego”) w postaci CI/CD, uzyskujemy maszynerię usuwającą „pola do popisu” dla wprowadzenia błędów.

Wszystko oczywiste, powie każdy praktyk. Nie bądźmy hipokrytami, powiem ja, wszak błędy będą się pojawiać, nawet przy tak ścisłym sicie testów, weryfikacji i walidacji. Na powyższych nie kończy się możliwość wywierania pozytywnego wpływu na TCO, szczególnie w sytuacji, kiedy jakiś błąd jednak się przedostanie:

  • Zmniejszanie ekspozycji na konsekwencje błędów (Agile, mikrousługi, API). Tworzymy rozwiązania o stopniach złożoności wymykających się percepcji pojedynczego człowieka, a w takich okolicznościach nie sposób przewidzieć pełni konsekwencji popełnianych błędów. Dzielimy więc tę złożoność, często arbitralnie, na mniejsze i radykalnie ograniczamy możliwości wzajemnej interakcji w liniach podziału. W ten sposób ograniczamy zasięg wpływu popełnianych błędów.
  • Skrócenie czasu powrotu do stabilnego rozwiązania (konteneryzacja, IaC, CI/CD). W każdej sytuacji błędu znacznie skuteczniejsze jest poradzenie sobie z nim w kontrolowanych warunkach środowiska testowego i przy mniejszej presji czasu. Dzisiejsze rozwiązania pozwalają nam po prostu powrócić do poprzedniego stanu środowiska produkcyjnego, nie zaś prowadzenia „nierównej walki z czasem i nerwami” usuwając błąd na produkcji. Im szybciej potrafimy – automatycznie – przywrócić stabilny stan produkcji, tym mniejsze straty spowodowane błędem i tym szybciej można się zająć jego eliminacją.

Lista ta raczej nie wyczerpuje czynników wpływu, ale pokazuje, że świat zrozumiał jedną prostą myśl: w sferze IT dużo poważniejszy efekt można uzyskać przez redukowanie ryzyka i przyspieszenie dostarczania nawet cząstkowej wartości biznesowej, niż przez nawet wielkoskalową oszczędność kosztów. Wcale nie chodzi bowiem o minimalizację kosztów wytwarzania oprogramowania, ale o całość kosztów posiadania, w tym konsekwencji popełniania błędów i „obsługi” takiej sytuacji. Stabilność produkcji nie musi być zakładnikiem time-to-market.

Za takim myśleniem o TCO stoi szersza myśl. Tak naprawdę bowiem, nie chodzi ani o zwinność, ani o koszty procesu wytwórczego, ale odporność na błędy (sic!) całego „systemu” tworzenia systemów informatycznych. Dotychczasowe „systemy zarządzania” wytwarzaniem rozwiązań IT opierały się na godzeniu kosztów z szybkością – walka skazana na niepowodzenie. We współczesnych warunkach ta działalność powinna być zoptymalizowana pod kątem odporności (Resilience) na błędogenny sposób tworzenia rozwiązań, narzucony przez tempo naszych czasów. Sama zwinność (Agility) nie wystarczy, a w większości przypadków prowadzi wręcz do wynaturzeń. Być może jest to podstawowy powód porażek większości „zwinnych transformacji”.

Pozostaw komentarz