Kontrakty architektoniczne w TOGAF
W szerszym ujęciu kontrakt (łac. contractus) oznacza zgodne porozumienie dwóch lub więcej stron (konsens), ustalające ich wzajemne prawa lub obowiązki. W TOGAF’ie kontrakt jest narzędziem ładu architektonicznego (Architecture Governance). Odzwierciedla on porozumienie zawarte przez zespół ds. architektury korporacyjnej (często w osobie Głównego Architekta) z drugą stroną i dotyczy on kwestii związanych z szeroko rozumianymi pracami architektonicznymi (lub realizacją rozwiązań na bazie tych prac). W zależności od tego, kim jest “druga strona” w TOGAFie mogą występować różnego rodzaju kontrakty.
Pierwszym rodzajem kontraktu (zawieranym w ramach fazy “A” cyklu ADM – czyli “Wizji architektury”) jest kontrakt pomiędzy Głównym Architektem a sponsorem prac architektonicznych. Jego celem jest z jednej strony ustalenie jakie produkty architektoniczne, w jakim czasie i w jakim budżecie będą dostarczone do organizacji, a z drugiej strony kontrakt ten zapewnia zgodę na wykorzystanie określonych zasobów organizacji na opracowanie tych produktów. Kontrakt ten nazywany jest w TOGAFie “Oświadczeniem o pracach architektonicznych” (Statement of Architecture Work) i często ma postać dokumentu zarządczego dla całego cyklu ADM.
Drugim rodzajem kontraktu (zawieranym w ramach fazy “G” cyklu ADM – czyli “Nadzoru nad implementacją”) jest kontrakt pomiędzy Głównym Architektem a właścicielem biznesowym projektu. Jego celem jest z jednej strony potwierdzenie, że produkty które będą dostarczone w ramach projektu wynikłego z realizacji wcześniejszych faz cyklu ADM (w szczególności z “Planowania migracji”) i które realizują fragment modelu docelowego organizacji (tj. opracowaną architekturę “to-be” lub architekturę pośrednią) są satysfakcjonujące dla biznesu, a jednocześnie, że biznes nie podejmie żadnych działań, bez wcześniejszych uzgodnień z zespołem architektonicznym (typowym przykładem takiej sytuacji może być zgoda “biznesu” na odbiór produktów nie spełniających standardów architektonicznych). Ten rodzaj kontraktu najczęściej ma postać notatki potwierdzającej ustalenia ze spotkania, na którym omawiano zagadnienia dotyczące konkretnego projektu z jego właścicielami biznesowymi.
Wreszcie trzeci rodzaj kontraktu (zawierany w ramach fazy “G” cyklu ADM – czyli “Nadzoru nad implementacją”) jest kontraktem pomiędzy Głównym Architektem a realizatorem projektu (może to być zarówno zewnętrzna firma IT, jak i wewnętrzny dział IT). Jego celem jest określenie, jakie są oczekiwania architektoniczne względem produktów (rozwiązań IT), które będą dostarczone w ramach projektu wynikłego z realizacji wcześniejszych faz cyklu ADM (w szczególności z “Planowania migracji”) i które realizują fragment modelu docelowego organizacji (tj. opracowaną architekturę “to-be” lub architekturę pośrednią), a jednocześnie dostarcza on dostawcy gwarancji, że jeżeli uwzględni te oczekiwania, to produkty zostaną odebrane bez przeszkód. Oczekiwania architektoniczne zawarte są w pryncypiach i standardach architektonicznych oraz w modelu docelowym (architekturze “to-be”). Oczywiście ten rodzaj kontraktu nie musi stanowić odrębnego dokumentu, gdyż może być np. załącznikiem do umowy z wykonawcą zewnętrznym, lub mieć postać notatki / maila w przypadku dostawcy wewnętrznego.
Od strony praktycznej należy jeszcze rozróżnić sam kontrakt (negocjowany/podpisywany w fazie “G” cyklu ADM) oraz jego standardową zawartość (którą można zmienić podczas negocjacji w fazie G), którą najczęściej przygotowuje się dla projektów w fazie “F” (Planowanie migracji) cyklu ADM.
Należy pamiętać także, że sam kontrakt to za mało (zwłaszcza w przypadku jego trzeciego rodzaju) i niezbędne są przeglądy architektoniczne, które zapewniają w praktyce weryfikację stosowalności zapisów zawartych w tym kontrakcie.
Komentarze do wpisu
Świetny blog, chyba jedyny w Polsce o tej tematyce.
Dodaj komentarz