Pisząc o różnicach pomiędzy architektem IT a architektem oprogramowania trzeba pamiętać, że mówimy o roli, a nie osobie. Może się bowiem zdarzyć, że dana osoba występuje w więcej niż jednej roli. Dodatkowo sytuację komplikuje fakt, że obaj mają pewną wspólną część zestawu narzędziowego, czyli realizują swoje odmienne zadania, wykorzystując te same metodyki i narzędzia.
Orientacja technologiczna
Architekt oprogramowania świetnie zna technologię, jej mocne i słabe strony. Wie, jakie zmiany są planowane przez dostawcę w najbliższym czasie, które biblioteki są najlepsze, a których należy unikać. Potrafi zdefiniować najlepsze praktyki dla budowy rozwiązań w danej technologii. Bez problemu zaprojektuje optymalne rozwiązanie w danej technologii i będzie kontrolował jego dostarczanie przez programistów.
Architekt IT zna ogólnie wiele technologii w tym samym obszarze, ale nie wie, jak zbudować najlepsze rozwiązanie w ramach konkretnej technologii. Wie, jak zbudować zestaw najlepszych praktyk od strony metodycznej, chociaż już od strony merytorycznej raczej sobie z tym nie poradzi. Natomiast doskonale poradzi sobie z porównaniem technologii i dopasowaniem ich do potrzeb przedsiębiorstwa.
Orientacja problemowa
Architekt oprogramowania podchodzi do problemu przez pryzmat technologii, w której się specjalizuje. Stara się jak najlepiej rozwiązać problem na bazie posiadanego zestawu narzędziowego. Dopasowuje więc problem do technologii, mając doskonale świadomość jej ograniczeń.
Architekt IT stara się dobrać optymalną technologię do konkretnego problemu, patrząc przez pryzmat całościowej strategii przedsiębiorstwa. Natomiast może nie znać ograniczeń konkretnej technologii, co może stać na przeszkodzie do finalnego rozwiązania problemu. Dopasowuje technologię do rozwiązywanego problemu.
Orientacja czasowa
Architekt oprogramowania działa w perspektywie krótko i średnio-terminowej. Skupia się na tym, aby uzyskać wartość jak najszybciej i aby rozwiązanie było w pełni funkcjonalne w krótki czasie.
Architekt IT analizuje zagadnienia w perspektywie średnio i długoterminowej. Dba o to, aby w długim terminie rozwiązanie oprócz zapewnienia wymaganych funkcjonalności nie wpływało negatywnie na inne obszary przedsiębiorstwa.
Orientacja operacyjna
Architekt oprogramowania często włącza się w prace zespołu wytwórczego albo wręcz jest jego członkiem, tworzy najlepsze praktyki dla takiego zespołu. Najczęściej jest umieszczany w strukturach rozwojowych.
Architekt IT zwykle ma więcej odpowiedzialności w obszarze utrzymania architektury (chyba że występuje w roli architekta rozwiązania). Jest raczej bliżej administratorów / architektów systemowych, trafia więc częściej w struktury operacyjno-utrzymaniowe.
Podsumowanie
Mając na uwadze wszelkie powyższe kwestie, trzeba pamiętać, że mówimy o rolach, a nie konkretnych osobach. Sytuacja w każdej organizacji jest unikalna. Moga się zdarzyć sytuacje, że obie role będzie pełnić ta sama osoba albo, że nie ma wydzielonej osoby pełniącej te role (i np. rolę architekta IT pełni CIO, a rolę architekta oprogramowania CTO). Natomiast te role zawsze występują w organizacji, chociaż mogą być pełnione nieświadomie. Ktoś podejmuje decyzje przypisane do odpowiedzialności tych ról. Ewentualnie jest to cedowane na dostawców, ale wtedy osoba podejmująca decyzje przekazania roli do dostawcy ma w swoim zakresie odpowiedzialność za nadzór nad tym dostawcą.