Regularnie czytam blog Andrzeja Sobczaka, profesora SGH. Czasami bywa, że mam odmienne zdanie niż tam prezentowane, i tym razem też tak jest. Ostatni wpis na tym blogu zawiera siedmiopunktową prognozę na…
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju “ale ja chcę zobaczyć to wszystko na jednym diagramie” pchamy projekt w kierunku “utraty panowania nad złożonością”… To prosta droga do klęski projektu.
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ą.
Jak widać, z zupełnie z innej strony “odkryliśmy” coś co nazywamy architekturą korporacyjną. Skoro każda analiza wymagań w istniejącej organizacji, to każdorazowa analiza od poziomu motywacji biznesowej projektu, przez wymagane usługi aplikacyjne, integracje aż do platform sprzętowo-systemowych, to mamy nic innego, jak projekt dokumentowania architektury korporacyjnej. I na koniec bardzo ważna moja uwaga: za jakość wymagań odpowiada i ponosi konsekwencje w 100% kupujący, nigdy dostawca!
obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy “świata” i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie – obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).
Od dłuższego czasu nurtuje mnie czym kierują się ludzie zawierający umowy na zakup pełnych i zintegrowanych pakietów ERP mimo, że statystyki pokazują, że to z reguły nie ma żadnego sensu. Praktycznie wszystkie te wdrożenia są po zakończeniu znacznie droższe niż pierwotne oferty, trwają dłużej niż obiecano, nie mała część kończy się fiaskiem i nawet kompletną rezygnacją i odinstalowaniem (bywam w tych firmach i widzę od środka różnicę pomiędzy tym co piszą w gazetach dostawcy w swoich referencjach a tym co faktycznie miało miejsce).
Jednym z największych błędów popełnianych w projektach związanych z modelowaniem procesów biznesowych jest zapominanie o tym, że model procesu to model organizacji a nie tylko dokument, i o tym, że pomiędzy procesami a procedurami, umiejętnościami, instrukcjami obsługi narzędzi, jest granica. To się nazywa utrata panowania nad złożonością projektu. Kolejny problem to powszechne traktowanie notacji (np. BPMN) jako biblioteki symboli, co jest kluczowym błędem: notacja to model pojęciowy – podstawowe narzędzie analizy i modelowania.
Tak więc AK jest to ktoś, kto rozumie całość ale nie musi (nawet nie powinien) być tym, kto ją implementuje, gdyż tu także ważne jest rozdzielenie roli projektującego od wdrażającego. Role te mają nie raz sprzeczne interesy: im głębiej w szczegółach tkwi dana rola (np. developer) tym bardziej w jej interesie leży utrzymanie status quo, mniejszą ma skłonność do wprowadzania zmian.
