sty
29

Kontrakty architektoniczne w TOGAF

Źródło: Andrzej Sobczak
Print Friendly

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.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “Kontrakty architektoniczne w TOGAF

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

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

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>