(źr. COMPUTERWORLD 7/2014) Tym razem króciutki wpis. Pragnę polecić numer 7/2014 COMPUTERWORLD a w nim (głównie, cały numer warto poznać ;)). Numer ten zawiera bardzo wartościowy artykuł "Pięć typowych błędów w umowach wdrożeniowych" Pana Marcina Maruty (Kancelaria Radców Prawnych Maruta i Wspólnicy). Pan Maruta wskazuje, jako kluczową przyczynę wielu problemów z wdrożeniami (a konkretnie z kontraktami na ich realizację) jest źle sformułowany, a nie raz po prostu brak, przedmiot umowy. Przyznam, że banan przy moim uśmiechu na twarzy to pikuś, jak pomyślałem, co myślą zwolennicy "zwinnych metod" czytając to (cytat…
Autonomiczne, duże systemy ERP? Nie wróżę im kariery, w obecnej postaci mega-aplikacje umrą, odwlekanie tej śmierci z pomocą perswazyjnych reklam i kampanii dużych korporacji i ich sprzedawców, to tylko sztuczne przedłużanie życia inwestycji w duże ERP, przez producentów tych rozwiązań, dawanie sobie czasu na (mam nadzieję) ich refaktoring. Mamy np. takie kolosy jak Google czy Amazon, które pokazują, że chmurowe, wysoce skalowalne architektury zasobowe mają sens. Systemy ERP oparte na relacyjnych bazach danych i ich wewnętrzna integracja poprzez współdzielenie danych, nie mają nawet szansy z tego skorzystać.
Na zakończenie mogę powiedzieć, że dokładnie takie same błędy widzę w projektach informatycznych. Wymagania są definiowane jako dziesiątki i setki "spotkanych w życiu przykładów i doświadczeń". Lista wymagań, powstała jako efekt wywiadów, prototypów, sesji burz mózgów, bardzo często wygląda jak taki właśnie okręt, którego poszycie składa się w 100% z chaotycznie przybitych łat. To jak by wymagania na okręt spisywali marynarze, kierując się najlepszą swoją wiedzą z rejsów, które odbyli, dodatkowo lobbujący - każdy z nich - na rzecz swojej kajuty i wyposażenia.
Wprowadzenie Ostatnio napisałem dwa artykuły: o architekturze i o integracji. Pewnym ich podsumowaniem będzie dzisiejsza recenzja książki Jeff Garland i Richard Anthony . Kilka sugestii zawartych w książce. Jedną z kluczowych jest zbyt szybkie "ładowanie się" w szczegóły, w toku analizy od ogółu do szczegółu jako pierwszy powstaje model kontekstowy, powstaje z użyciem diagramu przypadków użycia. Bardzo często na tym etapie tworzone są w projektach bardzo szczegółowe diagramy z dziesiątkami przypadków użycia, praca z taka ilością szczegółów niszczy skuteczność pracy na tym poziomie. Przypadki użycia na etapie analizy kontekstu mają…
Integracja to jeden z trudniejszych problemów. Wymaga bowiem nie tylko specyfikowania (i potem ich implementowania) interfejsów, ale także analizy i opracowania bezpiecznej architektury całego systemu (tu znowu architektura korporacyjna). Wiele firm ma, nie dwie ale kilka, kilkanaście a niektóre nawet setki aplikacji. Jeżeli będę ze sobą "pospawane" wywołaniami SQL/ODBC, to ruszenie "tego" praktycznie zawsze kończy się krachem (czytaj ogromne koszty przywrócenia funkcjonowania całości). Brak przemyślanej architektury, integracja ad-hoc "każdy z każdym", to prosta droga do kłopotów i ogromnych kosztów utrzymania całości. Stosowanie API (ich tworzenie) nieco tylko podnosi koszty wdrożenia, za to chroni przed bardzo dużymi, nieplanowanymi, wydatkami w przyszłości.
Jak wspomniałem, wielu dostawców oprogramowania jak Rejtan, broni się przed ujawnianiem architektury, swoich produktów. Głównym powodem jest zapobieganie przedwczesnego wyjawienia opisanych wyżej wad systemów z grubym klientem (znacznie rzadziej spektakularny pomysł, w końcu mamy jednak jakieś standardy). Przypadki, w których zakup systemu był relatywnie niski ale koszt utrzymania, rozwoju i dostosowania nie raz wręcz ogromny, to z reguły właśnie zakup systemu w tej kosztownej architekturze.
Jak starać się tego unikać? Na etapie definiowania wymagań poza-funkcjonalnych, żądać takich cech jak opisane powyżej czyli własnie: dostęp do całości przez przeglądarkę WWW, niskie wymagania na łącza przy zdalnej pracy i pracy w sieci rozproszonej terytorialnie, oddzielenie komponentu z własną dedykowaną logiką biznesową.
