Czym jest architektura IT

Architektura IT jest pojęciem dosyć szerokim, a z uwagi na fakt, iż w każdej organizacji trochę inaczej wygląda kontekst jego użycia to również rozumienie potrafi być odmienne.

Pojęcie „architektura IT”

Możemy zajrzeć na wikipedię, albo do encyklopedii PWN, z których to wynika, iż architektura zajmuje się tworzeniem ładu w otoczeniu celem dostosowania go do zaspokojenia wielorakich potrzeb przez planowaną przemianę otoczenia. Ze źródeł tych wynika, iż mamy do czynienia z wieloma rodzajami architektury (krajobrazu, wnętrz, procesora, korporacyjną). W skład architektury wchodzą więc wszelkie elementy danej dziedziny (np. fontanny, ławeczki itp.) wraz z łączącymi je relacjami. Warto też zauważyć, iż nie są to obrazy statyczne, a podlegające ciągłym zmianom. Musimy też zdać sobie sprawę z faktu, iż niezależnie czy będziemy planować / projektować architekturę czy nie ona po prostu będzie. Jeżeli kupimy sobie ławeczkę to dostawca nam ją przywiezie i zapyta, gdzie postawić, jeśli nie dostanie odpowiedzi to postawi, gdzie mu wygodniej. Jeżeli nie przemyślimy decyzji, gdzie powinna stać, może się okazać, że będzie nam utrudniać później poruszanie się po ogrodzie. Oczywiście, że w przypadku ławeczki to nie jest problem, bo możemy ją później przestawić, W przypadku, gdy tak zrobimy z dużą rzeźbą to już nie będzie tak łatwo jej później przemieścić. Dlatego właśnie tak ważne jest projektowanie / planowanie architektury.

Architektura IT

Czy to oznacza, że architektura IT to taka architektura, ale w świecie IT? Zamiast architektury domu, mamy architekturę systemu / oprogramowania, a zamiast architektury miasta, mamy architekturę IT / korporacyjną? Ależ skąd. Pomimo iż, przy zajmowaniu się architekturą IT możemy śmiało czerpać inspiracje z tradycyjnej architektury, to jednak ma ona (architektura IT) zupełnie inne (znacznie słabsze) umocowanie w rzeczywistości. Katastrofy wynikające z błędnego zaprojektowania architektury IT są często niewidoczne, przy odpowiednim księgowaniu udaje się je zupełnie ukryć. Widziałem projekty, które przekroczyły kilkakrotnie budżet i czas realizacji, nie osiągnęły celów a i tak były ogłaszane sukcesami. Architekt IT nie ma więc mocy sprawczej, architektura IT jest mocno oparta o zarządzanie relacjami w organizacji, interesariuszami. Dobry architekt IT jest liderem zmian architektury (a nie dyrektorem), promotorem właściwego podejścia do zarządzania architekturą IT.

W przypadku architektury IT jej elementami są komponenty świata IT. Oczywiście tworząc modele / opisy architektoniczne ich szczegółowość dostosowujemy do naszych potrzeb i możliwości. Konieczne jest pamiętanie, że istotnym elementem architektury są również relacje pomiędzy komponentami. Opisując architekturę np. aplikacyjną trzeba więc pamiętać, że ważnym elementem są wzajemne zależności poszczególnych aplikacji (czyli m.in. integracje), oraz zachodzące zmiany. Często w opisach stosuje się więc określenie czy mówimy o architekturze AS-IS, czyli o stanie obecnym, czy też o architekturze TO-BE, czyli stanie docelowym. Dlatego jednym z ważnych zadań w architekturze IT jest tworzenie tzw. roadmap, czyli dróg przejścia / sposobów przekształcenia stanu obecnego do docelowego.

Zakres architektury IT

Możemy oczywiście spojrzeć szerzej niż tylko na komponenty IT – uwzględniając elementy przedsiębiorstwa i w takim przypadku mówimy o architekturze korporacyjnej. Z uwagi na dużą złożoność i rozległość świata IT zajmuje się zwykle tylko jego pewnym obszarem, natomiast budując nasze umiejętności architekta specjalizuje się w konkretnej dziennie / warstwie architektury.

Oczywiście wraz z rozwojem naszego doświadczenia i wiedzy zaczynamy rozszerzać swoje kompetencje na kolejne warstwy. Poniżej znajduje się podział warstw architektury.

Pomimo, iż architekt skupia się w pracy na komponentach konkretnej warstwy to musi rozumieć również pozostałe obszary architektury (przynajmniej wysokopoziomowo) tak, aby być w stanie zintegrować rezultat pracy z innymi obszarami.

Podsumowanie

• Architektura IT to sposób opisu świata IT (opis powinien zawierać zarówno obiekty jak i łączące je relacje i powinien zostać uproszczony przez eliminację zbędnej złożoności)
• Opis musi być zrozumiały dla wszystkich uczestników dialogu ( często używa się modeli referencyjnych, najczęściej używa się standardowych notacji)
• Niezależnie czy stworzymy opis czy nie to zawsze jakaś architektura będzie