The Open Group Architecture Framework (TOGAF) stanowi szczegółowy sposób i zestaw narzędzi pomocniczych rozwoju architektury korporacyjnej.
Wspiera cztery domeny architektury:
TOGAF ADM (ang. Architecture Development Method – Metoda Rozwoju Architektury) konceptualizuje proces rozwoju architektury w kilku etapach, w których rozpatrywane są jednostkowe aspekty ogólnego problemu. Poniżej przedstawione zostaną poszczególne iteracyjne fazy tych etapów. Prezentowane podejście jest dedykowane dla rozwiązań typu SOA.
Diagram ilustrujący cykl ADM (udostępniony przez The Open Group)
Faza skupiająca się na przygotowaniu i zainicjowaniu działań niezbędnych do realizacji zlecenia biznesowego dotyczącego stworzenia nowej architektury korporacyjnej. TOGAF przewiduje przyrostowy rozwój architektury. Faza wstępna służy również określaniu potrzeb, które należy zrealizować by móc rozpocząć poszczególne przyrosty.
Diagram Modelu Zakresu TOGAF
Faza A skupia się na wizji, zakresie rozwoju architektury przedsiębiorstwa, czynnikach sterujących oraz ocenie gotowości. W ramach tej fazy tworzony jest dokument wizji architektury, który ma na celu dostarczenie formalnie uzgodnionych rezultatów projektu oraz deklarację prac architektonicznych.
Opis architektury strategicznej projektu stanowi kluczą kwestię fazy A. Obejmuje on zakres formalnego opisu, tworzącego ramy organizacyjne dla działań operacyjnych i działań transformujących oraz długoterminową perspektywę dla ustalania kierunku na szczeblu zarządczym. Pozwala również na wyodrębnienie poszczególnych segmentów w SOA, przed opracowaniem ich architektury i przejściem do szczegółowego opisu komponentów.
Począwszy od fazy A, przez kolejne trzy fazy, następuje aktualizacja metamodelu oraz dalsze wytwarzanie dokumentu architektury.
Domenę biznesowa stanowią:
Rekomendowana zawartość dokumentu specyfikacji wymagań architektonicznych jest następująca:
Dokumentem komplementarnym do specyfikacji wymagań architektonicznych jest dokument definicji architektury (ang. Architecture Definition Document). Stanowi on „kontener” dla artefaktów powstających w ramach projektu wytwarzania nowej architektury. Powinien on dostarczyć jakościowy obraz rezultatu, komunikując przy tym zamiary architektów.
Domenę aplikacji stanowią:
Podczas fazy D wytwarzane są model wdrożenia i model implementacji sytemu. Celem jest opis bazowej architektury technicznej w ujęciu logicznym i stworzenie docelowej architektury technicznej w ujęciu usługowym oraz opracowanie analizy luk. Analizowana jest zgodności z SOA Reference Architecture (Architektura Referencyjna) i z SOA Reference Model (Techniczny Model Referencyjny).
W trakcie fazy D następuje przełożenie mapy komponentów aplikacji zdefiniowanych w fazie projektowania aplikacji na zestaw komponentów technicznych, które stanowią składniki oprogramowania i sprzętu.
Faza E identyfikuje nowe możliwości i kluczowe rozwiązania oraz sposób ich wprowadzania do organizacji (w formie architektur pośrednich), w celu osiągnięcia architektury docelowej. Architektury pośrednie stanowią podstawę planu migracji.
W tej fazie rozpoczyna się planowanie implementacji, a następnie definiowane są narzędzia dostarczające rozwiązania dla ustalonej architektury. Zakładanym efektem końcowym fazy jest komplet dokumentacji (mapy drogowe – roadmaps, matryce rozwiązań oraz diagramy) przedstawiający identyfikację zakresu rozwiązań, integracji i zarządzania oraz zewnętrznych i wewnętrznych dostawców usług.
Etap prowadzi do stworzenia we współpracy z interesariuszami szczegółowego planu wdrożenia architektury. Stanowi fazę weryfikacji modelu wdrożenia przed samym wdrożeniem. Celem jest priorytetyzacja projektów i oszacowanie zależności, kosztów i korzyści związanych z poszczególnymi projektami migracyjnymi. Spriorytetyzowana lista projektów stanowi podstawę planu migracji.
Celem fazy G jest sformułowanie rekomendacji służących do zarządzania implementacją danego systemu. Faza skupia się na nadzorowaniu implementacji w celu poprawy jakości wdrożeń w ogóle, a w szczególności w celu zapewnienia zgodności z architekturą. Implementacja powinna odbywać się zgodnie z modelami procesu nadzoru i strategii opartymi na standardach SOA i TOGAF zdefiniowanymi w poprzedniej fazie. Po zakończonej implementacji dokonywany jest przegląd poimplementacyjny (ang. post implementation review). Po nim następuje zamknięcie całego projektu. W ramach przeglądu przewidziana jest aktualizacja dwóch dokumentów: wizji architektury i definicji architektury.
W fazie H definiowany jest proces zarządzania zmianami dla nowej bazowej architektury, która jest osiągania z momentem zakończenia fazy nadzoru nad implementacją. W ramach tego procesu prowadzi się ciągły monitoring rozwoju technologicznego oraz zmian w środowisku biznesowym, w celu decydowania czy formalnie zainicjować nowy cykl rozwoju architektury.