🚀 go-pugleaf

Interesuje mnie zagadnienie znalezienia dobrej analogii między konstrukcją 
systemu informatycznego
a konstrukcją jakiegoś złożonego bytu, np. architektonicznego (wysokościowca 
? wiaduktu w miejscu przecięcia
się dwóch autostrad ?).

Generalnie chodzi o to, by przy dyskusjach na temat budowy takiego systemu, 
jego rozbudowy czy bardziej
wprowadzania zmian, móc się posługiwać jakimś w miarę wyrazistym modelem, 
który pobudza wyobraźnię przestrzenną,
posługuje się w miarę znanymi pojęciami ze świata rzeczywistego, dzięki 
czemu złożoność takiej konstrukcji jest łatwiejsza
do ogarnięcia dla zespołu ludzi, którzy mają przy takim systemie grzebać i 
przewidywać konsekwencje swoich działań,
a mają na dzień dzisiejszy bardzo różne kwalifikacje i perspektywy widzenia 
tego systemu.

Generalnie chodzi o to, by taki model pomógł wypracować kierunki prac przy 
przebudowie starego, dużego systemu opartego
o pliki dbf na bazę relacyjną. Stary system jest słabo zmodularyzowany, ma 
słabo zarysowaną logikę biznesową - wszystko
wbudowane w interfejs użytkownika (fox pro), komunikuje się z wieloma innymi 
systemami za pośrednictwem różnych technik
integracji, głównie 'file transfer'. Od modernizacji oczekuje się spełnienia 
dwóch podstawowych celów:
 - system ma zostać przeniesiony na relacyjną bazę danych (bezpieczeństwo 
danych i inne)
 - system ma uzyskać architekturę umożliwiającą jego rozwój (kontrolowane, 
bezpieczne spełnianie żądań zmian - zapanować
nad powiązaniami w systemie)

Jest wiele koncepcji, które kładą podstawy pod to przedsięwzięcie, ale są 
dość radykalnie różne. Model miałby posłużyć
wstępnemu testowaniu "na papierze", "w czasie burzy mózgu" tych koncepcji. 
Pojawiają się np. takie pytania, jak:
 - czy/jak budować interfejsy wewnętrzne i precyzyjnie rozdzielić 
odpowiedzialności za dane pomiędzy elementy systemu
(silna modularyzacja także na poziomie bazy danych).
- czy pozostawać przy jednej, centralnej bazie danych - w sensie jednej 
struktury danych, czy dzielić ją na kawałki. Jeśli to drugie, to czy budować 
złożony system replikacji między tymi bazami, czy budować system usług, czy 
wydzielać osobno bazę danych raportową zbierającą dane i oddzielić raporty 
od pierwotnego systemu
- czy dażyć do architektury silnie warstwowej, z wyraziście zarysowanymi 
usługami i możliwie silnie oddzielonym interfejsem
- czy zachowywać jednolitość technologiczną komponentów systemu (czyli 
pozostać przy fox pro powoli wbudowując go w .NET)
- jak podzielić przedsięwzięcie na małe kawałki - projekty, gdzie każdy z 
nich przechodziłby przez pełen cykl życia oprogramowania
(powiedzmy od analizy poprzez projekt, implementację, testowanie aż do 
wdrożenia i utrzymania)
- jak zrównoleglić prace - by wiele projektów pracujących nad różnymi 
kawałkami systemu mogło biec równocześnie, możliwie niezależnie
- na jakiego typu decyzje strategiczne należy się już teraz przygotować

Generalnie klarują się dwa ogólne obozy ;)
- centraliści - jak najdłużej utrzymać jedną, spójną bazę danych i w 
pierwszej kolejności spróbować wymienić bazę na relacyjną, nawet jeśli
oznacza to grzebanie w bardzo słabo uporządkowanym i opisanym kodzie. Siłą 
tego obozu jest teza, że taką zmianę można w dużym stopniu
wykonać automatycznie i zajmie to stosunkowo mało czasu.
- usługowcy - zbudować model wielu technologii i baz danych. Siłą tego obozu 
jest teza, że tylko takie podejście pozwoli na stopniowe
przenoszenie systemu i w ten sposób kontrolę przedsięwzięcia jako takiego, a 
jednocześnie bardzo szybko daje podstawy pod
rozbudowę systemu w oparciu o nowsze technologie, bez oczekiwania, aż całe 
przedsięwzięcie sięskończy.

Jednocześnie usługowcy radykalnie krytykują wizję półautomatycznego 
przerabiania kodu fox pro na bazę relacyjną (poprzedni system jest w dbf)
bez wcześniejszego uporządkowania logiki - twierdzą, że to niewykonalne lub 
co najmniej bardzo trudne w oszacowaniu - zarówno kosztów jak
i ryzyka niepowodzenia. Trudne także z punktu widzenia zarządzalności - 
trudno to podzielić na etapy zakończone wdrożeniem u klienta.

Centraliści zaś krytykę opierają na tezie, że modularyzacja jest bardzo 
kosztowna, także w utrzymaniu, w szczególności wskazują na złożoność
systemów replikacji danych między powstałymi podsystemikami.

Macie jakieś pomysły, jak wybrnąć z tej sytuacji ? :)))

(kupić inny system, sparametryzować i zmigrować ...) ;)