RegułyChaosu

W czasach, kiedy miałem coś wspólnego z zarządzaniem, w świecie projektów było takie powiedzenie: „szybko, tanio, dobrze – wybierz dwa”. Choć traktowane było jak anegdotka, w rzeczywistości było to (i jest nadal) bardzo, ale to bardzo prawdziwe. W świecie architektury są bardzo podobne dylematy, choć nie da się ich opisać aż tak prostym stwierdzeniem. Sposób kształtowania architektury musi nadążać za zmianami w otoczeniu, przyspieszeniem, złożonością, wykładniczym wzrostem ilości danych oraz rosnącymi oczekiwaniami „czynienia magii”, czyli dokonywania cyfrowych transformacji z użyciem BigData (już niemodne), blockchain (moda już przemija), AI/ML (na pewno pozostanie) i czego tam jeszcze trzeba użyć. Poniżej propozycje zmian w sposobie i otoczeniu kształtowania architektury pozwalających na radzenie sobie ze znaczącymi dylematami.

Biorąc pod uwagę prosty fakt, że współczesny świat technologią IT stoi, co do zasady umiemy (jako ludzkość, nie koniecznie każda organizacja) robić zwinnie całkiem spore „systemy informatyczne”. Ciągle jednak jest długo (i coraz dłużej) i drogo (i coraz drożej), a do tego z czasem (coraz krótszym) każdy, nawet najlepiej zrobiony system staje się ciężarem. Nie wszystko można zrzucić na marketing dostawców technologii IT i wciskanie kolejnej „wielkiej technologii rozwiązującej wszystkie problemy (znane i nieznane)”. Podstawowy problem musi więc polegać na czymś innym.

Elastyczność, to jedno z najczęściej spotykanych wymagań stawianych przed rozwiązaniami informatycznymi, wynikające z braku wiedzy o przyszłych potrzebach. Pomijając powody, dla których miejsce otwartej dyskusji o unknowns zajmuje amorficzne i efemeryczne wymaganie elastyczności, jakoś trzeba się z nim zmierzyć i pomóc – szczególnie tym wstydliwym lub zobowiązanym do „wszystkowiedzenia” – dać sobie z nim radę.

Realia współczesnego „robienia biznesu” nie dają komfortu podejmowania decyzji posiadając wszystkie dane. Podejmując decyzje biznesowe menedżerowie kierują się heurystykami i wyczuciem. Coraz częściej bowiem nawet suboptymalna decyzja podjęta we właściwym tempie okazuje się lepsza, niż super optymalna decyzja podjęta „chwilkę później”. Wszak chodzi o to, żeby nie wypaść oraz żeby nie popełniać dużych błędów. A jak w tej sytuacji podejmowane są decyzje architektoniczne?

Jak podpowiada doświadczenie w każdej z dziedzin działalności człowieka, także rozwój w IT jest procesem cyklicznym. Co pewien czas następuje przewartościowanie – terminy i praktyki uznawane za obowiązujące muszą ustąpić z pierwszych miejsc, przy czym ustępują często miejsca terminom i praktykom uznawanym przez jakiś wcześniejszy czas za co najmniej passé. Wygląda na to, że konfigurowanie sucks, kodowanie rocks!

Oczywiście, że ma, jak (prawie?) wszystko – a w naszej branży chyba wręcz „wypada, żeby miało”. Większość decyzji w IT podejmowana jest pod wpływem wyliczeń TCO. Byłem przez jakiś czas „w okolicy” szeregu takich decyzji. Upłynął jednak pewien czas, wystarczająco długi, aby pozwalał na wnioskowanie. No i coś poszło nie tak z tym TCO zwinności, bo nie wychodzi.

W każdej firmie, w której informatyka ma jakieś znaczenie, znajdzie się jakiś CRM, ERP czy BI. Są to systemy o wieloletniej historii, wdrażane według stabilnych i dobrze udokumentowanych metod, obrośnięte zasadami governance. Ich niewątpliwymi zaletami są zdolność do zapewnienia kompleksowego rozwiązania dla znaczącej – w wielkości i istotności – części działań biznesowych oraz gotowość do działania „od dnia zero”. Po kilku latach okazuje się jednak, że coraz częściej stają się przeszkodą.

Rok 2021 co prawda należy do Stanisława Lema, ale Janusz Zajdel też daje radę, if You know, what I mean. Lektura dzieł obu Panów zawsze wywoływała we mnie refleksje o naturze człowieka oraz o powiązaniach filozofii i technologii. Ostatnimi czasy – po części z powodu wątków chmurowych – filozofia i technologia splatały mi się w obszarze architektury mikroserwisów. No właśnie, ale czy to na pewno mikroserwisy? A może bardziej mikreserwisy?