Czego wymagać od architekta?

Data: 2018-03-15
Autor: Sebastian Konkol
Czego wymagać od architekta?

Naturalnie, mam na myśli architekta w sferze ICT, ale bardzo podoba mi się analogia z branż dojrzałych i stabilnych, np. budownictwa. Kiedy postanawiasz wybudować dom, nie ma wątpliwości, szukasz architekta, a nie „analityka”, „projektanta” czy developera. Każdy, kto budował dom lub wykańczał mieszkanie czuje dlaczego. To odczucie jest bardzo adekwatne także dla sfery ICT.

Budowa domu. Wizyta u architekta, który słucha, jaki ma być ten dom – nie w kategoriach technicznych, tylko użytkowych: ile ma mieć pokoi, jaki garaż, przyzwyczajenia rodzinne, prowadzony tryb życia. Później wysłuchuje różnych „mądrości”, których naczytali się przyszli inwestorzy i – delikatnie, acz merytorycznie – wyjaśnia, że to nie tak. Następnie architekt doradza charakter projektu domu, jaki odpowiada oczekiwaniom. Inwestorzy wybierają, architekt adaptuje. W ramach adaptacji konstruktor wprowadza konieczne do wprowadzenia zmiany w konstrukcji budynku. Całość projektu ląduje u developera, który stawia dom. Architekt w budownictwie ma kilka zadań. Na samym początku ma wskazać co ma sens, co jest możliwe, a co nie – ustalić kluczowe oczekiwania i wykluczyć sprzeczności. W tym celu nie zagłębia się w szczegóły techniczne np. przyłącza kanalizacji do domu – jego doświadczenie pozwala na przejście takich dyskusji. Później zapewnia spójność komunikacji ze wszystkimi stronami, których wkład wymagany jest do zamknięcia projektu domu – konstruktorzy, dostawcy przyłączy, czasami kierownik budowy. Inwestor w tym nie pośredniczy, bo się na tym nie zna – architekt rozumie specyfikę roli każdego z zaangażowanych podmiotów i komunikuje się z każdym z nich we właściwym języku, przekazując wymagane informacje. Na koniec architekt aktualizuje projekt techniczny budynku – opisuje jaki efekt ma być osiągnięty w wyniku budowy, a nie w jaki sposób developer ma ten budynek stawiać.

Wyobraźcie sobie teraz, jak wyglądałby ten proces, gdyby inwestor poszedł do developera z pominięciem architekta… Na szczęście w budownictwie taki absurd jest wykluczony na mocy prawa budowlanego – nie można zgłosić budowy, której nie potwierdził profesjonalny architekt.

W świecie IT nie obowiązują takie regulacje, co nie znaczy, że należy pozbyć się zdrowego rozsądku – podstawowe uwarunkowania początku procesu „od pomysłu do systemu” są takie same, jak w budownictwie. IT ma swoje osobliwości – skracanie czasu, konieczność dopasowywania się – co dodatkowo wzmacnia konieczność działań architektonicznych. Z perspektywy inwestora efektem działania architekta jest architektura, której inwestor nie rozumie (tak samo, jak nie rozumie konstrukcji podciągów w projekcie domu). Jednak ta najbardziej wartościowa praca wykonywana przez architekta na rzecz inwestora leży w innych sferach:

  • komunikacja pomiędzy interesariuszami przedsięwzięcia – architekt dostrzega powiązania realizowanego rozwiązania z innymi (czasami potencjał wsparcia, czasami problemy), prowadzi z nimi dyskusje i uzyskuje co najmniej wspólne zrozumienie zagadnień;
  • identyfikacja podstawowych decyzji konstrukcyjnych – architekt określa ramy rozwiązania, wskazuje podstawowe i krytyczne (wcale nie wszystkie!) ograniczenia i uwarunkowania wpływające na konstrukcję rozwiązania;
  • określa potencjał reużycia istniejących komponentów i potencjał reużycia realizowanego rozwiązania – architekt optymalizuje finansową stronę przedsięwzięcia, dbając o (także długoterminowe) interesy organizacji finansującej realizację rozwiązania.

Podstawowym zadaniem, jakie należy stawiać przed architektem, wcale nie jest „wytworzenie architektury” – podstawowym zadaniem architekta jest zbudować konsensus wokół roli funkcji systemu, systemu, grupy systemów lub całego środowiska pośród wszystkich zainteresowanych tym zagadnieniem. Rzecz jasna, zupełnie czym innym zainteresowani są użytkownicy, czym innym sponsorzy, a czym innym developerzy – na tyle czym innym, że rzeczy fundamentalne dla jednych są szczegółami technicznymi dla drugich. I na tym tle powstają konflikty, a zadaniem architekta jest te konflikty rozstrzygać – nierozwiązane wypłyną później, kiedy będzie znacznie trudniej (i znacznie kosztowniej) je rozwiązywać. Chowanie głowy w piasek i zarządzanie przez niedostrzeganie problemów nie pomaga – architekci powinni mieć uprawnienia do podejmowania takich decyzji.

Budowanie konsensusu w tak nasączonym wrogością i konfliktami środowisku pracy jak sfera IT jest samo w sobie poważnym wyzwaniem. Zadanie to dodatkowo utrudniają inne wzorce postępowania często obecne w przedsięwzięciach IT:

  • Dwie dekady temu ujawnili się architekci korporacyjni, którzy mieli ambicje pełnić tę samą rolę mediatorów pomiędzy różnymi jednostkami organizacyjnymi, także w dziedzinie organizacji pracy, przebiegu procesów biznesowych, modeli działania. Zamiast skupić się na tym czym jest EA (Enterprise Architecture), czyli zapewnieniu zgodności roli i działań technologii informatycznych w strategii firmy, zaczęli uczyć biznes robić biznes. To stało się gwoździem do trumny architektury korporacyjnej – i nadal „obrywa się” wszystkim architektom. Mimo, że w wielu przypadkach takich okoliczności miewam sporo do powiedzenia i poradzenia, to jednak rozstrzyganie konfliktów między „biznesami” nie leży w zakresie obowiązków architekta.
  • W sferze IT klienci „wiedzą lepiej” i nie mają oporów przed kontestowaniem opinii architekta (w sferze budowlanej nie do pomyślenia). W mojej praktyce dowodzenie, że nie jestem wielbłądem ma status Standard Operating Procedure.
  • Kierownicy projektów, nie tylko ci z „techniczni” w nazwie funkcji, mają potężne zapędy analityków i wielką łatwość podejmowania dyskusji (a nawet decyzji!) architektonicznych, często na podstawie menedżerskiego (czyt. powierzchownego, uproszczonego) zrozumienia zagadnienia. Już kilka razy musiałem wydobywać na powierzchnię projekt tonący pod ciężarem takich „menedżerskich decyzji” w sferze architektury.
  • Architektów najróżniejszych cała masa. Wszyscy „architekci Java”, „architekci infrastruktury”, „architekci bezpieczeństwa” to – z perspektywy informatyki – analogi konstruktora, czy projektantów „instalacji” w budownictwie. Nie budują konsensusu, nie godzą sprzeczności – wykonują jakąś specjalizowaną część projektu rozwiązania, ale tytuł architekta brzmi nobilitująco. Z mojego doświadczenia jedna obserwacja – kiedy dowolny z tych „projektantów” dociera do zagadnienia wymagającego ustalenia konsensusu pomiędzy interesariuszami, biegnie do jednego człowieka w strukturze przedsięwzięcia – to właśnie ta osoba jest architektem.

Ale to tylko okoliczności profesji architekta (tego prawdziwego), taka robota. Współczesne IT musi być szybkie i zwinne (a wymagania te rosną), ale w tym samym czasie współczesne IT jest znacznie bardziej złożone (tu także widać wykładniczy wzrost złożoności). W mojej opinii obietnice składane przez świat IT zasadzają się na tym, że w każdym przedsięwzięciu jest prawdziwy architekt – i ma on uprawnienia do działania w swojej roli. Co ciekawe, w niektórych obszarach pojawiają się prawne uwarunkowania prowadzenia działań w sferze rozwoju rozwiązań informatycznych, dotykające już roli i działań architektów. Wartość ich działań w sferze technologii jest bezdyskusyjna, ale najważniejsze pole ich działania to konsensus, a nie technologia. Dojrzałość branży nie zbuduje się jednak sama. Może więc czerpać garściami mądrość dojrzałych i stabilnych branż – jak budownictwo – i nadać właściwe uprawnienia, należny status i rolę architekta IT?

Pozostaw komentarz