Wprowadzenie

Dług technologiczny to coś o czym mało się pisze i mówi, a prawie każdy się z nim boryka. W dużym uproszczeniu to jak zmywanie naczyń: jeżeli robimy to regularnie po każdym posiłku, to zajmuje to góra kilkanaście minut a do wykonania wystarczy ściereczka. Jeżeli jednak uznamy, że zmyjemy naczynia dopiero jak “statki” w zlewozmywaku zasłonią okno kuchni :),  to nie tylko jednorazowo stracimy znacznie więcej czasu, ale dodatkowo zafundujemy sobie walkę z zaschniętym tłuszczem i resztkami jedzenia, dlatego – co ciekawe – czas i wymagane “środki” potrzebne na rzadkie pozmywanie tej góry nagromadzonych naczyń, są zawsze większe niż suma nakładów pracy na częste drobne zmywanie. Zmywanie naczyń to nielubiana a konieczna czynność.

Z technologią w firmach jest bardzo podobnie: postęp techniczny i ewolucyjne zmiany w firmach, są jak narastająca liczba brudnych naczyń: prędzej czy później będziemy musieli to uporządkować (nadrobić) – albo wyrzucić i kupić nowe. Jedno i drugie kosztuje sporo. Dotyczy to w jednakowym stopniu aktualizowania zakresów obowiązków, dokumentacji tego jak firma pracuje, analiz i projektowania, dokumentacji architektury IT jak i upgrade’ów oprogramowania.

Dług technologiczny

Pojęcie ?długu? w projekcie śledzę od lat. Zjawisko to znane jest od lat 90-tych, przykład takiego długu opisuje E.Yourdon, który określa go opisowo jako ?brak projektu? (pomijanie etapu analizy i projektowania), w rozumieniu braku całościowej koncepcji, i wskazuje, że konsekwencją zaciągania tego długu jest ?ustawiczne przerabianie? oprogramowania w takt pojawiania się nowych wymagań. Dług ten (architektoniczny, tu w rozumieniu architektury oprogramowania) jest zaciągany poprzez rozpoczynanie prac nie zaplanowanych i nie poprzedzonych projektowaniem architektury całości. Zadziwia mnie to, że nie raz źle piszą o tym długu także zwolennicy metod zwinnych, które to metody bazują wręcz na zaciąganiu tego długu. Prace polegające na odkrywaniu wymagań metodami kolejnych przybliżeń z pomocą prototypów, przy praktycznie zupełnym braku etapów analizy i projektowania, np. przeciętny ?sprint? to góra tydzień, jeżeli to jedyne planowanie w projekcie trwającym (planowanym na) rok to jest to mega dług.

Nie znaczy to, że wszystko w firmie musi być koniecznie w najnowszej wersji, to zależy od tego jaki cykl życia funduje nam dostawca każdej aplikacji z osobna, jaką strategię wybierzemy My. Każdą należy rozpatrywać niezależnie ale świadomie. Z perspektywy programisty mamy np. tak:

Wiedza o długu pozwala nam również go zaciągać świadomie. Moim zdaniem nie wolno, pod karą chłosty klawiaturami, iść na skróty w częściach korowych systemu ale już w detalach np. interfejsu użytkownika (KTÓRY NIE POSIADA LOGIKI APLIKACJI I LOGIKI BIZNESOWEJ!!!), możemy sobie czasem pozwolić na gorszą jakość. Pójście na skróty w pierwszym przypadku będzie miało brzemienne skutki dla całego systemu, w drugim bardziej lokalne. Jeśli w obu sytuacjach pójście na skróty oznacza zysk 5h to gdzie lepiej zostawić małe lokalne piekiełko? za pomocą Dług Technologiczny : arek online.

Generalnie dług taki dotyczy niemalże każdego obszaru działania organizacji. Warto więc wiedzieć, że takie zjawisko występuje:

Ten prosty diagram obrazuje istotę długu technologicznego, a raczej nawet uogólniając: “długu stagnacji”.  Zielona linia obrazuje schematycznie okresowe, relatywnie drobne, zmiany i ich koszt. Mogą to być zarówno bieżące upgrade’y (patche) oprogramowania jak i aktualizacja dokumentacji opisującej: strategie firmy, zakresy obowiązków pracowników w ich umowach, procedury ISO (i inne) czy po protu projekt w toku. Brak takiego uaktualniania powoduje, że dokumentacja szybko staje się nieprzydatna (bo jest nieaktualna) a  skokowy jej upgrade wymaga czasem nawet praktycznie powtórzenia całego projektu wdrożeniowego (powtórne poniesienie jego dużych kosztów). Dodatkowy koszt skokowy dużej zmiany, to efekt między innymi tego, że: nie mamy na nią zbyt wiele czasu więc poniesiemy dodatkowy koszt skrócenia tej czynności (przymusowy zakup zmywarki). Kolejny koszt to skokowa zmiana przyzwyczajeń ludzi, zmiany ewolucyjne odbywają się płynie, praktycznie bez kosztów, skokowe to dodatkowe szkolenia i czas na dostosowanie. Taki dług potrafi w skrajnych sytuacjach doprowadzić firmę do upadłości albo co najmniej do zniszczenia jej konkurencyjności (brak środków na skokową zmianę technologii, podniesienie kompetencji kadry itp.).

Klasycznym przykładem takiego długu jest obecny problem wielu firm, posiadaczy Windows XP, firm które do tej pory nie wykonały upgrade. Czy to dużo firm? No niestety jak widać, dużo:

W marcu z komputerów z oprogramowaniem Windows XP pochodziła blisko jedna czwarta ruchu w sieci ? wynika z danych firmy Gemius. Zakończenie wsparcia dla tego systemu operacyjnego może być problemem ? oceniają eksperci z Akademii Leona Koźmińskiego.

Zdaniem Macieja Madzińskiego, eksperta Akademii Leona Koźmińskiego ds. innowacji i nowoczesnych technologii, zaprzestanie wspierania systemu Windows XP przez Microsoft będzie problemem i będzie wywoływać, a nawet już wywołuje pewne niezadowolenie. (Koniec Windowsa XP ? problem czy szansa? :: Gemius SA).

W efekcie firmy te nie tylko w końcu i tak poniosą koszt tej aktualizacji. Poniosą także koszty skokowej aktualizacji wielu innych produktów (przejście na nowszą wersje Windows, w wielu przypadkach wymaga aktualizacji wielu aplikacji, systemów zarządzania siecią, ich powtórne wdrażanie itp.).  Niektórzy eksperci oceniają, że w niektórych firmach będą to koszty większe w porównaniu z kosztami “problemu roku 2000”. Przytoczę teraz cytat z innego bloga:

Na blogu Szymona Błochowicza umieszczona jest taka definicja długu technologicznego: ?Cokolwiek co czyni Twój produkt trudnym do zmiany w przyszłości jest długiem technologicznym ? możesz albo zapłacić pełną cenę technologiczną teraz zrobić od razu rozwiązanie elastyczne albo zaciągnąć dług i spłacić go później zrobić rozwiązanie szybkie ale nieelastyczne a przy pierwszej konieczności zmiany mieć trudność z brakiem elastyczności?. Najczęściej dług technologiczny kojarzony jest ze sposobem kodowania, dokumentowania czy też testowania. Ale Arkadiusz Bendedykt na swoim blogu wskazuje również, że ?dług technologiczny to nie tylko pójście na skróty podczas kodowania, to również zaniechanie przechodzenia na najnowsze wersje narzędzi programistycznych oraz nie wspieranie najnowszych systemów operacyjnych?. Jeszcze dalej idzie Jan Rychter, który wskazuje że: ?gdy dotyczy to [tj. pójście na skróty  – przypis A.S.] pojedynczych funkcji w kodzie, dług jest niewielki. Gdy jednak mówimy o decyzjach architekturalnych [wolałbym używać określenia decyzje architektoniczne  – przypis A.S.], może być olbrzymi i pociągać za sobą konieczność przerabiania kiedyś całych systemów?. (źr. Czym jest dług architektoniczny? | Architektura Korporacyjna).

Tak więc stagnacja szkodzi, są to krótkotrwałe zyski, podobne do niezapłacenia rachunku za energie elektryczną: za miesiąc będzie dwukrotnie wyższy plus odsetki. Bieżące, dobrze zaplanowane “aktualizacje” (oprogramowania, dokumentacji projektowej, analizy i planowania, itp.) to relatywnie małe koszty, a dla firmy istotne są nie tyle kwotowe chwilowe wydatki (oszczędności) co płynność finansowa i długoterminowa rentowność. Dlatego permanentni dłużnicy zawsze płaca więcej a czasami bankrutują.  Tu polecam mój wpis z przed roku: Utopia – czyli model ideału pomaga w projektach.

___

Rok później:

A na koniec polecam to:

Zasady panujące na rynku produktów i usług IT wydają się przejrzyste: klient wydaje pieniądze na jakiś produkt, oczekując w zamian określonych korzyści. Jak wynika z udostępnionych przez Gartner Inc. analiz, firmy realizują przy okazji swoją strategię, o której wolałyby klientom nie mówić. Jakie są ich cele? […] Omawiając strategie firm, Gaughan podkreślił również znaczenie działających przy nich ośrodków badawczych. Ich nadrzędnym celem jest tworzenie innowacji w takich sposób, aby ? zachowując pozory rozwoju ? utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe.(źr.  Czego największe firmy technologiczne nie mówią swoim klientom?. oraz oryginał: What Microsoft, Oracle, IBM, And SAP Don’t Tell Customers)

Na zakończenie zapraszam do kontynuacji tego tematu w artykule: Czym jest dług informacyjny.