Architektura do remontu

Pamiętam dwa przynajmniej takie przypadki. Pierwszy - z opowiadania, drugi - z własnej praktyki.

O pierwszym opowiadał prowadzący na pierwszym w ogóle kursie analizy i projektowania systemów, na jakim byłem. A było to tak dawno, że dziwne wydaje się już samo to, że wtedy, i to w Polsce, już tego uczono.

Wspomniany prowadzący opowiadał o przypadku, jaki zdarzył się na tym kontynencie, gdzie chodzi się do góry nogami. Działał tam sobie, długo i bez problemów, system komputerowy (nie mówiło się jeszcze wtedy "informatyczny"), który na podstawie danych historycznych planował dostawy towarów do sklepów pewnej sieci. Sklepy były różne - od bardzo dużych, po takie wielkości kiosku. No i do takiego sklepiku wielkości kiosku zajechała pewnego dnia ciężarówka ze świeżym towarem. Była tak duża, że z łatwością pomieściłaby na sobie ze dwa takie sklepy, a przywiozła tam, nie mniej i nie więcej, tylko tonę mydła. Wszystko poszło na konto, a jakże, komputera, któremu po latach niezawodnego działania, nagle coś "odbiło".

Drugi przypadek, który chcę przedstawić, a który może w jakiś sposób wyjaśnić ten pierwszy, pochodzi sprzed lat co najmniej kilkunastu.

Tym razem do działającego całkiem nieźle systemu wprowadzono kolejne poprawki. W wyniku tego okazało się, że ta sama jego funkcja raz działa dobrze, a drugi raz źle. Po zbadaniu sprawy okazało się, że system ten liczył sobie już sporo lat i - jak to z systemami bywa - nie był najlepiej udokumentowany. I kiedyś kolejny nowy członek zespołu zajmującego się tym systemem, czy to nie sprawdził, czy też nie doczytał, w każdym razie napisał od nowa niewielki moduł, który już w systemie - w sensie pełnionej funkcji - był. Tak więc ta sama funkcja była realizowana odtąd przez dwa moduły, z których oba dawały identyczne wyniki, więc nic nikomu nie podpadło. I tak działały one, nie wiedząc nic o sobie, aż przyszła konieczność wprowadzenia zmiany do realizowanej przez nie funkcji. No i poprawiono ten nowszy, bo istnienia starszego nikt już nie pamiętał. Skutek był taki, że w zależności od tego, który z tych modułów był wywoływany do działania przez inne moduły, wynik był taki, albo inny.

Co łączy oba przytoczone przykłady? Ano to, że systemy informatyczne też się starzeją i - czego w ich przypadku nie widać - stają się czymś w rodzaju wielokrotnie remontowanego i przebudowywanego budynku. Rośnie w nich wielkość kodu programowego, który pozostaje nieczynny, ale jest starannie posplatany z tym jeszcze działającym. Nikt więc nie odważy się go tknąć, bo skutki mogą być podobne do tych po zburzeniu w starym budynku ściany, która wyglądała na działową, a okazała się nośną.

Po latach przypadłość taka, w wyniku nawarstwiających się zmian, dotyka najlepiej nawet zaprojektowane systemy. Rosnąca wielkość kodu programu, która jest jednym ze skutków takiego obrotu spraw, zwiększa jego zapotrzebowanie na pamięć operacyjną. Duże moduły z częściowo martwym kodem dłużej się przepisują z pamięci dyskowej do operacyjnej, a jałowe działania tego kodu beztrosko trwonią moc obliczeniową.

Powstaje więc pytanie: jak długo można remontować architekturę takiego dużego, działającego od lat systemu? I jak oszacować, że system taki, po iluś tam remontach, do kolejnego już się nie nadaje?

Sprawa jest co najmniej tak trudna, jak z decyzją, czy stary dom jeszcze raz remontować, czy też zburzyć i postawić w jego miejsce nowy (który kiedyś czekać będzie podobny los). Są tu dwa ważne kryteria: ryzyko i koszty. Bywają również próby angażowania w tym celu metod punktowej oceny "stanu zużycia" systemu informatycznego. W ogólności, kryterium kosztowe góruje w przypadku systemów niekrytycznych. Dla tych, od których niezakłóconego działania zależy np. bieżąca obsługa klientów, ważniejsze jest ryzyko, że ta obsługa będzie zakłócona albo wręcz zatrzyma się.

Można też uważać, że wszystko to powinno być wykryte podczas testowania. Ale trzeba przyznać, że rzadko poddaje się testom coś, co uważa się za oczywistą oczywistość.

Dr Bogdan Pilawski jest głównym specjalistą z zakresu strategii i architektury informatycznej w Banku Zachodnim WBK oraz wykładowcą akademickim.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200