Digitized ≠ Digital

Wstęp

W dniu 11 czerwca 2019 uczestniczyłem w konferencji IX ForumArchitektów IT. Podczas konferencji opowiedziałem, jak zarządzamy architekturą korporacyjną w mojej obecnej, zwinnej firmie. Inne wystąpienia traktowały o roli architekta IT, o zarządzaniu innowacjami, o praktycznej przydatności modelu pojęciowego, o wartości danych w firmie, …

Po części prezentacyjnej miał miejsce m.in. warsztat pt. „Transformacja cyfrowa oczami architekta”. Warsztat miał formę moderowanej dyskusji, podczas której staraliśmy się odpowiedzieć na postawione przez moderatorów pytania dotyczące cyfrowej transformacji. Jedno z takich pytań, na które nie udało nam się odpowiedzieć a wręcz pojawiły się różne odpowiedzi, to pytanie „co to jest digital transformation”. Przykłady takich transformacji przytaczane przez moderatorów i zebranych często nie miały wspólnych cech a mimo to były nazywane „cyfrowymi transformacjami”. Stąd pomysł, aby podzielić się wynikami analiz i badań przeprowadzonych na ten temat przez:

• naukowców z MIT CISR, którzy - na podstawie badań 2014 - 2015 (27 firm) oraz 2016 (171 executives) - odróżniają i oddzielnie definiują znaczenie „digitized” oraz „digital” (niestety z braku dobrych odpowiedników w języku polskim w dalszej części tekstu pozostawiam angielskie nazwy)
• badaczy Gartnera, którzy odróżniają i oddzielnie definiują „digital business optimization” oraz „digital business transformation”

I nie jest to jedynie kwestia samych definicji, które mogą pomóc w komunikacji ale również wynikające z tych definicji różnice dotyczące celów i korzyści, ładu, podejścia do ryzyka oraz podejścia do zmian.

„Digitization”, stawanie się „digitized”

„Digitizaion”, to wg MIT transformacja, w której chodzi o standaryzację a następnie automatyzację głównych, back offic’owych procesów biznesowych. Chodzi o wydajność, skalowalność, stabilność i przewidywalną powtarzalność. Chodzi o bezpieczeństwo i dokładność przetwarzania transakcji. Chodzi o dostęp do danych z tych procesów. Na końcu chodzi o niższe ryzyko i niższe koszty operacyjne podstawowych operacji firmy.

Firmy robią to już od kilkudziesięciu lat wdrażąjąc CRM’y, ERP’y, itp. lecz z różnym efektem. Główną trudnością bowiem nie jest technologia, ale zmiana (zestandaryzowanie, dyscyplina) sposobu pracy. Te procesy i technologie tworzą platformę, którą naukowcy z MIT nazywają „operational backbone”.

„Digitalization”, stawanie się „digital”

Stawanie się „digital”, to już całkiem inne ćwiczenie od stawania się „digitized”. To całkiem inne podejście, cele i często (ale nie zawsze) inne technologie. Stawanie się „digital”, to transformacja, w której chodzi o nową, kliento-centryczną propozycję wartości możliwą do wytworzenia dzięki takim technologiom jak „social”, „mobile”, „analytics”, „cloud”, „internet of things” (SMACIT), czy sztuczna inteligencja, biometria i inne nowe technologie. Te technologie mogą oczywiście być użyte do optymalizacji operacji, ale przede wszystkim mogą być użyte do zbudowania całkiem nowej propozycji wartości. Firma, która jest „digital” używa tych technologii do innowacyjnej rozbudowy swoich produktów i usług oraz spersonalizowanego angażowania klientów. Korzyścią ze stawiania się „digital” nie są niższe koszty czy ryzyka ale wzrost przychodów i marż, wzrost lojalności klientów a także zdolność do pozyskiwania do pracy najlepszych talentów.

Firmy dostarczają tej nowej propozycji wartości w postaci tzw. „digital offerings”, które MIT CISR definiuje następująco: to rozwiązania klienckie wzbogacone o informacje i dostarczane jako bezproblemowe, spersonalizowane doświadczenia klienta (po polsku brzmi to średnio, więc przytaczam wersję oryginalną: „digital offerings = information-enriched customer solutions delivered as seamless, personalized customer experiences”). Przy czym chodzi tutaj zarówno o wzbogacone produkty i usługi (np. wzbogacone o informacje, zintegrowane - tworzące rozwiązanie, w sposób przezroczysty zawierające usługi i produkty partnerów, itp.) jak i o spersonalizowane angażowanie klientów (np. spójność interakcji w różnych kanałach, inne interakcje dla różnych segmentów, interakcje odpowiednie do oczekiwania klienta, dające klientowi więcej informacji/wglądu, itp.).

Efektem „digital offerings” jest wzrost przychodu. Firmy zwykle najpierw tworzą mały „digital” produkt lub usługę a później go szybko rozbudowują lub wprowadzają oferty powiązane. Dokładnie tak samo, jak to robią start-up’y.

Do szybkiego tworzenia i rozbudowy „digital offerings” nie wystarczy wspomniana platforma „operational backbone”. Dlatego w tym celu firmy budują drugą platformę – „digital offerings platform”. Ta druga platforma składa się zarówno z elementów wyłącznie technicznych takich, jak autentykacja czy integracje, ale również z elementów o przeznaczeniu biznesowym, takich jak onboarding klienta czy dashbordy, które firma wykorzystuje (reużywa) dla każdej nowej „digital offering”, co przyspiesza konfigurowanie nowych „digital offerings”.

„Digitized” vs. „digital”

Przytoczone opisy nie są bardzo ścisłymi definicjami, co to jest transformacja „digitized” i transformacja „digital” ale pokazują wyraźną różnicę w celach i korzyściach, podejściu do ładu i podejściu do ryzyka. Różnice podsumowuje poniższa tabela:

Źródło: MIT CISR

W Gartnerze myślą podobnie

Podobny sposób rozróżnienia, na optymalizację oraz budowę nowych propozycji wartości, proponuje Gartner, który odróżnia / zestawia ze sobą dwa różne rodzaje zmian możliwych dzięki technologiom: „Digital Business Optimization” oraz „Digital Business Transformation”. Przy czym używane technologie mogą być w obu przypadkach takie same. To co odróżnia te dwa rodzaje zmian od siebie, to, wg Gartner’a m.in. to, czy zmiany modyfikują / rozszerzają / tworzą nowy model biznesowy, czy nie:

• Jeśli model biznesowy (czyli w skrócie: docelowi klienci, propozycja wartości dla nich, zestaw zdolności, sposób zarabiania) się nie zmienia, to wg Gartner'a mamy do czynienia z „Digital Business Optimization”. Przykładem takiego działania jest np. wdrożenie ERP. Albo użycie drukarek 3D do redukcji kosztów. Albo użycie sztucznej inteligencji do lepszej oceny ryzyka. Czytałem też kiedyś o fabryce, w której wykorzystano virtual reality do poprawy motywacji pracowników pomagając im zobaczyć (właśnie za pomocą virtual reality), że części, które składają, są elementem większej całości (samolotu, statku).
• Jeśli jednak model biznesowy się zmienia lub tworzony jest całkiem nowy, to mamy do czynienia z „Digital Business Transformation”. Przykładem jest zmiana sposobu sprzedawania z produktu (np. płyta CD) na usługę typu pay-as-you-use (dostęp do muzyki). Albo zmiana: sprzedaję tylko swoje usługi / produkty na pośredniczę w sprzedaży czyichś usług / produktów.

Różnice podsumowują dwie poniższe tabele:

„Digital Business Optimization” = tworzy istotną wartość bez zmiany modelu biznesowego (w ramach istniejącego modelu biznesowego):

Źródło: Gartner

„Digital Business Transformation” = prowadzi do utworzenia nowych strumieni przychodów i nowych modeli biznesowych:

Źródło: Gartner

Inną cechą, którą Gartner przytacza jako odróżniającą „Digital Business Optimization” od „Digital Business Transformation” jest stopień kontrolowalności zmienianego środowiska. W „Digital Business Optimization” pracujemy w ramach istniejącego modelu biznesowego, w ramach środowiska, które kontrolujemy w całości. W „Digital Business Transformation” wychodzimy poza organizację i zaczynamy robić rzeczy, których nigdy nie robiliśmy, na których się jeszcze nie znamy. 

Przykładem „Digital Business Optimization”, czyli zmiany w ramach kontrolowanego środowiska, jest wdrożenie autonomicznych ciężarówek w kopalni odkrywkowej lub wdrożenie autonomicznych odśnieżarek na lotnisku – w obu przypadkach środowisko jest w całości kontrolowane przez organizację, wykorzystujemy nowe technologie, tworzymy istotną wartość ale poruszamy się w ramach istniejącego modelu biznesowego. Kontr-przykładem „Digital Business Transformation” jest wg Gartnera autonomiczny samochód poruszający się po drogach publicznych. Tutaj wkraczamy w środowisko, którego nie kontrolujemy.

Dwie różne platformy digi*

Wracamy jednak do badań MIT. Wspomniane wyżej dwie różne platformy „operational backbone” oraz „digital offerings platform” są wg badań MIT CISR i BCG konieczne do sprostania wyzwaniom dzisiejszej, cyfrowej ekonomii, gdyż razem umożliwiają szybkie testowanie, integrowanie i skalowanie cyfrowych innowacji w zakresie produktów i usługa oraz angażowania klienta.

Platformę „operational backbone”, która wspiera efektywność operacyjną, MIT CISR definiuje następująco: jest to zbiór systemów, procesów i danych, który zapewnia efektywność, skalowalność, niezawodność, jakość i przewidywalność podstawowych (ang. core) operacji firmy. Firmy budują takie platformy od lat wdrażając systemy typu CRM czy ERP aby zestandaryzować i zintegrować procesy firmy. Pomiędzy firmami budowa tej platformy może się różnić, ale w każdym przypadku posiada ona (platforma) następujące cechy:

• Automatyzuje zestandaryzowane, powtarzalne procesy
• Jest jednym źródłem prawdy dla krytycznych danych, takich jak dane klientów, dane o zamówienia, dane o produktach
• Zapewnia płynne i przejrzyste przetwarzanie transakcji
• Dostarcza wglądu w te transakcje
• Zapewnia bezpieczne, niezawodne, stabilne przetwarzanie
• Ma modułową architekturę

Posiadanie zbudowanej platformy „operational backbone”, której firma re-używa przy wchodzeniu na nowe rynki, nabywaniu innych firm, czy dodając nowe produkty, pozwala menadżerom skupić uwagę na budowie nowych cyfrowych usług i produktów.

Platforma „operational backbone” jest zaprojektowana, aby wspierać niezawodność i efektywność, ale nie zapewnia szybkości i elastyczności niezbędnych do szybkiego wdrażania cyfrowych innowacji za zakresie usług i produktów oraz w zakresie angażowania klienta. Do tego celu służy druga platforma, „digital offerings platform”, którą MIT CISR definiuje następująco: zbiór możliwości (ang. capabilities) biznesowych i technicznych służący jako baza dla szybkiego rozwoju i wdrażania cyfrowych innowacji. Ta druga platforma musi ułatwiać ciągłe innowacje bez naruszania niezawodności działania platformy „operational backbone”. „Digital offerings platform” posiada następujące cechy:

• Zawiera reużywalne komponenty / usługi techniczne (np. biometria) i biznesowe (np. wysyłanie powiadomień do klientów)
• Zawiera techniczne środowisko hostowania przyszłych cyfrowych, innowacyjnych usług
• Wspiera dostęp do usług zbudowanych przez partnerów
• Jest dostępna przez API dla partnerów zewnętrznych
• Jest dostępna przez API dla partnerów wewnętrznych
• Zawiera repozytoria do przechowywania wielkiej ilości danych z różnych źródeł: z sensorów, z mediów społecznościowych czy danych kupionych
• Zawiera silniki analityczne do analizy tych danych i wyciągania z nich wniosków
• Wykorzystuje platformy chmurowe (PaaS)
• Wykorzystuje oprogramowanie open-source
• Zawiera gotowe do reużycia połączenia do danych i procesów platformy „operational backbone”

Budowa obu platform stawia różne wymagania

Jak się można spodziewać, budowa tych dwóch platform, tych dwóch zbiorów zdolności (ang. capabilities), stawia przed firmą dwa odrębne zbiory wymagań operacyjnych. Firmy bardzo dokładnie projektują architekturę platformy „operational backbone” - tak, aby zrealizować wymagania na ogólnofirmową standaryzację i integrację procesów. Budowa platformy „operational backbone”, to duża zmiana organizacyjna i znaczne inwestycje w duże systemy. Implementacja jest zwykle wolna i zwykle realizowane w trybie waterfall. Niektóre firmy adoptują tutaj metody agile’owe ale zwykle efektem jest po prostu szybszy waterfall.

Wg badań MIT poniższe, tradycyjne praktyki zarządcze, mają największe znaczenie dla budowy platformy „operational backbone”:

• Przeglądy architektoniczne
• Priorytetyzacja inicjatyw technologicznych na poziomie firmy
• Roadmapa rozwoju infrastruktury na poziomie firmy
• Proces zarządzania inwestycjami na poziomie firmy
• Ustalone pryncypia architektoniczne

Dla kontrastu, budowa platformy „digital offerings platform” nie wymaga dużych inwestycji. Zwykle adoptuje się tutaj technologię chmurową, która wspiera szybki rozwój i reużycie mikroserwisów w celu realizacji wymagań pojedynczego produktu, kanału lub segmentu klientów. Elementem platformy są agile’owe metody pracy, z wykorzystaniem których małe, kros-organizacyjne zespoły budują i testują nowe mikroserwisy. Poprzez rozpoznawanie co działa a co nie, te zespoły powoli rozbudowują „digital offerings platform”.

Wg badań MIT poniższe praktyki zarządcze, mają największe znaczenie dla budowy platformy „digital offerings platform”:

• Zarządzanie kosztem i jakością usługi / produktu przez jego właściciela
• Zarządzanie przychodem i zyskiem (marżą) usługi / produktu przez jego właściciela
• Iteracyjny, cross-funkcyjny rozwój usługi / produktu
• Projektowanie kliento-centryczne
• Podejście MVP
• CI/CD

Poniższa tabela zestawia najważniejsze różnice i uwydatnia podejście do budowy ww. platform.

 Źródło: MIT CISR

Zakończenie: „Digitized” czy „digital”?

Wg badań MIT CIST firmy mogą tworzyć „digital offerings” nie posiadając dojrzałej platformy „operational backbone”. Robią to zwykle poprzez dedykowaną jednostkę biznesową odpowiedzialną za budowanie innowacyjnych rozwiązań. Ale okazuje się, że jeśli oferta takiego innowacyjnego rozwiązania znajdzie popyt, to wtedy trzeba szybko uzupełniać braki w platformie „operational backbone”, aby zapewnić przeskalowanie eksperymentu w działający biznes. Z drugiej strony z biegiem czasu firmy inwestujące w innowacyjne, cyfrowe rozwiązania dla klientów wytwarzają ich coraz więcej. Bez możliwości reużycia wspólnych usług i komponentów między nimi (czyli bez istnienia „platformy digital offerings” - platformy „enablującej” szybkie konfigurowanie nowych „digital offerings”) szybko okaże się, że są za drogie (bo zbudowane jako silosowe rozwiązania) lub nie daje się ich integrować tak, jakby tego oczekiwali klienci. Wniosek: aby stać się „digital”, czyli zaproponować klientom nowe propozycje wartości, niezbędne jest zbudowanie obu platform: „operational backbone” oraz „digital offerings platform”.

Deser

Na deser film, w którym obejrzycie i posłuchacie, jak Pani Jeanne Ross z MIT CISR osobiście mówi o różnicy między Digitized i Digital: http://cisr.mit.edu/publications-and-tools/publication-search/d4d-video1/

Polecam :)

Źródła:

• Prentice Brian, Digital Business Transformation Strategy Needs a Change of Perspective, Gartner, 2018, https://www.gartner.com/en/webinars/3858468/digital-business-transformation-strategy-needs-a-change-of-persp, [dostęp 2019-07-01].
• Ross Jeanne W., Sebastian Ina, Beath Cynthia M., DIGITIZED ≠ DIGITAL, MIT CISR, 2017, https://cisr.mit.edu/blog/documents/2017/10/19/2017_1001_digitizednotdigital_rossbeathsebastian.pdf/, [dostęp 2019-07-01].
• Ross Jeanne W., Sebastian Ina, Beath Cynthia M., Digital design: it’s a journej, MIT CISR, 2016, 2017, https://cisr.mit.edu/blog/documents/2016/04/21/2016_0401_digitaldesign_rosssebastianbeath.pdf/, [dostęp 2019-07-01].
• Ross Jeanne W., Sebastian Ina, Beath Cynthia M., Jha Lipsa, The Boston Consulting Group - Technology Advantage Practice, Designing Digital Organizations - Summary of Survey Findings, MIT CISR, 2017, https://cisr.mit.edu/blog/documents/2017/02/28/mit_cisrwp415_ddosurveyreport_rosssebastianbeathjhabcg.pdf/, [dostęp 2019-07-01].

Dług techniczny - czym jest a czym nie jest

Ostatnio w moim otoczeniu często stykam się z tematem „długu technicznego”. Ale podczas rozmów z różnymi ludźmi zauważyłem, że termin ten jest czasami przez różnych ludzi rozumiany w różny sposób. Stąd pomysł na ten tekst.

Wstęp

Termin „dług techniczny” (lub „dług projektowy”) stworzył Ward Cunningham (twórca pierwszego wiki) we wczesnych latach 90’ (patrz: https://www.youtube.com/watch?v=pqeJFYwnkjE). Wywodzi się on z analogii do kredytu, jaki zaciąga się w banku w celu szybszego uzyskania korzyści. W uproszczeniu: zbudowanie rozwiązania nieoptymalnego (na skróty) odpowiada zaciągnięciu kredytu. Dzięki kredytowi okazja rynkowa jest wykorzystana (korzyść mamy dzisiaj), koszt budowy rozwiązania o optymalnej jakości jest odroczony w czasie ale pojawiają się też odsetki. Te odsetki, to w uproszczeniu zmniejszona łatwość zmiany i/lub zmniejszona efektywność lub zwiększone ryzyko działania systemu. Z kolei rozliczenie kredytu równa się doprowadzeniu „zadłużonego” rozwiązania do optymalnej jakości poprzez jego refaktoring lub zastąpienie nowym.

Objawy

Dług techniczny może się objawiać na wiele różnych sposobów dla wielu różnych interesariuszy:

• Użytkownicy mogą być niezadowoleni z użyteczności aplikacji
• Ludzie od infrastruktury i utrzymania mogą być niezadowoleni z powodu wysokich kosztów operacyjnych aplikacji
• Menedżerowie biznesowi mogą być sfrustrowani kosztem i powolnym tempem dostarczania zmian w aplikacji a przez to w procesach biznesowych
• Ludzie z bezpieczeństwa i zarządzania ryzykiem zauważają, że aplikacja nie nadąża ze spełnianiem standardów bezpieczeństwa

Dług techniczny akumuluje się, jeśli nie jest zmniejszany. Z czasem może nawet przewyższyć możliwości firmy do poradzenia sobie z nim. Jednak, aby zmniejszać (spłacać) dług techniczny, trzeba go najpierw dobrze zrozumieć. Czym on zatem jest?

Definicja

Spotkałem się z wieloma definicjami terminu „dług techniczny” (przytaczam je w oryginale):

• "The residual cost of completing technology tasks left undone in the race to be agile, innovative, or from lack of funding".
• "The ongoing costs of inconvenience, inconsistencies, and lost opportunities".
• "Unfunded critical technical liabilities".
• "A design or construction approach that is expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)".
• "Delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules".
• "A trade-off between the short-term benefit of rapid delivery and long-term value".

Zgadzam się z powyższymi definicjami ale wciąż są one dla mnie zbyt ogólne. Z tego powodu najbardziej podoba mi się definicja Gartnera, która określa, o jakie braki techniczne chodzi (a o jakie nie), gdy mówimy o długu technicznym. Wg Gartnera dług techniczny jest „odchyleniem systemu od jego wszelkich wymagań niefunkcjonalnych”. Proste. Z tej definicji wynika na przykład, że:

• dług techniczny nie dotyczy funkcjonalności - brak wymaganej funkcji aplikacji nie jest długiem technicznym,
• dług techniczny jest względny - może się zmienić w jednej chwili jedynie poprzez zmianę wymagań niefunkcjonalnych (np. dostępność systemu wynosi dzisiaj 8/5 ale wymaganie też było 8/5 --> długu nie ma; ale jak tylko zmienimy wymaganie na 12/6, to w tej samej chwili dług się pojawi).

7 obszarów negatywnego wpływu

Skoro więc dług techniczny jest odchyleniem od wymagań niefunkcjonalnych, to do dokładniejszego zrozumienia i oceny poziomu tego długu będzie nam potrzebna klasyfikacja wymagań niefunkcjonalnych. Prosty model takiej klasyfikacji można znaleźć w standardzie ISO/IEC 25010, który jest ulepszona wersją lepiej znanego ale starszego ISO/IEC 9126. Standard ISO/IEC 25010 określa 8 cech jakości oprogramowania, z czego 1 dotyczy funkcjonalności a pozostałe 7 dotyczą cech niefunkcjonalnych aplikacji:

1. „Niezawodność” (ang. „Reliability”) - obejmuje atrybuty niższego poziomu, takie jak „Stabilność” (ang. „Stability”), „Dostępność” (ang. „Availability”) i „Możliwość odzyskania” (ang. „Recoverability”).
2. „Użyteczność” (ang. „Usability”) - obejmuje obszary, takie jak "szybkość uczenia się" a także „łatwość obsługi”.
3. „Wydajność” (ang. „Performance efficiency”) - ilość zasobów obliczeniowych potrzebnych do zapewnienia odpowiedniego poziomu wydajności.
4. „Utrzymywalność” (ang. „Maintainability”) - odnosi się do tych cech oprogramowania, które ułatwiają (lub utrudniają) wprowadzanie zmian w funkcjonalności, naprawianie błędów i zapewnienie jakości usług.
5. „Przenośność” (ang. „Portability”) - obejmuje przenośność między urządzeniami i systemami operacyjnymi a także łatwość, z jaką aplikacja może być zlokalizowana pod kątem specyficznych cech geograficznych, takich jak język czy podatek obrotowy.
6. „Bezpieczeństwo” (ang. „Security”) - obejmuje wszystkie atrybuty bezpieczeństwa systemu.
7. „Zgodność” (ang. „Compatibility”)  - określa łatwość i wydajność integracji zapewnianej przez oprogramowanie.

Wg definicji Gartnera dług techniczny może mieć negatywny wpływ w ww. 7 obszarach i nigdzie więcej. Oznacza to, że w przyrodzie występuje dokładnie 7 rodzajów długu technicznego:

1. Techniczny dług niezawodności (ang. „Reliability Technical Debt”).
2. Techniczny dług użyteczności (ang. „Usability Technical Debt”).
3. Techniczny dług wydajności (ang. „Performance efficiency Technical Debt”).
4. Techniczny dług utrzymywalności (ang. „Maintainability Technical Debt”).
5. Techniczny dług przenośności (ang. „Portability Technical Debt”)
6. Techniczny dług bezpieczeństwa (ang. „Security Technical Debt”).
7. Techniczny dług zgodności” (ang. „Compatibility Technical Debt”).

4 możliwe powody

Wg Gartnera dług techniczny może w systemie powstać z 4 powodów:

1. Dług planowany - zespół projektowy wie, że istnieje pewne wymaganie niefunkcjonalne N, ale z jakiegoś powodu zdecydowano się go nie realizować i wszyscy interesariusze o tym wiedzą. Np. wymaganie odtwarzalności – w przypadku utraty całego data center aplikacja powinna być odtworzona w ciągu 15 minut; niestety okazuje się to za drogie, więc będzie zapewnione odtworzenie w ciągu 4 godzin. Albo sytuacja, w której z powodu braku czasu (potrzeby dostarczenia rozwiązania szybko) rozwiązanie realizuje się bez zaimplementowanych znanych i wymaganych zabezpieczeń. Wszelkie rodzajów PoC’ów (ang. „Proof of Concept”) także się mieszczą w tej kategorii – w zamian za krótki czas budowy i naukę powstaje rozwiązanie o nie-docelowej jakości.
2. Dług dostarczony - zespół projektowy wiedział, że wymaganie niefunkcjonalne N istnieje i planował je zrealizować. Ale się nie udało. Np. system miał móc obsłużyć 200 równoległych użytkowników. Zaprojektowano pod to 6 serwerów. Ale po wdrożeniu okazało się, że te 6 serwerów wystarcza do obsłużenia 100 równoległych użytkowników. 200 równoległych użytkowników będzie wymagać 40 serwerów.
3. Dług odkryty - zespół projektowy spełnił wszystkie określone wymagania, ale po tym, jak system został dostarczony okazało się, że istnieją wymagania, które wcześniej nie zostały określone. Na przykład nie było wymogu "przenośności" językowej, ale po dostarczeniu systemu firma stwierdziła, że aplikacja musi również obsługiwać inne języki, bo firma zamierza otworzyć oddziały w innych krajach. Odkrywamy nowe wymagania niefunkcjonalne (przenośności językowej), które wcześniej nie były wyartykułowane.
4. Dług nabyty - dług, który system nabywa z biegiem czasu, czasami po wielu latach, z dwóch powodów:
1. Zmiana biznesowa – system pracuje dobrze przez wiele lat, ale w wyniku przeglądu bezpieczeństwa powstaje nowa polityka bezpieczeństwa, wcześniej nieistniejąca, która wymaga „single-sign-on” dla wszystkich aplikacji. Albo aplikacja pracuje dobrze w trybie 8/5, ale biznes rozszerza zakres czasowy swojej pracy i aplikacja musi pracować 12/6. W takim momencie aplikacja „nabyła dług”, który jest efektem zmiany wymagań niefunkcjonalnych.
2. Entropia oprogramowania - z czasem, wraz z dodawaniem nowych funkcji do aplikacji, aplikacja staje się coraz trudniejsza do zmiany z powodu wzrostu złożoności. Lub po prostu wzrósł wolumen przetwarzanych danych i aplikacja zaczęła działać wolniej.

Zaniechanie czynności utrzymaniowych nie jest długiem technicznym!

Ww. rodzaje długu są generalnie wynikiem decyzji co do sposobu realizacji lub wynikiem zmiany wymagań niefunkcjonalnych. Natomiast wg Gartnera nie odnoszą się one do sytuacji, w której nie wykonano wymaganych upgrade’ów i w efekcie używana technologia przestała być wspierana. Np. nie dokonaliśmy upgrade’u systemu operacyjnego lub bazy danych na wersję wspieraną, bo budżet, bo priorytety, bo byliśmy zajęci czymś innym. Według ww. definicji to nie jest dług techniczny, gdyż nie jest wynikiem decyzji projektowej, błędu w tej decyzji, zmiany wymagań niefunkcjonalnych, wzrostu złożoności czy wzrostu wolumenu transakcji. Jest wynikiem zaniechania czynności utrzymaniowych.
Dług utrzymaniowy (doprowadzenie do braku wsparcia) wynika zawsze z konfliktu zasobów - z decyzji, na co je przeznaczyć: na nową funkcjonalność, czy na upgrade bazy danych. Nowa funkcjonalność zamiast koniecznego upgrade’u, to odłożenie zobowiązania utrzymaniowego na później. Trzeba jednak zdawać sobie sprawę, że dokonując takiego odłożenia wcale nie oszczędzamy pieniędzy. Odraczamy jedynie nasze zobowiązanie na przyszłe pokolenia a w zamian za te pieniądze (i/lub czas) budujemy nowy feature dzisiaj. Prędzej czy później jednak to zobowiązanie trzeba będzie spłacić. Z długiem technicznym jest inaczej - można go zlikwidować np. poprzez rezygnację z wymagań niefunkcjonalnych.

Ten rodzaj długu - utrzymaniowego - Gartner nazywa „Długiem IT” i definiuje następująco: „Dług IT, to koszt obsługi opóźnionej lub odroczonej konserwacji portfela aplikacji”. Czyli dług IT, to wg Gartner’a ilość pieniędzy potrzebna na doprowadzenie wszystkich naszych systemów do stanu supported.

Podsumowując:

• Twórcą terminu „dług techniczny” jest Ward Cunningham i dotyczy on odchylenia systemu od jego wszelkich wymagań niefunkcjonalnych. Może się pojawić w wyniku decyzji podjętej podczas projektowania i budowy rozwiązania lub w skutek zmiany / nowych wymagań niefunkcjonalnych.
• „Dług techniczny” nie dotyczy odraczania czynności utrzymaniowych na później. Twórcą nazwy dla tego rodzaj długu jest Gartner, który nazywa ten dług „Długiem IT” (ang. „IT Debt”) i definiuje go jako koszt doprowadzenia portfela aplikacji do stanu supported.

Skutki długu technicznego

Wróćmy do długu technicznego, który jest odchyleniem od wszelkich wymagań niefunkcjonalnych. Generalnie celem definiowania wymagań niefunkcjonalnych jest zapewnienie wymaganej „ilości” danej usługi IT - tzn. jej stabilności, dostępności, wydajności, bezpieczeństwa, itd. (usługa IT wg ITIL v3, to funkcjonalność dostarczana w określonej „ilości”). Istnienie długu technicznego tę „ilość” zmniejsza, co z kolei powoduje zwiększenie kosztu i/lub ryzyka operacji, której tej wymaganej „ilości” usługi IT potrzebują. Na przykład:

• Aplikacja z długiem w obszarze utrzymywalności (ang. „Maintainability”) będzie miała wyższe koszty aktywności utrzymaniowych i czynności wprowadzania zmian.
• Aplikacja, która nie osiąga swoich celów w zakresie wydajności (ang. „Performance efficiency”), będzie powodowała wyższy poziom kosztów operacyjnych, gdyż procesy biznesowe przez nią wspierane również będą za mało wydajne.
• Aplikacja, która nie jest w stanie spełnić swoich celów związanych z odzyskiwalnością (ang. „Recoverability”) stwarza wysoki stopień ryzyka biznesowego ze względu na potencjał przedłużających się (tzn. dłuższych, niż dopuszczalne) przestojów w przypadku awarii systemu.
• Aplikacja, która nie jest w stanie spełnić swoich wymagań dotyczących użyteczności (ang. „Usability”), może powodować zwiększenie kosztów biznesowych spowodowanych niezdolnością jej użytkowników do skutecznego wykonywania swoich zadań.

Zarządzenie długiem technicznym jest szczególnie istotne w metodach agile’owych

W metodach waterfal’owych dług techniczny pojawia się zwykle z powodu objawiających się w trakcie projektu ograniczeń czasowych i budżetowych. Jeśli się pojawią (a im większym projekt, tym większe prawdopodobieństwo ich wystąpienia), to w ich efekcie obcina się zakres: nie dostarczymy dokumentacji potrzebnej do utrzymania, nie zoptymalizujemy bazy danych, nie będzie szyfrowania, zahardkodujemy, zamiast zbudować coś konfigurowalnego, itd. Te wszystkie rzeczy, których nie dostarczymy, przekłada się później na „fazę drugą”, na którą z reguły jednak już nie ma budżetu, nie ma zasobów, nie ma planu, … Innymi słowy w metodach waterfall’owych dług techniczny tworzymy w wyniku problemów ale później przeważnie nim nie zarządzamy.

Inaczej to wygląda w metodach agilowych, w których tworzenie długu technicznego jest integralną częścią: kiedy tworzymy MVP (ang. „Minimum Viable Product”), to z definicji tworzymy również dług techniczny, bo rozwiązanie z definicji nie jest docelowe! (to jest tak, jakbyśmy w każdym sprincie robili coraz lepszy PoC :-). Dlatego zarządzenie długiem technicznym jest wtedy szczególnie istotne. W dobrze wdrożonych metodach agile’owych stworzony dług techniczny zapisuje się backlogu. Oznacza to, że zobowiązujemy się do jego usunięcia. W ten sposób dług techniczny jest jawnie zarządzany.

Metody radzenia sobie z długiem technicznym

Wg Gartnera istnieją trzy metody radzenia sobie z istnieniem długu technicznego w aplikacjach legacy:

1. Pierwsza wynika z faktu, że dług techniczny jest względny – zależy od istnienia wymagań niefunkcjonalnych. Więc pierwsza metoda, to zrezygnować z wymagania niefunkcjonalnego. Np. mamy aplikację która działa 8/5 i postawiono przed nią wymaganie dostępności 12/7 (dług się pojawił). Teraz - jeśli z tego wymagania zrezygnujemy i pozostaniemy przy dostępności 8/5 – dług znika. Jeśli jednak wymaganie niefunkcjonalne jest naprawdę ważne i nie możemy z niego zrezygnować, to mamy dwie następne opcje:
2. Zrefaktoruj aplikację, napraw problem – usuń dług. Jednak z wymaganiami niefunkcjonalnymi jest tak, że nie można w ich przypadku mówić o bug’u, więc poprawa kilku linii kodu nie pomoże. Realizacja wymagań niefunkcjonalnych przeważnie zależy od struktury, od projektu całego rozwiązania lub jego dużych elementów, zależy od jego architektury, od decyzji, co jest przetwarzane wsadowo a co jest przetwarzane real-time, co jest zakodowane a co jest konfigurowalne. Innymi słowy naprawienie problemu z wymaganiem niefunkcjonalnym wymaga przeprojektowania aplikacji lub rozwiązania. Co z kolei wymaga uruchomienia dedykowanego projektu i nie da się naprawić w trybie utrzymaniowym.
3. Wreszcie, jeśli zrefaktorowanie aplikacji jest nieopłacalne, to ostatnią opcją jest jej wymiana na taką bez długu, na którego usunięciu nam zależy (i co też przeważnie niestety wprowadzi inny rodzaj długu, o czym prędzej czy później się dowiemy :-)

Zakończenie

Po pierwsze: mam nadzieję, że udało mi się uporządkować pojęcia dot. długów w IT:

• Dług techniczny jest odchyleniem systemu od jego wszelkich wymagań niefunkcjonalnych i jest wynikiem decyzji projektowych lub zmiany tych wymagań.
• Dług wynikający z zaniechania czynności utrzymaniowych Gartner nazywa długiem IT. Jest on wynikiem konfliktujących decyzji o przeznaczeniu zasobów: na utrzymanie czy na rozwój.

Ww. długi są powodowane czymś innym i inaczej usuwane. Warto je więc odróżniać.

Po drugie: Biznes przeważnie nie chce rozmawiać od długu technicznym uważając ten temat za sprawę IT. Zmiana przedmiotu tej konwersacji z dialogu o „długu” (= sprawa IT) na dialog o „wymaganiach” (= sprawa Biznesu) może tę rozmowę uczynić skuteczniejszą. Zamiast mówić o pieniądzach na spłatę długu można mówić o pieniądzach na realizację zmieniających się wymagań niefunkcjonalnych. Np. "Changability" (składnik "Maintainability" wg ISO 25010) - to jest ważne, czy nieważne wymaganie Biznesu? Jeśli ważne, to wymaga sfinansowania. Jeśli nie ważne, to zapomnijmy o skracaniu Time To Market.

Wreszcie po trzecie: ww. klasyfikacja wymagań niefunkcjonalnych i wynikająca z niej klasyfikacja typów długu technicznego (np. dług niezawodności, dług utrzymywalności itd.) może pozwolić na priorytetyzowanie usuwania tego długu. Jest to o tyle istotne, że dług techniczny jest jak problem - jak zaczniesz szukać, to na pewno go znajdziesz, ale nie zawsze akurat ten najważniejszy. Stąd mechanizm priorytetyzacji może być przydatny.

Materiały źródłowe

• BMC Blog, Technical Debt Explained: The Complete Guide to Understanding and Dealing with Technical Debt, 2017, https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/, [dostęp 2019-01-29].
• Carnegie Mellon University, Software Engineering Institute Blog, A Field Study of Technical Debt, 2015, https://insights.sei.cmu.edu/sei_blog/2015/07/a-field-study-of-technical-debt.html, [dostęp 2019-01-29].
• Data Language, Reassessing Technical Debt, 2018, https://datalanguage.com/news/reassessing-technical-debt, [dostęp 2019-01-29].
• Gartner, A Primer on Technical Debt, ID: G00307777, Refreshed: 24 April 2018, Published: 5 October 2016.
• Gartner, Manage Technical Debt to Reduce Cost and Risk, and Improve Delivery Velocity, 2017, https://www.gartner.com/webinar/3564717/player?commId=241241&channelId=5500&srcId=null&webinarType=UpcomingEvent, [dostęp 2019-01-29].
• Gartner, Measure and Manage Your IT Debt, 2010, http://imagesrv.gartner.com/media-products/pdf/cast_software/gartner2.pdf, [dostęp 2019-01-29].
• IDC, Technical Debt: A Framework for Unfunded, Critical Technical Liabilities.
• MIT CISR Blog, Exposing Technology Debt, 2014,  https://cisr.mit.edu/blog/blogs/2014/12/09/technology-debt/, [dostęp 2019-01-29].
• MIT SMR, Technical Debt Might Be Hindering Your Digital Transformation, 2018, https://sloanreview.mit.edu/article/technical-debt-might-be-hindering-your-digital-transformation/, [dostęp 2019-01-29].
• Wikipedia, Technical Debt, https://en.wikipedia.org/wiki/Technical_debt, [dostęp 2019-01-29].