Współczesne ICT składa się z klocków

Data: 2013-07-02
Autor: Sebastian Konkol

Doradzam ostatnio w bardzo ciekawym projekcie rozwoju informatyki. Niestety, zaniedbałem poważnie z tego powodu bloga – bardzo przepraszam. Projekt jest ciekawy, bo mało kto na świecie takie robi. I nie dlatego, że jest niebywale innowacyjny, bo jest raczej typowy. Projektuję system bilingowy „od podstaw” (sic!)… Mój klient, po dokonaniu (jak twierdzi) przeglądu wielu dostępnych rozwiązań bilingowych uznał, że żaden z nich nie jest w stanie spełnić wymagań stawianych przed takim systemem. W konsekwencji zdecydował, że jedyną pozostającą do dyspozycji drogą jest wyprodukowanie takiego systemu samodzielnie.

Przez pewien czas pracy na początku tego projektu nie potrafiłem zrozumieć, dlaczego tak jest – co spowodowało podjęcie takiej, dość ekstremalnej decyzji. Jak to zwykle bywa, oczywiście powody są niemalże trywialne i sprowadzają się do dwóch opowiadań z historią w tle.

Opowiadanie pierwsze, o zaufaniu. Tradycja postrzegania informatyki w firmach rysuje zwykle konflikt między dwoma stronami: IT i tzw. biznesem (każdy, kto nie jest z IT). Historia mojego klienta nie odbiega tu od tej tradycji. Przez lata tradycyjnej działalności IT (nie robienie tego, czego biznes oczekuje, jeśli już robienie to z opóźnieniami, wymuszanie ponoszenia większych kosztów niż obiecane) i biznesu (ciągła zmiana zdania, niechęć do potwierdzania ustaleń, eskalacje problemów na najwyższe poziomy hierarchii organizacji) narosły między tymi dwoma stronami konfliktu wystarczające – w pełni obiektywnie uzasadnione – animozje, których efektem stał się całkowity wzajemny brak zaufania. W związku z obecnym stanem przeniesienia wagi organizacji w kierunku biznesu (co nie powinno nikogo zaskakiwać), biznes ten stosuje politykę siły – prezentuje postawę roszczeniową egzekwując ją przez pryzmat narzucania rozwiązań systemowych. Tak, biznes projektuje systemy informatyczne, choć – w mojej ocenie – narzucając pierwsze z brzegu rozwiązanie, jakie (w ich mniemaniu) załatwi taki czy inny problem, nie mając nawet cienia wiedzy o ćwierćwieczu doświadczeń ludzkości w sferze tworzenia systemów bilingowych. Kontynuując politykę siły, każda podejmowana przez IT próba wpłynięcia na kształt „wymyślonego” przez biznes rozwiązania traktowana jest jak „kombinowanie” niemalże na pograniczu zdrady. Biznes siłowo przewalcza rozwiązania, które z poprawnością, efektywnością, zdolnością do rozwoju i całą tą resztą nie mają nic wspólnego.

Opowiadanie drugie, o etyce zawodowej. W środowisku z opowiadania pierwszego działają analitycy z IT, którzy mają za zadanie opracować system spełniający wymagania biznesu. Biznes nie wypowiada jednak wymagań, tylko rozwiązania. Naturalnym zachowaniem analityków IT powinno być wyjście od rozwiązania do zrozumienia rzeczywistych wymagań i dopiero dla nich opracowanie rozwiązania. W związku z polityką siły nie chcą oni być jednak kozłem ofiarnym historii, więc po prostu spisują rozwiązania dyktowane przez biznes i traktują je jako poprawny projekt systemu. No i wychodzi z tego potworek… Analitycy, choć – przynajmniej teoretycznie – znają rozwiązania stosowane w systemach bilingowych nawet nie dokonują próby przetransformowania rozwiązań „zaprojektowanych” przez biznes do postaci zgodnej z wzorcami tworzenia systemów bilingowych. Te rozwiązania są realizowane i wdrażane, a później – ku zaskoczeniu wszystkich – są do bani, bo nic nie daje się z nimi sensownego już zrobić. Winne temu jest IT, co daje biznesowi jeszcze silniejszy mandat do „projektowania” systemów informatycznych. I błędne koło się zamyka.

A podstawą dla takiego stanu rzeczy jest błędne zrozumienie współczesnej roli informatyki – opieranie się o tradycyjne podejście do budowy systemów informatycznych, w którym dominującym trybem pracy było zaprogramowanie systemu w zgodzie z wymaganiami. Współczesna informatyka polega jednak bardziej na konstruowaniu rozwiązań z dostępnych komponentów (jak składanie dowolnych konstrukcji z klocków LEGO®). Podejście to zasadza się na oczekiwaniu doboru gotowych rozwiązań, dla których – minimalnym wysiłkiem – udaje się uruchomić rozwiązanie spełniające większość wymagań. Dwie sprawy wymagają tu jednak podkreślenia: minimalny wysiłek oznacza tu zarówno minimalny wysiłek rozwoju systemu, jak i uproszczenia organizacyjne oczekiwań biznesowych, a większość wymagań oznacza, że realizacja części z nich ma zawsze charakter wodotrysku i nie jest uzasadniona ekonomicznie.

Ja wierzę, że – po ćwierćwieczu doświadczeń z konstrukcją systemów bilingowych – ludzkość dopracowała się właściwego podejścia popełniając już wszystkie błędy, jakie można było popełnić. Ergo, istnieją wzorce tworzenia takich systemów, a bardzo analogiczne wnioski można wysnuć w stosunku do innych klas systemów, jakie wypełniają przestrzeń dostępnych rozwiązań informatycznych. Rzecz jasna, projektując system bilingowy dla mojego klienta korzystam z dorobku cywilizacji homo sapiens w tym obszarze i „układam z klocków”. Przyznaję, że reguły rozliczeń stosowane przez mojego klienta „nieco odbiegają” od typowych (choć często z powodów nie tyle biznesowych, co chęci „łatania i sprzątania” błędów organizacyjnych popełnionych w innych miejscach) i mogą stanowić wyzwanie. Dla mnie nie znaczy to jednak konieczności zbudowania tego systemu od podstaw, a jedynie umieszczenie właściwych zmian we właściwych miejscach i komponentach architektury.

Na dzisiaj więc – o ile nadal ważna jest efektywność ekonomiczna rozwoju systemów informatycznych – przepis na postępowanie podczas tworzenia systemów informatycznych powinien być zdecydowanie inny, niż powszechnie stosowany:

  1. umieścić oczekiwania biznesowe w kontekście istniejących, gotowych systemów, posługując się architekturą jako podstawą dla zrozumienia;
  2. zrozumieć filozofię funkcjonowania gotowego systemu – poznać możliwości wpływania na jego działanie, framework, możliwości rozbudowy, a przede wszystkim ograniczenia;
  3. dokonać analizy luk (oczekiwania biznesowe a filozofia funkcjonowania gotowego systemu) prawdopodobnie przechodząc ścieżkę rozwiązanie biznesu à zrozumienie wymagań à wypracowanie poprawnego rozwiązania;
  4. opracować zakres zmian mieszczących się w filozofii funkcjonowania gotowego systemu.

Lepiej jest spełniać 80% wymagań w krótkim czasie, niż 95% za późno – 100% nie osiąga się nigdy.

Jedna dodatkowa przestroga. Korzystanie z systemów gotowych nie jest już wyłączną decyzją ICT, to decyzja podejmowana wspólnie z biznesem, bo oni także (a może przede wszystkim?) muszą zrozumieć możliwości, rozszerzalność i ograniczenia takiego systemu – żeby później budować na nim reguły biznesowe, które nie stoją w rażącej sprzeczności z filozofią funkcjonowania gotowego systemu.

Zakładając więc, że obu „stronom” konfliktu zależy na realizacji oczekiwań i obie strony podchodzą do tego ze zdrowym rozsądkiem i otwartością, nie ma rzeczy, której nie dałoby się zrobić narzędziami technologii teleinformatycznej. Wszystko to trzeba jednak robić z głową – inaczej wszyscy na tym stracą, a najbardziej firma.

Pozostaw komentarz