Czy IT może się uczyć od… mrówek?

Data: 2013-03-07
Autor: Sebastian Konkol

Nie wiem, czy w związku ze zbliżającymi się moimi „inżynierskimi” urodzinami, czy z innego powodu, ale nachodzą mnie ostatnio refleksje na temat fundamentów współczesnej technologii teleinformatycznej. Dzisiaj jest o złożoności i heurystyce w systemach, a całość zaczęło się od… mrówek.

Już kilka lat temu, kiedy z wypiekami na policzkach oddawałem się studiowaniu analizy sieci społecznych, trafiłem na bardzo ciekawą koncepcję, jaką Steven Johnson opisał w swojej książce (“Emergence: The Connected Lives of Ants, Brains, Cities, and Software”, Steven Johnson, Touchstone, 2002, ISBN: 0684868768). Sprawa dotyczyła tego, jak na podstawie niewielu bardzo prostych reguł tworzone są złożone i stabilne „systemy” – a dokładniej nie tyle „są tworzone”, co „wyłaniają się”, bo ich powstawaniem nie kieruje żadna wyższa forma nadzoru. Za przykład, który najbardziej utkwił mi w pamięci, posłużył eksperyment „na mrówkach”. Nie wnikając w dowody wiarygodności wyników eksperymentu (był przeprowadzony bardzo naukowo, a wyniki są bezdyskusyjnie wiążące), przebiegał on z grubsza następująco. Jeśli w jednym, zamkniętym pomieszczeniu pozostawić kolonię mrówek (tu powinna paść łacińska nazwa tego gatunku mrówek, ale nigdy nie miałem takiego zacięcia do biologii), to zbudują one swoje „miasto” w taki sposób, że zawsze (podkreślam, zawsze) trzy istotne elementy tego miasta – kopiec, śmietnik i cmentarz – znajdować się będą w możliwie najbardziej odległych miejscach do siebie nawzajem. Nie ma wśród nich mierniczych, architektów, inżynierów – mrówki mają tylko zapachy i zdolność kierowania się nimi oraz domyślną „rolę społeczną”. Wystarczy więc, że mrówka o określonej roli (np. śmieciarz) będzie wędrowała, po drodze rozsiewając zapach swojej roli, tak daleko, aż nie będzie odczuwała (lub będzie on lokalnie najsłabszy) zapachu pozostawionego przez jakąkolwiek wcześniej wędrującą mrówkę. Tam zostawia śmiecie. Następna pójdzie nieco dalej (bo zapach jeszcze będzie) i w ten sposób, po pewnym czasie, śmietnik będzie zorganizowany najdalej, jak się da od innych „ścieżek zapachowych”.

Takich dowodów na wyłanianie się złożonych systemów pojawia się wiele, ale nie o przykłady chodzi – ważna jest mechanika: na podstawie takich dwóch czy trzech reguł i bardzo prostej sygnalizacji możliwe jest budowanie złożonych, stabilnych systemów, a kluczem do ich stabilności jest prostota. Im prostsze reguły, tym stabilniejszy system, a złożoność systemu nie wynika ze złożoności reguł. Dodając kolejne reguły nie uzyskuje się stabilności systemu – wzmacnia się jedynie jego heurystyczną naturę. Im więcej reguł i im bardziej są one złożone, tym bardziej nieprzewidywalnie (heurystycznie) działa system jako całość.

Współczesne ICT to właśnie wiele, złożonych reguł, wchodzących między sobą w bardzo złożone interakcje. Dzisiaj każdy system informatyczny czy telekomunikacyjny to gąszcz reguł, powiązanych między sobą równie złożonymi zależnościami. W efekcie daje to heurystyczne (czytaj: nieprzewidywalne) zachowania, mimo, że przecież każda z tych reguł i każda z interakcji jest doskonale deterministyczna. Od teorii złożoności i teorii chaosu nie ma ucieczki – nawet w tak hermetycznym, skodyfikowanym i metodycznym świecie, jak ICT.

Na tym tle popadłem ostatnio w zadumę, jak to ludzie sami sobie gotują ten los. Statystyczny użytkownik systemów informatycznych wymaga zwykle realizacji złożonych wymagań, a statystyczny inżynier IT za punkt honoru stawia sobie włączenie do projektu największej ilości modnych technologii. A powinno być – przynajmniej z punktu widzenia złożoności, chaosu i lekcji od mrówek – dokładnie odwrotnie. Każde zwiększenie złożoności systemu informatycznego oznacza zwiększenie heurystycznej jego natury, a odpowiedzialność za stabilność rozwiązania leży po obu stronach, zarówno wymagających jak i realizujących. Ostatecznie problem nieprzewidywalności – kiedy już wystąpi – będzie męczył zapewne obie strony.

Pozostaw komentarz