Co jakiś czas ktoś zadaje mi pytanie: czym właściwie zajmuje się w pracy? Pomyślałem więc, że wartościowe będzie opisanie tutaj, czym właściwie zajmuje się architekt IT.
Często ta rola kojarzona jest z dość zamkniętym kręgiem wszystkowiedzących osób, które za zamkniętymi drzwiami podejmują wszystkie “ważne” decyzje w projekcie. Znam też historie architektów, którzy autorytarnie podejmowali decyzje, które nie zawsze wychodziły na zdrowie zespołowi. 
Myślę, że pojęcie architekta jest dość pojemne i każdy może o tej funkcji myśleć w inny sposób. Postaram Ci się jednak przybliżyć mój sposób widzenia.
Rola architekta oznacza pracę na pograniczu. To bycie łącznikiem pomiędzy światem technicznym a nietechnicznym. Pomiędzy deweloperami, a różnymi mniej technicznymi osobami.
Rolę architekta widzę przede wszystkim w 3 funkcjach:

• strategicznego planowania, którego celem jest planowanie i prowadzenie dużych przedsięwzięć w stylu migracji infrastruktury firmy na chmurę;
• taktycznej pomocy, czyli pewnego rodzaju ojcowskiego nadzoru zgodności z firmowymi zasadami oraz badania jak ulepszyć sposoby pracy zespołów. Zarówno poprzez budowanie wspólnych komponentów w systemie, jak i dbanie o jakość jego wymagań niefunkcjonalnych (jak bezpieczeństwo, wydajność);
• codziennej współpracy, czyli pomocy w rozwiązywaniu bieżących problemów zespołów deweloperskich. Zarówno problemów technicznych jak i związanych z organizacją pracy. 

Jak widać są to dość ogólnie zdefiniowane zadania. Tak rzeczywiście jest, ponieważ dość trudno to określić precyzyjniej. Zakres pracy jest dość szeroki. Wynika to zresztą z tego, że architekt współpracuje z wieloma różnymi rolami:

• deweloperami – to akurat dość oczywiste, ponieważ pomysły architektów często są wykonywane właśnie przez deweloperów lub mają za zadanie im pomóc;
• team leadami – aby sprawnie koordynować prace nad wdrożeniami innowacji technologicznych;
• analitykami – aby znać wymagania biznesowe i być w stanie budować architekturę ściśle odpowiadającą na potrzeby biznesu;
• project managerami – aby być w stanie prowadzić (a raczej rozpoczynać i monitorować) długoterminowe strategiczne projekty techniczne;
• biznesem – aby móc z nim dialog na temat technicznych rozwiązań i rekomendować te najlepiej pasujące do potrzeb organizacji. 

Wymieniłem sporo osób zainteresowanych pracą architektów, jednak jestem pewien, że nie jest to kompletna lista. Architekt ze względu na swoją szeroką wiedzę (oraz głęboką w niektórych tematach) jest osobą wartościową głównie ze względu na swoje doświadczenie i umiejętność sprawnego rozwiązywania problemów.
Oczywiście są różne typy osób, a jednocześnie różne typy architektów. Każdy ma swoje preferencje. Niektórzy wolą być bliżej biznesu, niektórzy bliżej deweloperów. Jednak wspólnym mianownikiem dla każdego jest to, że finalne rozwiązanie powinno wnosić wartość dla możliwie jak największej liczby interesantów wymienionych powyżej. Niezależnie od osobistych preferencji, większość decyzji na poziomie architektury ma mniej lub bardziej bezpośrednio wpływ na prace wymienionych wyżej ról. Tym bardziej warto pamiętać  o regule win-win, podczas dyskusji i projektowania.
Osobiście wyznaję też zasadę, że nikt nie jest nieomylny. Architekt nie jest tutaj wyjątkiem. Dlatego tak ważne jest podejmowanie decyzji wspólnie z interesantami, aby poznać inne spojrzenia na problem i postarać się je lepiej zrozumieć.