Architektura Rozwiązań vs. Architektura Korporacyjna

Architektura_IT

Intuicyjnie każdy wie lub czuje, czym jest architektura oraz czym zajmuje się architekt. Jeśli ktoś potrzebuje bardziej formalnej definicji, bez trudu znajdzie ją w literaturze fachowej lub internecie. Jednak od jakiegoś czasu słowa „architektura” i „architekt” nie kojarzą się wyłącznie z budownictwem. Nie powinno to specjalnie dziwić, bo wyobraźnia przestrzenna – konieczna w zawodzie architekta – stała się niezbędna również w innych dziedzinach. Jedną z nich jest IT – i to zarówno w sferze oprogramowania, jak i sprzętu.

O ile łatwo sobie uzmysłowić, czym zajmuje się architekt odpowiedzialny za budowę komputera, o tyle trudniej jednoznacznie określić zakres kompetencji Architekta Oprogramowania. Temat jest istotny tym bardziej, że o takie stanowisko stara się wielu specjalistów IT, sądząc, że jest to pozycja prestiżowa i dobrze płatna.

Typowa ścieżka kariery specjalisty IT zajmującego się programowaniem zaczyna się od Programisty. Z czasem można awansować na Projektanta, by w końcu stać się Architektem. Pomijam przymiotniki Starszy/Młodszy, które nieco tę ścieżkę wydłużają. Generalnie absolwent kierunków technicznych kończący studia w wieku 25 lat mniej więcej po 30-stce, a przed 40-stką może zostać Architektem. Przeważnie zostaje Architektem Rozwiązania/Systemu/Oprogramowania. Oczywiście istnieje znacznie więcej rodzajów architektów, np. Architekt IT, Biznesowy, Integracji, Infrastruktury, Segmentu, Bezpieczeństwa, Korporacyjny itd. Warto przy tym pamiętać, że im więcej architektów w organizacji, tym prestiż każdego z nich jest niestety mniejszy…

Analizując obecne na rynku ogłoszenia o pracę, widać, że Architekt Rozwiązań to przeważnie osoba, która współpracuje z analitykami oraz projektantami nad wymaganiami i ich realizacją, określa standardy projektowania komponentów, dba o spójność oraz wydajność rozwiązania, dobiera technologie do problemu. Innymi słowy, żeby podołać takiej funkcji, trzeba mieć wieloletnie doświadczenie nabyte przy projektowaniu i budowaniu rozwiązań – najlepiej w kilku technologiach, znać różnorodne wzorce projektowe, języki modelowania (zazwyczaj UML), metodyki wytwarzania oprogramowania (np. SCRUM). Dodatkowo trzeba biegle znać język angielski, umieć przekazywać wiedzę innym, pracować w zespole, być komunikatywnym, elastycznym, samodzielnym i oczywiście odpowiednio zaangażowanym.

Nie chcę pisać o wszystkich rodzajach architektów oraz różnicach między nimi – zazwyczaj same nazwy wskazują najistotniejsze z nich. Poza tym, mogę nie mieć tak szerokich kompetencji – nigdy nie pracowałem w dziale HR… Chciałbym napisać natomiast o relacjach między Architektem Rozwiązania a innymi Architektami wymienianymi przez metodyki zarządzania architekturą korporacyjną, a dokładnie te, budowane na podstawie ram architektonicznych TOGAF (The Open Group Architecture Framework). TOGAF zakłada istnienie czterech domen architektonicznych: biznesowej, aplikacji, danych oraz technicznej. Każdej z nich odpowiadają Architekci, których prace koordynuje Architekt Korporacyjny.

Architekci Rozwiązań z reguły działają w ramach konkretnych projektów. Dla każdego z nich muszą  zaprojektować optymalne rozwiązania, a co za tym idzie, oprócz czystości architektonicznej muszą uwzględniać również inne ograniczenia związane na przykład z budżetem, zasobami czy terminem realizacji. Tak konstruowane rozwiązanie może nie być optymalne z punktu widzenia całej Strategii IT organizacji. Najczęściej biznes oczekuje szybkiego i taniego rozwiązania bieżących problemów, co w praktyce przekłada się na szereg rozwiązań powiązanych ze sobą w chaotyczny sposób. Bardzo trudno jest przekonać inwestora, że zwiększenie nakładów na rzecz wzrostu elastyczności i reużywalności komponentów, z których może składać się rozwiązanie, sprawi że w przyszłości nakłady na integrację oraz dostosowania środowiska IT do często zmieniających się wymagań biznesowych będą znacznie mniejsze.

Architekt Korporacyjny i jego zespół pracują nad tym, by rozwijane aplikacje w możliwie najlepszy sposób realizowały potrzeby biznesowe organizacji oraz by były tworzone zgodnie z określonymi standardami architektonicznymi. Architekt Biznesowy odpowiada za organizację biznesu oraz kluczowych procesów biznesowych tak, aby można było realizować przyjęte cele strategiczne. Za to, w jaki sposób systemy informatyczne wspomagają realizację celów biznesowych, odpowiada Architektura Systemów Informatycznych, czyli Architekci Aplikacji oraz Danych. Wreszcie na pytanie o to, w jaki sposób infrastruktura wpisuje się w realizację tych potrzeb, odpowiada Architekt Techniczny. W takiej organizacji Architekt Rozwiązania zależy zatem nie tylko od Kierownika Projektu, ale również – a może nawet przede wszystkim – wypracowane rozwiązanie musi wpisywać się w ogólną strategię, na straży której stoi Architekt Korporacyjny.

Co ciekawe, według TOGAF Architekt Korporacyjny nie powinien być związany z działem IT organizacji. Wymagania związane z tym stanowiskiem różnią się od oczekiwań wobec np. Architekta IT. Jedną z najważniejszych cech dobrego Architekta Korporacyjnego jest zdolność do skutecznego komunikowania się. Nic dziwnego, skoro większość jego czasu pracy wypełnia komunikowanie swoich racji. Architekt Korporacyjny to lider i sprzedawca, dysponujący wiedzą biznesową i techniczną.

Jak łatwo przewidzieć, tarcia pomiędzy projektami a zespołem architektonicznym nie należą do rzadkości. Przy założeniu, że organizacja oraz liczba wspierających ich aplikacji nie są duże, do kompromisów można dochodzić stosunkowo łatwo i niewielkim kosztem. Jednak w sytuacji, gdy organizacja gwałtownie się rozrasta – czy to w zakresie nowych usług i produktów czy w sensie terytorialnym, wchłaniając inne jednostki o podobnym profilu – zapanowania nad „dzikim” rozrostem IT jest kwestią nieodzowną.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *