Konformizm w projektach

Na koniec największy mit: analiza jest prosta, wystarczy wiedzieć jak ją wykonać i mieć właściwe wzorce dokumentów. Nic tej tezy nie potwierdza, a tak wielu próbuje… Znam masę przypadków, gdy ktoś uznał, że przyuczona grupa pracowników sama wykona analizę wymagań, w końcu to tylko spisywanie potzreb. Niestety nie znam żadnego przypadku gdzie, na bazie tak spisanych wymagań, projekt zakończył się sukcesem. Jest zresztą prosty sposób na ocenę jakości dokumentu opisującego wymagania: skonfrontowanie go z tym co w końcu powstało.

Czytaj dalej Konformizm w projektach

Zintegrowany ERP: postęp czy cofanie?

Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże “zabetonowanie” architektury biznesowej firmy.

Czytaj dalej Zintegrowany ERP: postęp czy cofanie?

Skomplikowana sieć aplikacji to kula u nogi działów IT

Tak na prawdę integracja taka polega nie na samym zainstalowaniu ESB i “podłączeniu” komponentów, to samo z siebie nic nie wnosi i nie jest łatwe. Integracja z użyciem ESB, to po pierwsze stworzenie (lub użycie jeżeli istnieje) dla każdego komponentu odpowiedniego adaptera i API, po drugie zaprojektowanie schematu komunikacji.

Czytaj dalej Skomplikowana sieć aplikacji to kula u nogi działów IT

CHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług

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ć.

Czytaj dalej CHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług

O sieciach handlowych i stanowieniu prawa

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.

Czytaj dalej O sieciach handlowych i stanowieniu prawa

Architektura korporacyjna w administracji

Legalny, niestety, lobbing (lobbing: wywieranie wpływu na organy władzy państwowej w interesie określonych grup politycznych, gospodarczych lub społecznych; źr. sł. j. polskiego PWN) to nic innego jak manipulacja urzędnikami, wpływaniem na treść ustaw. Lobbyści producentów i dostawców technologii będą czynili starania, by w prawie znalazła się technologia, bo tak korporacje “tworzą rynek” na swoje produkty. Dobre prawo powinno być jednak zbiorem reguł a nie zbiorem rozwiązań. Te ostatnie powinny być przedmiotem analiz i projektów inżynierskich a nie prawem, jak widać np. po ustawie o podpisie elektronicznym, bardzo ułomnym.

Czytaj dalej Architektura korporacyjna w administracji

Inżynieria wymagań

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!

Czytaj dalej Inżynieria wymagań