Jakiś czas temu pisałem o architekturze i dobrych praktykach, a nie raz wręcz o zasadach budowy architektury, jedną z kluczowych jest “[[open close pryncypia]]” (część zasad [[tworzenia oprogramowania obiektowego SOLID]]). Zasada ta mówi, że dobra architektura jest otwarta na rozszerzenia i zamknięta na zmiany. Można się z ta zasadą bardzo często spotkać w literaturze dotyczącej architektury systemów, i nie chodzi tu o to, że o prawdzie decyduje to, jak często ją powtarzamy, a o to, że jest masa przykładów na to, że jest to możliwe (rozszerzenia bez wprowadzania zmian), że jest przydatne o czym świadczą najniższe koszty cyklu życia systemów o takiej właśnie architekturze.
Aż tu czytam sobie “niusy” z internetu i trafiam na artykuł:
Upgrade oprogramowania to projekt co najmniej równie skomplikowany co instalacja bazowa. […] (Źródło: Cechy dobrego menedżera ds. upgrade’u oprogramowania – Portal Wiedzy Menedżerskiej)
W tym momencie, osobom które chcą choć pobieżnie poznać zasady tworzenia “dobrej architektury” polecam wpis o grze w szachy.
Jeżeli upgrade oprogramowania ma być rewolucją co najmniej tak wielką, lub nawet większą, jak pierwotne wdrożenie tego oprogramowania, to ja głęboko współczuję nabywcom tego oprogramowania. Czytałem ten artykuł i z każdym kolejnym akapitem moje zdumienie rosło: jak można z patologii robić dobre praktyki…
Upgrade, cóż to jest” Słownik języka polskiego:
upgrade [wym. apgrejd] ?uaktualnienie oprogramowania komputera lub jego systemu operacyjnego?
w języku angielskim słowo upgrade oznacza uaktualnienie, unowocześnienie, rozszerzenie (źr. bab.la). Jedną z kluczowych cech dobrej architektury jest kompatybilność wstecz. Wdrażanie to (s.j.p.) to wprowadzać coś nowego do użytku, zacząć stosować coś w praktyce. Jedno jest pewne: nie jest to wymiana.
Jeżeli więc ktoś “funduje Państwu” upgrade jako “projekt co najmniej równie skomplikowany co instalacja bazowa” to znaczy, że to oprogramowanie, lub sposób jego wdrożenia, połamało wszelkie dobre praktyki wdrażania oprogramowania i budowania jego architektury.
Można się spotkać w przypadku upgrade z pojęciem długu technologicznego (czytaj artykuł o długu technologicznym) ale to także wieloletnie zaniedbanie ze strony producenta oprogramowania…
Dług technologiczny może być także konsekwencją wieloletnich zaniedbań ze strony posiadacza (nabywcy) oprogramowania.
To prawda, to jednak typowe grzechy zaniechania. I faktycznie nie zwróciłem tu na to uwagi. U producenta długiem technologicznym jest utrzymywanie starej nieefektywnej architektury i korzystanie z przestarzałej technologii. W takich właśnie przypadkach upgrade bywa rewolucją, nie zmienia to faktu, że wydanie nowej wersji systemy kompletnie niekompatybilnej wstecz jest raczej dziwnym podejściem.
Znam firmy, które specjalnie nie inwestują w architekturę umożliwiającą płynny upgrade. Po prostu kasują dodatkowo klienta za każdą aktualizację. Ktoś musi pojechać do klienta, “poprzepychać” skrypty itp. Interes się kręci. Są to jednak przeważnie dość duże i kosztowne systemy.
Czasy się zmieniają, upowszechnia się cloud-computing i wydaje mi się, że dostawcy oprogramowania będą musieli spłacić zaciągnięty dług technologiczny.
Na przykładzie jednego z naszych produktów przekonaliśmy się, że celując w “długi ogon”, czyli bardzo wielu klientów będących w stanie zapłacić za usługę stosunkowo niewiele ( rzędu kilkuset złotych – , trzeba bardzo dobrze zaprojektować architekturę rozwiązania, aby kolejne wdrożenia i aktualizacje przechodziły bezproblemowo, a nawet automatycznie.
Myślę, że to jest korzystne pole walki dla małych firm konkurujących z dużymi korporacjami, gdzie bez konsultanta / wdrożeniowca / programisty (100 PLN/h i w górę) ani rusz.
Myślę, że jest to pole walki do mniejszych firm mających ambicje nie mieć żadnych długów technologicznych. W dobie narastającej trendu zawierania umów “fixed price” pojęcie stawki godzinowej spada na drugi, nawet trzeci plan, zaczyna grać ogromną rolę budżet na cały projekt – zamknięty budżet i zakres.