Rola Architekta IT w procesie projektowym

Architektura_IT

Na potrzeby tego artykułu proces projektowy można zdefiniować jako ciąg powiązanych ze sobą czynności, których początkiem jest potrzeba, czyli konieczność osiągania określonych celów biznesowych, a końcem – działający i wspierający realizację owej potrzeby system informatyczny.

Architekt IT dba o zgodność tworzonych rozwiązań informatycznych z obowiązującymi w organizacji standardami, wzorcami, strategią czy też – jak mówią ramy architektoniczne TOGAF – pryncypiami architektonicznymi.

Wielu twierdzi, że aby zapanować nad rozwojem IT w organizacji, konieczne jest wdrożenie Architektury Korporacyjnej. Pozwala ona na wspólne zarządzania domenami – biznesową, IT oraz infrastruktury – dając przy tym pewność, że wdrażane rozwiązania w sposób realny i spójny wspierają istotne cele biznesowe organizacji na wszystkich płaszczyznach.

Niestety, uruchomienie takiego przedsięwzięcia jest dość złożone i kosztowne, więc niełatwo przekonać decydentów o jego niezbędności. Zazwyczaj wiąże się ono również z poważnymi zmianami organizacyjnymi oraz modyfikacją rozkładu kompetencji, co może budzić naturalny opór ludzi, którzy czują się dobrze w istniejących strukturach.

Na szczęście dynamicznie rozwijający się biznes, wymagający coraz większego wsparcia przez IT, szybko obnaża pewne niedoskonałości rozwiązań – ich małą elastyczność, długi czas wdrażania zmian, wysokie koszty utrzymania, małą efektywność itd. Modyfikacja już istniejących rozwiązań wydaje się być bardzo kosztowna. Z kolei nowe rozwiązania nie eliminują wszystkich problemów – zwiększają tylko stopień złożoności całego środowiska informatycznego organizacji. Jeśli dodać do tego słabą dokumentację  wprowadzanych zmian, po przekroczeniu pewnego progu złożoności kontrola dalszego rozwoju IT wydaje się być wręcz niemożliwa.

Coraz więcej organizacji skłania się zatem ku temu, aby jednak powołać u siebie Architekta Korporacyjnego. Kiedy już to zrobią, najczęściej wybierają metodykę opartą na ramach architektonicznych TOGAF. To wybór o tyle dobry, że są one świetnie udokumentowane, ciągle się rozwijają, a do dyspozycji informatyków są narzędzia, które implementują standardy zdefiniowane w TOGAF’ie.

Pewnym kompromisem – a w mojej ocenie etapem przejściowym – jest powołanie jedynie Architekta IT, który z jednej strony ma zinwentaryzować środowisko IT, czyli w najprostszym ujęciu narysować mapę wszystkich systemów działających w organizacji wraz z powiązaniami, a z drugiej strony – musi opracować efektywną metodykę aktualizacji mapy oraz zapanować nad inicjatywami projektowymi w kontekście ich zgodności ze strategią IT, standardami, wzorcami itp.

O tworzeniu mapy powiązań na pewno jeszcze wspomnę w kolejnych artykułach. Dzisiaj natomiast chciałbym napisać kilka słów o próbie zapanowania nad rozwojem nowych rozwiązań, czyli o roli Architekta IT w procesie projektowym.

Ogólna mapa procesu projektowego może wyglądać jak poniżej.

Procesprojektowy z perspektywy Architekta IT

Na diagramie można wyróżnić pięć ról:

  • Pomysłodawca
  • Architekt IT
  • Akceptujący
  • Dostawca
  • Inny opiniodawca

Pomysłodawca to osoba, która ma pomysł na to, w jaki sposób usprawnić biznes przy pomocy narzędzia informatycznego. Architekt IT dba o rozwój IT w organizacji zgodnie ze strategią, standardami, wzorcami itp. Akceptujący decyduje, czy rozwijać narzędzie. Dodatkowo może się zdarzyć, że są potrzebne opinie innego eksperta – np. prawnika, dzięki którym Akceptujący będzie miał komplet informacji, niezbędnych do podjęcia ostatecznej decyzji.

Pierwszym krokiem jest opisanie koncepcji przez Pomysłodawcę. Najczęściej reprezentuje on biznes, więc i samą ideę formułuje w języku biznesu. Pomysł wcale nie musi przyjąć postaci formalnego dokumentu. Może być on wynikiem spotkania, który został w głowach paru osób. Tak czy inaczej, w idealnym świecie Architekt IT ma okazję wstępnie przeanalizować pomysł, uzgodnić zakres wsparcia oraz zaproponować wstępne ramy rozwiązania. Niestety, wiem z doświadczenia, że niezwykle rzadko się zdarza, by już na tym etapie Architekt IT proszony był o konsultacje.

Wydaje się, że pomysł oraz koncepcja rozwiązania to wystarczający materiał dla osoby, która podejmuje decyzje w sprawie kontynuowania inicjatywy. Na ich podstawie godzi się na przygotowanie formalnej oferty przez Dostawcę. Oferta zawiera szczegółowe informacje na temat zakresu, budżetu oraz harmonogramu prac. Znajduje się w niej również opis koncepcji oraz sposób realizacji.

Architekt IT powinien mieć możliwość zaopiniowania oferty – nie jest bowiem pewne, czy ostatecznie Dostawca uwzględnił wszystkie wskazówki z etapu tworzenia koncepcji rozwiązania (takie wskazówki można na przykład umieścić w zapytaniu ofertowym). Zdarza się, że ze względu na niski budżet wybierane jest rozwiązanie tańsze, które niekoniecznie jest zgodne z pryncypiami architektonicznymi. Jeśli Architekt IT ma wystarczająco mocną pozycję, może wręcz zablokować taką ofertę. Tak samo jak koncepcja, również ofertę powinni zaopiniować również inni eksperci (np. specjalista od ochrony danych osobowych).

Akceptujący oprócz oferty powinien otrzymać komplet dokumentów, dzięki którym będzie mógł podjąć ostateczną decyzję w sprawie uruchomienia projektu. Może się zdarzyć, że wbrew negatywnej opinii Architekta IT projekt zostanie uruchomiony – trzeba bowiem pamiętać, że najważniejsze są potrzeby biznesu. Istotne jest jednak, aby Akceptujący uświadamiał sobie konsekwencje takiej decyzji. TOGAF przewiduje stworzenie Rejestru Odstępstw, w którym umieszcza się informacje o rozwiązaniach, które w jakimś stopniu nie spełniają pryncypiów architektonicznych. Dokonując wpisu do Rejestru, określa się, jak długo tolerowane będzie odstępstwo. W praktyce niestety zdecydowanie więcej odstępstw jest rejestrowanych niż usuwanych z Rejestru. Cóż, jeśli już coś w miarę dobrze działa, trudno znaleźć inwestora, który wyłoży środki na to, aby przy okazji rozwiązanie było czyste architektonicznie. Z listy pryncypiów powinny zniknąć te, które są notorycznie łamane – praktyka pokazuje, że w danej organizacji po prostu wcale pryncypiami nie są.

Tworzenie oraz opiniowanie oferty to dobry moment na to, aby zweryfikować prawdziwość modeli AS-IS oraz stworzyć odpowiednie modele TO-BE architektury, opisujące jej stan architektury po wdrożeniu rozwiązania objętego projektem.

Może się zdarzyć, że w trakcie trwanie projektu trzeba zmienić założenia architektoniczne. W takiej sytuacji również powinien móc wypowiedzieć się Architekt IT – zmiany mogą spowodować, że rozwiązanie przestaje spełniać pryncypia, więc należy się zastanowić, czy można je kontynuować w nowej formie. Zazwyczaj trzeba również zaktualizować modele TO-BE architektury.

Aktualizacja modeli konieczna jest również w momencie wdrożenia rozwiązania – o ile rozwiązania wprowadzało jakieś zmiany w architekturze IT organizacji. Wszystko zależy od tego, jak głęboko dokumentowana jest architektura. Jeśli dokumentowane są jedynie systemy wraz z połączeniami między nimi, ale bez zakresu przesyłanych danych, to projekt, który przewiduje jedynie rozszerzenie tego zakresu, nie wprowadza zmian w modelach architektonicznych.

W praktyce w dużych organizacjach, w których prowadzi się jednocześnie dziesiątki projektów, uzyskanie informacji o tym, że właśnie jeden z nich się zakończył i należy zaktualizować modele architektoniczne, wcale nie jest łatwe. Jedynym skutecznym sposobem wydaje się włączenie Architekta IT do grona osób odbierających rozwiązanie. W rezultacie można uzyskać jego potwierdzenie aktualizacji modeli w protokole odbioru rozwiązania.

Na koniec chciałbym jeszcze dodać parę słów o charakterze współpracy Kierownika Projektu i Architekta IT. W początkowej fazie rzeczywiście można mówić o współdziałaniu, ponieważ Architekt IT wspomaga Architekta Rozwiązania i ma realny udział w formułowaniu oferty. Z czasem jednak, gdy zmienia się rola Architekta IT w projekcie, staje on na straży czystości rozwiązania. Jak widać, przy takim obrocie sprawy charakter tej wzajemnej relacji również się przeobraża. Architekt IT okazuje się jeszcze jedną osobą, która powinna zweryfikować ofertę i ją zaopiniować – najlepiej pozytywnie. Próby wyjaśnienia nieprecyzyjnych zapisów w ofercie wydłużają całą procedurę. Sugestie wyboru  rozwiązań bardziej elastycznych, nadających się do ponownego użycia oznaczają zazwyczaj podniesienie kosztów projektu, czyli konieczność wprowadzenia istotnych zmian w ofercie. Zmniejsza się jej zakres, zmienia harmonogram. Może nawet trzeba ponownie przedyskutować założenia projektu i skonfrontować je z biznesem.

Włączenie akceptacji Architekta IT w protokole odbioru rozwiązania również może być postrzegane przez Kierownika Projektu jako kolejny element istotnie wpływający na termin wystawienia faktury i otrzymania wynagrodzenia za realizację projektu. Patrząc jednak realnie na problem, uzyskanie podpisu Aarchitekta IT świadczącego jedynie o tym, że repozytorium modeli architektonicznych zostało zaktualizowane, może być zadaniem dość prostym. Modele AS-IS oraz TO-BE zostały przecież stworzone już na etapie oferty. Wystarczy tylko zmienić statusy obiektów w modelach z TO-BE na AS-IS oraz z AS-IS na OLD.

 


Dodaj komentarz

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

2 komentarzy do “Rola Architekta IT w procesie projektowym