Kim jest architekt IT
Kim jest architekt IT, czym się zajmuje ? Zależnie kogo zapytamy dostajemy inną odpowiedź.
Wprowadzenie
Moim zdaniem większość problemów jest wynikiem faktu postrzegania architekta IT jako roli w organizacji, podczas, gdy, zgadzam się w tej materii z IASA (http://iasaglobal.org/), że jest to raczej zawód. Architekt IT może występować w organizacji w wielu różnych rolach co powoduje konfuzję przy próbie zdefiniowania kim jest. W każdej organizacji kładziony jest nacisk na różne aspekty zawodu architekta w zależności od potrzeb danej organizacji i jej poziomu dojrzałości. Obecnie dużo zawirowań wynika z nowych trendów mocno zorientowanych na robienie „tu i teraz” odrzucając zagadnienia strategicznego planowania czy zarządzania ignorując takie zagadnienia jak dług architektoniczny spychając je na później.
Technologiczne zorientowanie architekta IT
Dużo dyskusji wynika z występowania dwóch typów architektów o zupełnie innym podejściu do technologii. Mamy więc architektów oprogramowania, którzy są skoncentrowani na maksymalizacji wartości uzyskiwane z konkretnej technologii i budowaniu rozwiązań opartych o tą technologię. W swoim portfelu umiejętności mogą posiadać więcej niż jedną technologię, jednakże ich postrzeganie jest skoncentrowane na budowaniu wartości na tej technologii. Z drugiej strony mamy architektów IT, którzy są technologicznie niezależni. Dla nich technologia jest jednym za parametrów tworzenia rozwiązań (wartości) na mapie architektury. Pomimo posiadania doświadczenia technologicznego nie rozwijają oni swoich zdolności w konkretnej technologii do poziomu mistrza (i dalej), ale wykorzystują te umiejętności do lepszego zrozumienia całego wachlarza technologii i lepszego doboru portfela technologicznego.
Spory rozdźwięk między tymi grupami wynika z faktu, że jedni będąc blisko technologii zajmują się wprost tworzenie rozwiązań (dotykają kodu i mają bliską styczność z fizycznym rozwiązaniem) podczas gdy drudzy poruszają się na pewnym poziomie abstrakcji i często nie dotykają fizycznej części rozwiązania.
Obie te grupy to są architekci IT, mają podobne podejście do rozwiązywania problemów, posiadają podobny zakres umiejętności pomimo różnic w zakresie znajomości i podejścia do konkretnych technologii.
Architekt Korporacyjny
Kolejny aspekt tego zawodu to architekt korporacyjny. Skoro architekt IT to zawód, który może być wpasowany w wiele ról w organizacji to jak ma się sytuacja z architektem korporacyjnym? W większości przypadków określa się tym terminem osoby zajmujące się wysokopoziomowymi strategiami w organizacjach. Wydawać by się więc mogło, że jest to konkretna rola zawodowa. Dodatkowo często określa się ich jako kogoś zajmującego się znacznie szerszym obszarem przedsiębiorstwa, znacznie wykraczającym poza obszar architektury IT.
Przyznam się, że gdy po raz pierwszy spotkałem się z podejściem zaprezentowanym przez IASA w ITABoK (IT Architect Body of Knowledge) byłem przeciwny tej koncepcji. Proponują mianowicie aby uznać, że architekt korporacyjny zawiera się w profesji architektów IT. Również architektów biznesowych trudno mi było uznać za architektów IT. Trzeba, jednakże przyznać, iż pomimo różnych obszarów przedsiębiorstwa, którymi zajmują się ci poszczególni architekci można zauważyć, że posiadają oni podobny profil kompetencyjny, używają często tego samego zestawu narzędziowego i metodycznego. W związku z czym, finalnie doszedłem do wniosku, że rzeczywiście jest to jedna i ta sama profesja. Pojawiają się wątpliwości związane z nazewnictwem, bo wiadomo, że architekci korporacyjni nie chcą być utożsamiani wyłącznie z IT – jednakże pomysłu na lepszą nazwę chyba nikt nie ma.
Co moim zdaniem wyróżnia architekta korporacyjnego?
Perspektywa w jakie się porusza, obszar w jakim poszukuje rozwiązania dla problemów, podejście do komunikacji.
Architekt IT zajmujący się obszarem aplikacyjnym będzie poruszał się w świecie architektury aplikacji, będzie budował strategię dla aplikacji, wykazywał jak poszczególne zmiany w tej architekturze wpływają na aplikacje bądź będzie poszukiwał rozwiązań w obszarze architektury aplikacji. Natomiast architekt korporacyjny będzie poruszał się w szerszej perspektywie. Zagadnienia związane z architekturą aplikacji będzie odnosił do całości przedsiębiorstwa, strategię aplikacyjną będzie osadzał w kontekście celów i działań całości przedsiębiorstwa. Wpływ zmian w architekturze aplikacyjnej będzie odnosił do mierników w obszarze biznesowym. Jednym z podstawowych zadań, każdego architekta jest rozwiązywanie problemów / łamigłówek architektonicznych i budowanie rozwiązań dla tych problemów lub realizowanie potrzeby organizacji. Architekt korporacyjny będzie poszukiwał rozwiązań w szerszej perspektywie – np. rozwiązanie problemów z długim „Time To Market” może być zmiana procesów wdrożeniowych IT, może DevOps, a może optymalne jest połączenie kilku rozwiązań wraz z transformacją samej architektury IT. Moim zdaniem osoba będąca architektem aplikacji może być zarówno architektem IT lub architektem korporacyjnym.
Doszliśmy więc do punktu, gdzie możemy określić, że wyróżnikiem architekta korporacyjnego jest perspektywa w jakiej się porusza. Moim zdaniem raczej nie znajdziemy architekta korporacyjnego zajmującego się pojedynczymi systemami. Są to raczej osoby zajmujące się segmentami lub domenami architektonicznymi.
Kolejną rzeczą jest fakt, iż są to osoby mocno interdyscyplinarne, powinny posiadać bogate doświadczenie dotyczące nie tylko świata IT. Muszą one znać i rozumieć bieżące trendy technologiczne i potencjalny wpływ na obszar ich pracy. Nie jest to raczej dziedzina startowa dla nowych osób, ale raczej jeden z kolejnych etapów w karierze. Ważniejsze jest też podejście do zagadnień i doświadczenie niż wiedza teoretyczna np. znajomość TOGAF-a czy Zachmana.
Role architekta IT
Pisałem wcześniej, że dla mnie architekt IT to zawód, który daje możliwości występowania w różnych rolach. Poniżej opiszę potencjalne role powiązane z zagadnieniami architektonicznymi pomijając role czysto organizacyjne (kierownika, dyrektora itp.).
Rodzaj wsparcia
Przyglądając się przestrzeni w jakiej jest definiowana odpowiedzialność architekta może wskazać, iż jednym z kluczowych czynników charakteryzujących daną rolę jest określenie stopnia zaangażowania w działania utrzymaniowe dotyczące architektury w stosunku do zaangażowania w działania rozwojowe. Warto tutaj zauważyć, że w większości przypadków nie będziemy mieć do czynienia z sytuacją czarno-białą, czyli albo wyłącznie działania dotyczące rozwoju lub też działania dotyczące utrzymania. Jedną z oczywistych ról jaka od razu nam się nasuwa jest architekt rozwiązania, który jest przypisany do działań rozwojowych, chociaż w zależności od organizacji adresuje również w pewnym stopniu działania utrzymaniowe (uwzględniając odpowiednie wymagania i potrzeby z tego obszaru w swoich rozwiązaniach). Drugą oczywistą rolą po przeciwnej stronie jest główny architekt (Chief Architect). Tutaj zależnie od charakterystyki danej organizacji osoba taka w różnym stopniu angażuje się w działania rozwojowe, od prawie całkowitego braku zaangażowania (roli policjanta) aż po wspierania bardziej złożonych projektów / programów poprzez przygotowywanie blueprintów / szkiców rozwiązania. Kolejną rolą jaka trafia się architektowi w obszarze utrzymaniowo / rozwojowym jest Właściciel Biznesowy systemu. Rola taka przeważnie jest przypisywana w przypadku systemów, które nie realizują funkcji biznesowych w związku z czym nie ma osób zainteresowanych po stronie biznesu, np. mogą to być komponenty integracyjne.
Perspektywa czasowa
Kolejnym aspektem pod jakim należy weryfikować rolę architekta jest zakres czasowy realizowanych prac oraz rozległość wizji / obszaru architektury który podlega kształtowaniu przez danego architekta. Tutaj również daleki jestem od budowania jakiejś określonej miary skupiając się raczej na poszczególnych obszarach charakterystycznych dla tego aspektu takich jak np. projekt / program lub horyzont krótkoterminowy / długoterminowy. W przypadku perspektywy krótkoterminowej ponownie spotykamy się z rolą architekta rozwiązania, ale co ciekawe możemy też mieć do czynienia z architektem w roli Project (rzadziej) / Program (częściej) Managera. Może to w pierwszej chwili budzić zdziwienie, ale wbrew pozorom doświadczony architekt IT (szczególnie korporacyjny) posiada odpowiedni zestaw narzędziowy / metodyczny oraz punkt widzenia, które pozwolą mu na prowadzenie programu transformacji architektonicznej. Oczywiście, w przypadku tradycyjnych projektów realizujących wymagania zwyczajny PM będzie znacznie bardziej efektywny. Jednakże, w sytuacji, gdy program jest ukierunkowany na zmianę w zdolnościach (capabilities) danego przedsiębiorstwa tradycyjne metodyki projektowe nie sprawdzają się, bo są skoncentrowane na zupełnie innych miernikach sukcesu. W przypadku, kiedy wydłużamy perspektywę czasową to dotykamy zadań związanych ze strategią, roadmap-ami i w tym przypadku znów pojawia się rola głównego architekta.
Domena architektury
Kolejnym aspektem jest rozległość odpowiedzialności w wymiarze architektury (np. zgodnie z domenami definiowanymi przez TOGAF). Będziemy mieli więc architektów biznesowych, aplikacyjnych, danych czy technicznych (czasami jeszcze integracyjnych). W tym aspekcie możemy też inaczej zdefiniować przestrzeń i otrzymamy architekta systemowego (odpowiedzialnego za pojedynczy system) czy też architekta odpowiedzialnego za grupę systemów (domenę architektoniczną – architekta domenowego) lub na końcu znowu głównego architekta odpowiedzialnego za całość obszaru architektury.
Warto również zwrócić uwagę, że w przypadku architektów biznesowych czy danych nie będziemy mieć sytuacji skoncentrowanej na pojedynczym systemie. Role takie adresują zagadnienia w domenie architektonicznej lub dla całości architektury.
Podsumowanie
Warto zauważyć, że powyższe opisy pokazują rolę architekta w różnych aspektach. Rzeczywisty zakres obowiązków / odpowiedzialności będzie wynikiem złożenia wszystkich tych wymiarów. Uzyskamy więc takie role jak np. Główny architekt aplikacji albo architekt rozwiązania infrastruktury. Rolą architekta jest dopasowanie się do potrzeb organizacji i uwarunkowań poszczególnych zadań, nie może więc on na sztywno trzymać się wytyczonego obszaru odpowiedzialności.
Jeżeli coś dla Ciebie jest niejasne, brakuje Ci jakiś informacji to zostaw komentarz albo napisz do mnie. Postaram się rozszerzyć artykuł.