Wprowadzenie

Od kilku już lat jestem, jako ekspert, angażowany jako rzeczoznawca do sporządzania opinii na zlecenie sądów (opinia biegłego) lub jednej ze stron sporu (opinia prywatna). Są to spory dotyczące nieudanych dostaw i wdrożeń oprogramowania, nie tylko ERP, bardzo często także dedykowanego.

Po tych latach wyłania się pewien wspólny mianownik, łączący te porażki scenariusz:

1. firma dostaje ofertę na dostarczenie i wdrożenie oprogramowania,
2. ma miejsce prezentacja pomysłu, jakieś makiety, jakaś działająca funkcjonalność,
3. przedmiotem oferty jest prezentowane istniejące oprogramowanie z obietnicą jego dostosowania (kastomizacji), lub oferta wykonania dedykowanego oprogramowania,
4. projekt przyjmuje formę umowy T&M, podane są stawki wykonawcy,
5. prawa autorskie (osobiste i majątkowe) do tego co powstaje w toku projektu, są “z zasady” należne wykonawcy, z możliwością przekazania praw majątkowych zamawiającemu (często za dodatkową opłatą),
6. prawnicy obu stron nie mają do powyższego żadnych zastrzeżeń, skupiają na formalnościach: zawarcie umowy, jej rozwiązanie, przekazanie praw majątkowych do kodu, warunki płatności itp… w zasadzie nic co dotyczy przedmiotu umowy, bo nie istnieje opis przedmiotu umowy (nie licząc licencji na standardowe oprogramowanie i ogólnego celu zamawiającego),
7. początek projektu, szybko powstaje (albo jest gotowe) tak zwane MVP (Minimum Valuable Product), zamawiający nabiera zaufania do dostawcy, uwierzył w zwinne projektowanie,
8. kolejne funkcjonalności zaczynają nastręczać problemów, ale wszyscy są dobrej myśli, zamawiający zaczyna coraz częściej słyszeć, że to on jest problemem bo zmienia wymagania i wierzy, że to on jest powodem problemów, dostawca mówi że tak (długo i drogo) ma być to biznes się zmienia i trzeba płacić,
9. zależnie od cierpliwości zamawiającego, zaczyna sie eskalacja problemu, w zasadzie nic nie jest tak jak powinno być, zamawiający zaczyna ponosić straty,
10. zamawiający wstrzymuje płatność za ostatnią fakturę (z powodu umowy T&M, poprzednie są już w praktycznie nieodzyskiwalne), zaczyna sie spór, zaczynają zarabiać kancelarie prawne, często te same, które wspierały projekt na etapie zawierania umowy.

Mityczne MVP?

Co jest problemem wielu firm? Zarząd, który nie ma pomysłu na rozwój. Czy musi go mieć? Nie, może zaangażować analityka, który opracuje model działania organizacji i wskaże na nim możliwe usprawnienia. Jednak wielu nie robi tego wierząc, że dobrym pomysłem jest już samo rozpoczęcie metodą prób i błędów.

Generalnie więc powodem problemów jest zupełny brak pomysłu na to czym ma być rozwiązanie, a sam problem jest zarysowany ogólnie i często do końca niezrozumiany. Mimo to obie strony – firma i deweloper – są pełne zapału.

Jednym z typowych argumentów deweloperów na etapie ofertowania i prezentowania “metodyki pracy” jest mityczne MVP, często prezentowane jak poniżej:

Rysunek ten, w tej i podobnych wersjach krąży po stronach WWW deweloperów i jest chyba jednym najbardziej manipulacyjnych i nieprawdziwych schematów. Deweloperzy często argumentują, że ścieżka dolna jest długa i kosztowna, trzeba płacić i długo czekać na ostateczną wersję produktu, bo najpierw trzeba ponieść koszty projektowania, a do tego czasu “nic nie ma”. Sugerują, że szybko coś przydatnego dostarczą (MVP). W czym problem?

W tym, że:

1. faktycznie rozwiązaniem problemu (potrzeba biznesowa) jest ostatnia pozycja po prawej,
2. wszystkie kolejne pośrednie urządzenia powstają na koszt zamawiającego, są odrzucane (nie spełniają wymagań) a realnie w niczym nie pomagają, no bo rozwiązaniem (potrzebą) jest ostateczny produkt,
3. zamawiający nie ma kompetencji (a nie raz nie ma dostępu do kodu) i nie wie, że realnie płaci za kod, który jest zastępowany kolejnym pomysłem, i tak wiele razy, cały czas na jego koszt,
4. dolna ścieżka realnie, jest znacznie krótsza, bo projektowanie produktu na modelach jest co najmniej o rząd wielkości tańsze i znacznie szybsze, nie realizowane zbędne prace na odrzucanych prototypach,
5. praktyka pokazuje, że w dniu podpisania umowy zamawiający też nie wie (nie ma pomysłu, koncepcji) co ma ostatecznie powstać, więc generalnie projekt sie toczy bez żadnego planu i kontroli kosztów,
6. autorzy tego obrazka całkowicie pominęli fakt, że dzisiejsze aplikacje, podobnie jak ten samochód, w 90% powstają z gotowych i dostępnych na rynku komponentów, więc realnie raczej nie wymyślamy koła na nowo.

Tak więc cała powyższa “metoda” to całkowicie nieplanowany, bardzo kosztowny proces z dużym ryzykiem, że nie powstanie nic wartościowego bo braknie czasu i środków. I tak właśnie wyglądają te sporne projekty.

Troszkę teorii: Komponenty i Paradygmat Obiektowy

Paradygmat obiektowy to hermetyzacja i wymiana komunikatów, a nie “dziedziczenie i łączenie funkcji i danych w obiekty”, które jest cechą pierwszych języków obiektowych i stosowanych w nich wzorcach (C++/Java). W zasadzie JavaEE/Spring to framework oparty na antywzorcach (anemiczny model dziedziny, set/get, brak separacji logiki od backendu, patrz artykuł: Ten straszny diagram klas).

Popatrzmy na to:

Diagram powyżej pokazuje typową monolityczną architekturę po lewej stronie. Kluczowe cechy monolitu to fakt, że każda zmiana funkcjonalności wymaga refactoringu kodu i migracji danych do nowej, większej bazy o nowej strukturze. Za każdym kolejnym razem jest to trudniejsze i kosztowniejsze. Jeżeli zaś jest to np. kastomizowany system ERP, to praktycznie na większą skalę jest to niemożliwe (dlatego producenci tych systemów odradzają takie podejście, patrz artykuł: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje).

Po prawej stronie mamy architekturą komponentową, potocznie i powszechnie określaną jako mikro-serwisy, czasami jako mikro-aplikacje. Jest to tak na prawde znana od lat 90-tych architektura komponentowa , patrz także .

Kluczową cechą tej architektury jest wzajemna komunikacja komponentów (integracja) jako wymiana komunikatów, a nie współdzielenie jednej bazy danych (wtedy realnie nadal byłby to monolit). Ta komunikacja to na powyższym diagramie szare linie z grotami. Integracje opisałem w artykule Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy. Dzisiaj skupie się tu na wyjaśnieniu jak komunikaty zastępują centralne współdzielone bazy danych.

Podstawowym elementem komunikacji są komunikaty. Z uwagi na to, że organizacja to system komunikujących się między sobą ludzi, ludzi z komputerami i komputerów między sobą, pojęcia “dokument” i “komunikat” należy uznać za tożsame, gdyż komunikacja człowiek-człowiek, niczym się nie różni od komunikacji człowiek-komputer czy kompoter-komputer .

Powyższy schemat to przykład współpracy kilku komponentów: każdy z nich wykonuje jakieś czynności, są one inicjowane otrzymanym komunikatem, wynik działania także jest przekazywany jako komunikat. Każdy z tych komponentów może przechowywać historie tych komunikatów (lokalne repozytorium komponentu). Takie komunikaty mogą zawierać różne treści, nie raz nadmiarowe z perspektywy jednego komponentu, ale zawsze spójne kontekstowo. Bardzo często w systemach występują komponenty, których celem jest kolekcjonowanie danych, a odbywa się to po prostu jako zbieranie określonych komunikatów (dokumentów).

Np. faktura to dokument/komunikat niosący dane o dokonanej transakcji. Jest on nośnikiem danych dla działu księgowości, dla klienta, na żądanie dla Urzędu Skarbowego, itp.. Mimo tego, że każdy z wymienionych korzysta tylko z części treści faktury, przekazywana jest zawsze cała faktura, bo to upraszcza cały system.

Kluczem jest zrozumienie tego, że komputery przetwarzają i wymieniają dane a ludzie przetwarzają i wymieniają informacje. Sztuką projektowania systemów informacyjnych jest dekompozycja problemu, projektowanie komunikatów (treści dokumentów) oraz zrozumienie i opisanie mechanizmów ich powstawiania i korzystania z nich. Potem pozostaje już tylko implementacja: zbudowanie systemu informatycznego (patrz: Architektura informacji, system informacyjny a system informatyczny w organizacji).

Powyższy diagram pokazuje także, że próba budowania architektury, w której kilka, kilkanaście wymienianych komunikatów miało by być zamienionych na jeden współdzielony stos wszystkich danych, będzie bardzo trudna do zbudowania i jeszcze trudniejsza do wprowadzania w niej zmian.

Podsumowując: każda organizacja i jej otoczenie to “system wymiany danych” a nie “system współdzielenia danych”. Dlatego świat od dawna odchodzi od monolitów na rzecz komunikujących sie komponentów (mikro-serwisy, mikro-aplikacje, komponenty). Budowanie wspólnego, centralnego modelu danych dla wielomodułowych systemów w zasadzie nigdy nie miało sensu ani szans powodzenia:

Dlaczego problemy pojawiają sie “dopiero później”, na początku było dobrze i klient był zadowolony

Paradoksalnie wyjaśnienie jest dość proste: u deweloperów nadal dominują metody oparte o monolityczne architektury. Głoszenie stosowania “obiektowych metod programowania” oznacza tylko tyle, że zastosowano tak zwany “obiektowo zorientowany język programowania”, co absolutnie nie oznacza, że architektura tego co powstanie będzie nowoczesna. Praktyka audytów pokazuje, że raczej będzie to skansen architektoniczny oparty o relacyjny model danych, wielopoziomowe dziedziczenie i najgorsze praktyki modelowania danych jakimi są anemiczny model dziedziny i płytkie płaskie klasy z ogromna liczbą operacji (w tym set/get dla każdego atrybutu klas reprezentujących tabele bazy danych, patrz artykuł: Ten straszny diagram klas).

Dlatego ten scenariusz często wygląda tak, że na początku powstaje oprogramowanie realizujące jedną określoną funkcję, to często zarodek monolitu. Wszystko ładnie działa, klient się cieszy, zawiera (przedłuża) umowę. Kolejne funkcjonalności to początek dramatu: rozbudowa monolitycznego modelu danych, migracje ze starego modelu do nowego, narastające problemy monolitycznej architektury: wszystko się sypie bo wszystko zależy od wszystkiego, i nie wiadomo jak, bo nie ma żadnej dokumentacji mechanizmu działania aplikacji, zaś kod od dawna nie nadaje się już czytania. Próba naprawy tego też zaczynam być gonieniem króliczka…. i jest spór.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Źródła