Architektoniczne „lub czasopisma”

Data: 2021-09-22
Autor: Sebastian Konkol
Architektoniczne „lub czasopisma”

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ę.

Na swoje potrzeby identyfikuję kilka źródeł wymagań elastyczności. Najbardziej oczywistym jest nieokreśloność i zmienność otoczenia biznesowego, które wywiera potężny wpływ na to, co robimy i do robienia czego powinniśmy być gotowi w przyszłości. Każde przedsięwzięcie korzysta, kiedy o takich elementach rozmawia się otwarcie, żeby dać szanse architektowi skonkretyzować elastyczność w takim przypadku. Innym źródłem takich nieokreśloności jest, nie bójmy się tego powiedzieć, lenistwo i niechęć do wzięcia odpowiedzialności. W wielu przypadkach daje się ustalić znacznie więcej, o ile tylko da się otwarcie rozmawiać – zagadnienia skutkujące „elastycznością” często okazują się częściowo możliwe do głębszego zrozumienia, a częściowo wynikające z otoczenia. Tu kluczem do sukcesu jest otwartość.

Trzecim źródłem tej elastyczności, któremu chciałbym poświęcić więcej uwagi, to temat tzw. ASRów, Architecturally Significant Requirements, czyli takich wymagań, których zmiany skutkować mogą zmianami w architekturze. W ramach działań edukacyjnych takie wymagania nazywam często „lub czasopisma”, bo zadziwiająco często skutkują one bardzo analogicznymi zdarzeniami i mają bardzo analogiczną „silę rażenia”. Dla przykładu ewolucja sformułowania wymagania dotyczącego przeszukiwania danych. Wersja oryginalna – „dane klientów mają być przeszukiwalne” – w umyśle architekta skutkują prostą, absolutnie standardową w każdym szanującym się frameworku formatką do wyboru kryteriów wyszukiwania obiektów danego typu, w tym przypadku klientów. Może być wybór z listy rodzajów klienta, przedział dat aktywacji, jakaś część imienia czy nazwiska lub adresu e-mail, nawet z wildcards. Zadanie dla developera, testy funkcjonalne, wdrożenie. Wersja po ewolucji – „dane klientów mają być przeszukiwalne (pełnotekstowo)”, dokładnie tak, w nawiasie – w każdym świadomym architekcie wskazują na konieczność wprowadzenia silnika indeksowania, obsługi fleksji języka i integracji całości. Zadania dla znaczenie większego zespołu, nie mówiąc już o kosztach czy czasie realizacji. Żeby nie było wątpliwości, w żaden sposób nie kwestionuję zasadności takiego wymagania. Co więcej, cieszę się, że w tym konkretnym przypadku o to dopytałem, bo decyzje o rozwiązaniu były zdecydowanie bardziej świadome. Kluczowym doświadczeniem, jakie należy wysnuć jest to, że pytania architekta, zadawane odpowiednio wcześnie i dyskutowane z należytą otwartością, dają projektom szanse na zwiększenie skuteczności, zarówno podniesienia dostarczanej wartości, obniżenia kosztów, jak i redukcji ryzyka. ASRów nie widać jednak „na pierwszy rzut oka”, wymagania nie są magicznie w ten sposób sklasyfikowane. Architekci je dostrzegają, bo widzą świat inaczej i to jest ich wielka wartość.

W mojej praktyce bycia architektem dochodzę do wniosku, że bardzo łatwo sobie poradzić z tym wszystkim, co mierzymy i czego potrafimy dowodzić. Znacznie trudniej poradzić sobie z tym, co wynika z doświadczenia, a czego emanacją jest intuicja. Ja wyrobiłem w sobie taką właśnie zdolność, zdolność intuicji architektonicznej, pozwalającą mi dostrzegać ASRy, czy inne zagadnienia, które „czuję w kościach, że mogą sprawiać problemy”. Jak stacja meteorologiczna, czy sejsmograficzna, potrafię dostrzec zagrożenia na chwilę przed ich materializacją, choć może nie potrafię z matematyczną precyzją i prostotą slajdu PowerPoint „udowodnić” swoich racji. To bez wątpienia wartościowa zdolność, choć trzeba odejść od PowerPointowych stereotypów, żeby móc z niej w pełni skorzystać.

Pozostaw komentarz