TOGAF (Framework Architektury Otwartej Grupy) to otwarty framework organizacyjny. Sam framework jest dobrze udokumentowanym zbiorem wiedzy, w tym szczegółowymi metodami i zestawem narzędzi wspierających rozwój architektury przedsiębiorstwa. TOGAF 9.2 to najnowsza wersja frameworku.
- TOGAF jest rozwijany i utrzymywany przez członków The Open Group i działa w zespole zwanym Forum Architektury. Pierwsza wersja TOGAF 1 została opracowana w 1995 roku, a kolejne wersje TOGAF rozszerzały i ulepszały ten system wiedzy.
- TOGAF został opracowany dzięki wspólnym wysiłkom ponad 300 członków forum architektury reprezentujących niektóre z wiodących firm i organizacji na świecie – dlatego jest dobrym podsumowaniem ogólnych praktyk architektury przedsiębiorstw.
- Rozwój i utrzymanie architektury przedsiębiorstwa to złożony proces, w który zaangażowanych jest wielu interesariuszy i procesów decyzyjnych. TOGAF pomaga, dokumentując specyfikacje architektury korporacyjnej, procesy i produkty robocze.
- Korzystając z TOGAF, organizacje mogą opracować spójną architekturę przedsiębiorstwa, która odzwierciedla potrzeby interesariuszy, przyjmuje najlepsze praktyki i odpowiednio uwzględnia obecne potrzeby oraz postrzegane potrzeby biznesowe w przyszłości.
Skąd pochodzi TOGAF?
TOGAF powstał z Ram Architektury Technologii Zarządzania Informacją Departamentu Obrony USA (TAFIM). TOGAF 1.0 został ostatecznie wydany w 1995 roku po latach badań, za zgodą Departamentu Obrony USA i przy pomocy dużej inwestycji ze strony rządu USA. TOGAF wydał dotychczas swoją dziewiątą wersję, TOGAF 9 (najnowsza wersja to TOGAF 9.2)

Dlaczego TOGAF?
Architektura IT musi ściśle odzwierciedlać cele biznesowe organizacji. Rzeczywiście, należy stosować konkretne techniki (scenariusze biznesowe), aby zapewnić, że cele biznesowe są właściwie rozumiane przez architekta IT i odzwierciedlone w architekturze IT opracowanej przy użyciu TOGAF.

Oto powody, dla których powinniśmy przyjąć TOGAF ADM do rozwoju architektury:
- Kompleksowa ogólna metoda
- Uzupełniająca, a nie konkurująca z innymi frameworkami
- Szeroko przyjęta na rynku
- Możliwość dostosowania do potrzeb organizacji i branży
- Dostępna na podstawie darmowej licencji wieczystej
- Neutralny wobec dostawców, narzędzi i technologii otwarty standard
- Unika wynajdywania koła na nowo
- Dopasowanie IT do biznesu
- Oparte na najlepszych praktykach
- Możliwość uczestniczenia w ewolucji frameworku
Czym jest ADM?
Metoda Rozwoju Architektury (ADM) jest stosowana do opracowania architektury przedsiębiorstwa, która spełni potrzeby biznesowe i technologii informacyjnej organizacji. TOGAF ADM jest wynikiem ciągłych wkładów ze strony dużej liczby praktyków architektury w celu realizacji następujących celów:
- Opisuje metodę rozwijania i zarządzania cyklem życia architektury przedsiębiorstwa i stanowi rdzeń TOGAF.
- Może być dostosowana do potrzeb organizacji i jest następnie wykorzystywana do zarządzania realizacją działań związanych z planowaniem architektury.
Metoda rozwoju architektury – często określana jako skrót ADM – to szczegółowy proces krok po kroku używany do opracowywania lub zmiany architektury przedsiębiorstwa.
ADM opisuje 10 faz obejmujących cykl rozwoju architektury.
Te fazy to:
- Etap wstępny
- Faza A: Wizja architektoniczna
- Faza B: Architektura biznesowa
- Faza C: Architektura systemu informacyjnego
- Faza D: Architektura techniczna
- Faza E: Możliwości i rozwiązania
- Faza F: Planowanie migracji
- Etap G: Wdrożenie zarządzania
- Faza H: Zarządzanie zmianą architektury
- Zarządzanie wymaganiami

Wejście i wyjście ADM
TOGAF dostarcza szereg materiałów wejściowych i wyjściowych z każdej fazy:
- To są sugestie i nie muszą być ściśle przestrzegane
- Każdy wyprodukowany materiał powinien być wersjonowany, aby wskazać, kiedy zaszła zmiana
- Pokazana numeracja wersji jest również sugestią i nie musi być przestrzegana
Wyniki
Produkt pracy, który jest określony w umowie i następnie formalnie przeglądany, uzgadniany i zatwierdzany przez interesariuszy. Zazwyczaj będzie archiwizowany po zakończeniu projektu lub przeniesiony do Repozytorium Architektury jako model referencyjny

Etap początkowy:

Głównym celem etapu początkowego jest określenie i ustalenie wymaganych zdolności architektonicznych organizacji.
Jednym z kluczowych elementów jest określenie, co należy zrobić i jak to wdrożyć. Na przykład, głównym wynikiem jest wniosek o pracę architektoniczną który określa wymagania i decyduje, jaki zakres, struktura, narzędzia lub ramy architektoniczne są potrzebne do wsparcia tej pracy.
Na tym etapie TOGAF jest specjalnie dostosowany do zaspokojenia nadchodzących potrzeb iteracji ADM. Definiujemy podstawowe zasady, oceniamy zdolność struktury przedsiębiorstwa i biznesu do wprowadzenia wymaganych zmian oraz integrujemy TOGAF z innymi ramami zarządzania. Na tym etapie są kroki, aby ograniczyć organizację korporacyjną dotkniętą proponowanymi zmianami, potwierdzić poprawne ramy zarządzania i wsparcia, zdefiniować i ustanowić zespół EA oraz organizację, zidentyfikować i ustanowić zasady architektoniczne, dostosować TOGAF i wszelkie inne ramy oraz wdrożyć narzędzia. Na koniec tej fazy zespół EA powinien być gotowy do śledzenia iteracji cyklu ADM. Dzieje się tak częściowo dlatego, że etap wstępny jest pokazany na górze diagramu ADM i poza główną pętlą etapów A do H.
Faza A: Wizja architektury:

Faza A dostarcza jasne oświadczenie o pracy architektonicznej, które będzie dostarczone w iteracji ADM. Dostarcza również wizję proponowanej architektury przedsiębiorstwa. To poczucie kierunku jest niezbędne do prowadzenia pracy ADM w całym procesie iteracyjnym. oświadczenie o pracy architektonicznej określa procedury opracowywania i wdrażania architektury określonej w wizji architektonicznej. To wizja dostarcza wysokiego poziomu pragnienia funkcjonalności i wartości biznesowej, które proponowana architektura przedsiębiorstwa zapewni. Zaczynając od aplikacji o pracę budowlaną, Faza A dostarcza narzędzie (tę wizję) do sprzedaży korzyści proponowanych zdolności interesariuszom i decydentom w przedsiębiorstwie. Scenariusze biznesowe są używane do zrozumienia wymagań biznesowych i pomagają wyjaśnić wymagania architektoniczne sugerowane przez wymagane funkcje. Jest to udokumentowane w oświadczeniu o pracy architektonicznej i jest używane do budowania konsensusu w celu wsparcia ostatecznej architektury. Gdy organizacja sponsorująca podpisuje dokument, pojawi się konsensus.
Kroki w Fazie A polegają na przekształceniu wniosku o pracę budowlaną w jasne oświadczenie o pracy architektonicznej oraz zapewnieniu, że firma jest w stanie, gotowa, chętna i zobowiązana do wprowadzenia niezbędnych zmian architektonicznych. Obejmuje to ustanowienie projektu architektonicznego, w tym zdefiniowanie jego zakresu, a także potwierdzenie i rozwinięcie zasad architektury i biznesu. Faza A identyfikuje interesariuszy oraz ich obawy i wymagania, a także potwierdza cele biznesowe, czynniki napędzające i ograniczenia etapu wstępnego. Aby zapewnić sukces, ocenia również zdolności biznesowe, ocenia gotowość do transformacji biznesowej i rozwiązuje wszelkie ryzyka transformacji.
Faza B: Architektura biznesowa:

TOGAF postrzega architekturę przedsiębiorstwa jako sposób na poprawę zdolności biznesowych – dlatego pierwsza faza rozwoju architektury dotyczy architektury biznesowej .
ADM z punktu widzenia biznesu — w wstępnych etapach wniosków o prace infrastrukturalne w celu określenia silnego zapotrzebowania biznesowego, a następnie doprecyzowanej dla Fazy A w pracach infrastrukturalnych i oświadczenie wizji architektury
Kluczowym celem fazy architektury biznesowej jest opracowanie docelowej architektury biznesowej, która pokazuje, jak przedsiębiorstwo realizuje wizję architektury i rozwiązuje wniosek o pracę architektoniczną. Jej drugim celem jest najpierw zidentyfikowanie komponentów mapy drogowej architektury, które mają na celu wypełnienie luki między bazą a docelową architekturą biznesową. TOGAF postrzega wiedzę o architekturze biznesowej jako warunek wstępny do pracy architektonicznej w innych dziedzinach (takich jak dane, aplikacje i technologia). Architektura biznesowa pokazuje również kluczowym interesariuszom wartość komercyjną i zwrot z inwestycji w pracę architektoniczną. Modele biznesowe, takie jak modele aktywności lub procesów, przypadki użycia i modele klas, lub diagramy połączeń węzłów,
Wszystkie trzy fazy rozwoju architektury (B, C i D) przebiegają według podobnych kroków. Ważne jest, aby ponownie wykorzystać dostępny model referencyjny i dostosować wszystkie wyniki do punktu widzenia interesariuszy. Następnie architekt opracowuje opis bazy i celu architektury biznesowej oraz przeprowadza analizę luk, aby określić, jak przekształcić się z jednego w drugie.
Faza C: Architektura systemu informacyjnego:

TOGAF dzieli Fazę C – Architektura systemu informacyjnego – na dwie części, obejmujące rozwój danych i aplikacji architekturze. Dokument TOGAF zawiera krótki rozdział wprowadzający obejmujący dwa obszary, a następnie oddzielne rozdziały dotyczące danych i aplikacji. Podobnie jak w innych etapach rozwoju architektury (B&D), celem jest opracowanie docelowej architektury systemu informacyjnego dla danych i aplikacji oraz określenie komponentów mapy drogowej architektury na podstawie luki między bazą a docelową architekturą.
Faza C zawsze obejmuje połączenie architektury danych i aplikacji. Ważne jest, aby obie były uwzględnione, a kolejność nie ma znaczenia – są zwolennicy obu metod. Kroki dla danych i aplikacji są bardzo podobne – wybór modeli referencyjnych, punktów widzenia i narzędzi; opracowanie baz i następnie zlokalizowanie opisów architektury, przeprowadzenie analizy luk i zdefiniowanie komponentów mapy drogowej; oraz rozwiązanie wszelkich wpływów w ogólnym środowisku architektonicznym. Po formalnym przeglądzie interesariuszy architektura została ostatecznie określona, a dokument definicji architektury został stworzony.
Główna różnica między danymi a aplikacjami leży w temacie, co znajduje odzwierciedlenie w użyciu różnych modeli referencyjnych, technologii i reprezentacji architektonicznych. Na przykład architektura danych może używać relacji encji lub diagramów klas, podczas gdy architektura aplikacji może używać diagramów komunikacji aplikacji lub diagramów inżynierii oprogramowania.
Faza D: Architektura techniczna:

Faza D to faza TOGAF, która rozwija architekturę techniczną dla projektu architektonicznego. Architektura technologii opisuje strukturę i interakcję usług platformy oraz logicznych i fizycznych komponentów technologicznych. Faza D rozwija docelową architekturę technologiczną, która wspiera komponenty danych i aplikacji (opracowane w fazie C) w realizacji komponentów biznesowych.
Architektury opracowane w fazach B, C i D są łączone w celu zrealizowania wizji architektury – rozwiązując obawy interesariuszy i wnioski o prace budowlane. Podobnie jak w innych fazach rozwoju architektury, Faza D identyfikuje komponenty mapy drogowej architektury, aby osiągnąć przejście z Bazy do Celu. Kroki w Fazie D są prawie takie same jak w Fazie B i Fazie C – główna różnica polega na tym, że teraz skupiamy się na technologii. Dlatego obejmuje to techniczne modele referencyjne oraz techniczne standardy lub pomiary – takie jak wydajność, łatwość konserwacji, lokalizacja oraz opóźnienie lub dostępność.
Określenie wyników i dostarczanych produktów jest bardzo ważne, aby pomóc w budowie architektury technicznej, która rzeczywiście wspiera system informacyjny i architekturę biznesową. Uzyskanie odpowiedniego zakresu może przyspieszyć zwroty, podczas gdy zbyt duży zakres utrudni udane wdrożenie. Nie chodzi tu o samą technologię wdrożeniową, ale o rozwój architektury technicznej, która rzeczywiście odpowiada wizji architektonicznej i wnioskom o pracę.
Faza E: Możliwości i rozwiązania:

Faza E nosi swoją nazwę – ma na celu znalezienie możliwości dostarczenia docelowej architektury poprzez wdrożenie konkretnych rozwiązań. Faza E generuje pierwszą kompletną wersję mapy drogowej architektury, łącząc zalecenia analizy i faz rozwoju – B, C i D.
Na tym etapie główny nacisk kładzie się na to, jak dostarczyć architekturę. Dlatego koncentruje się na tworzeniu mapy drogowej architektury, wymieniając pakiety robocze w harmonogramie, aby osiągnąć docelową architekturę. Gdy zmiana jest tak duża, że niemożliwe jest przejście bezpośrednio z bazy do docelowej architektury, wtedy etap E wytworzy podejście inkrementalne, składające się z architektur pośrednich lub przejściowych. Faza E mapuje wymagane zmiany architektoniczne do procedur inwestycyjnych i projektów, które mają fundusze i zasoby do realizacji pakietu roboczego oraz dostarczają architektury przejściowe i docelowe. Wejście na tym etapie to prawie wszystko, co jest wynikiem wczesnego etapu. Te kroki biorą te wyniki; konsolidują je, analizują zależności i godzą różnice; oraz ponownie potwierdzają, że organizacja może wprowadzać zmiany. Faza E poprawia i aktualizuje wymagania, dokumenty architektoniczne i mapy drogowe architektury. Kluczowym wynikiem jest pierwszy krok w planie wdrożenia i migracji.
Faza F: Planowanie migracji:
Wczesne etapy ADM zidentyfikowały potrzebę zmian architektonicznych, a następnie opracowały architektury biznesowe, danych, aplikacji i techniczne, aby wspierać tę potrzebę. Następnie, w drugiej fazie, opracowywany jest plan wdrożenia i migracji na wysokim poziomie, aby skorzystać z możliwości inwestycyjnych i zidentyfikować konkretne rozwiązania. Architektura docelowa: Faza F finalizuje szczegółowy plan wdrożenia i migracji, a także ostateczną mapę drogową architektury.
Zapewnia również, że plan jest skoordynowany z metodami zarządzania zmianami stosowanymi w firmie oraz innymi planami w ogólnym portfelu zmian. Wreszcie Faza F zapewnia, że kluczowi interesariusze w pełni rozumieją wartość biznesową, koszt pakietu roboczego oraz architekturę przejściową i przyszłą. Chociaż wczesne etapy ADM są bardzo prowadzone przez zespół architektury przedsiębiorstwa, etap od E do H wymaga współpracy z innymi agentami zmian.
Faza F szczególnie wymaga bliskiej współpracy między czterema ramami zarządzania, aby uczynić plan wdrożenia i przesiedlenia sukcesem.
Cztery obszary to:
- plan biznesowy
- Architektura przedsiębiorstwa
- Zarządzanie portfelem
- zarządzanie projektem
Poprzez współpracę, te cztery obszary muszą priorytetowo traktować pracę, używając kryteriów takich jak ocena wydajności, zwrot z inwestycji, wartość biznesowa, kluczowe czynniki sukcesu, pomiar efektywności i dopasowanie strategiczne.
Etap G: Wdrożenie zarządzania:
Rzeczywisty rozwój i wdrożenie odbywa się równolegle z fazą G. Faza G zapewnia, że projekt wdrożeniowy i inne trwające projekty są zgodne z określoną architekturą.
Zazwyczaj docelowa architektura jest rozwijana jako seria transformacji, aby jak najszybciej osiągnąć wartość biznesową i korzyści oraz zminimalizować ryzyko w planie transformacji. Każda transformacja jest krokiem w kierunku docelowej firmy, aby zrealizować jej własne interesy biznesowe.
Do momentu osiągnięcia fazy G, architektura została opracowana (w fazach A do D), zidentyfikowano możliwości i rozwiązania do dostarczenia architektury (w fazie E), a szczegółowe plany wdrożenia i migracji zostały ukończone (w fazie F). Tak więc, rolą zespołu architektury fazy G jest zapewnienie nadzoru nad wdrożeniem architektury. Osiąga się to poprzez weryfikację zakresu i priorytetów wdrożenia, kierowanie rozwojem i wdrożeniem rozwiązań oraz przeprowadzanie przeglądów zgodności.
Dokumenty umowy architektonicznej są używane do wprowadzania zmian w architekturze. Wytwarzane na początku fazy G i zatwierdzane przez funkcjonalność architektury oraz osoby odpowiedzialne za wdrożenie, stanowią mechanizm oceny zgodności zarządzania architekturą.
Faza H: Zarządzanie zmianą struktury:
Nic nie poszło zgodnie z planem – zawsze będą nowe wymagania i zmiany w architekturze. Faza H opisuje proces zarządzania zmianami, aby zarządzać zmianami w architekturze w spójny i uporządkowany sposób. Zazwyczaj wymaga to ciągłego monitorowania wniosków dotyczących zarządzania, nowych technologii lub zmian w otoczeniu biznesowym.
Proces powinien wspierać zrealizowaną architekturę przedsiębiorstwa jako dynamiczne środowisko, które może elastycznie reagować na te zmiany i szybko się rozwijać. W fazie H ważne jest, aby organ zarządzający ustalił standardy, aby określić, czy wniosek o zmianę wymaga prostego zaktualizowania architektury, czy też wymaga zainicjowania nowego cyklu metody rozwoju architektury (ADM). Zmiany muszą być bezpośrednio związane z wartością biznesową. Jak wykorzystać architekturę przedsiębiorstwa jest najważniejszą częścią cyklu rozwoju architektury, dlatego kluczowe jest monitorowanie wzrostu i spadku biznesu w fazie H.
Na koniec, architektura przedsiębiorstwa, która działała dla organizacji wczoraj, już nie wspiera bieżących ani przyszłych funkcji. Wynik wniosku o zmianę w fazie H można sklasyfikować jako uproszczenie – zazwyczaj podyktowane wymogiem redukcji inwestycji; zmiana inkrementalna – wymagająca dodatkowej wartości z istniejącej inwestycji; lub zmiana redesignu, która jest wymogiem zwiększenia inwestycji i stworzenia nowej wartości.
Zarządzanie wymaganiami architektury:
Na każdym etapie ADM wymagane są wymagania dotyczące generacji, analizy i przeglądu. Faza zarządzania wymaganiami opisuje proces zarządzania tymi wymaganiami architektonicznymi w całym ADM. Faza zarządzania wymaganiami jest rdzeniem ADM – dlatego jest pokazana w centrum kręgu upraw ADM. Ten etap opisuje proces zarządzania wymaganiami i jak proces ten jest powiązany z innymi etapami ADM. Wymagania nie są statyczne – dynamicznie ewoluują między każdym etapem naszego zakończenia ADM i cyklem ADM.
Wymagania architektury przedsiębiorstwa oraz późniejsze zmiany tych wymagań będą identyfikowane, przechowywane oraz związane z fazami ADM i między cyklami ADM. Radzenie sobie ze zmianami w popycie jest kluczowe. Architektura radzi sobie z niepewnością i zmianą – „szara strefa” między oczekiwaniami interesariuszy a możliwościami! Dlatego wymagania architektoniczne zawsze będą się zmieniać.
Ponadto architektura obejmuje wiele czynników napędzających i ograniczeń, które są poza kontrolą przedsiębiorstwa – takich jak zmieniające się warunki rynkowe czy nowe przepisy prawne – które w nieprzewidywalny sposób wprowadzą zmiany w wymaganiach.
TOGAF podkreśla, że proces zarządzania wymaganiami sam w sobie nie zajmie się, nie rozwiąże ani nie ustali priorytetów wymagań, ponieważ odbywa się to w odpowiedniej fazie ADM. Etap zarządzania popytem to tylko proces zarządzania wymaganiami w całym ADM.
Wstępna faza ADM
Przygotowanie i działania inicjujące wymagane do stworzenia zdolności architektonicznej, w tym dostosowanie TOGAF i definicja architektury
Wyniki dostarczane:
- Zasady architektury
- Repozytorium architektury
- Zasady biznesowe, cele biznesowe i czynniki napędzające biznes
- Model organizacji dla architektury przedsiębiorstwa
- Wniosek o prace architektoniczne
- Dostosowana struktura architektury
Faza A ADM: Wizja architektury
Początkowa faza cyklu rozwoju architektury. Zawiera informacje o definiowaniu zakresu inicjatywy rozwoju architektury, identyfikacji interesariuszy, tworzeniu wizji architektury oraz uzyskaniu zgody na kontynuację rozwoju architektury.
Wyniki dostarczane:
- Zasady architektury
- Mapa drogowa architektury
- Wizja architektury
- Zasady biznesowe, cele biznesowe i czynniki napędzające biznes
- Ocena zdolności
- Plan komunikacji
- Oświadczenie o pracach architektonicznych
- Dostosowana struktura architektury
Faza B ADM: Architektura biznesowa
Architektura biznesowa: rozwój architektury biznesowej wspierającej uzgodnioną wizję architektury
Wyniki dostarczane:
- Dokument definicji architektury
- Zasady architektury
- Specyfikacja wymagań architektury
- Mapa drogowa architektury
- Zasady biznesowe, cele biznesowe i czynniki napędzające biznes
- Oświadczenie o pracach architektonicznych
Faza C ADM: Architektura systemów informacyjnych
Architektury systemów informacyjnych: rozwój architektur systemów informacyjnych wspierających uzgodnioną wizję architektury
- Dokument definicji architektury
- Zasady architektury
- Specyfikacja wymagań architektury
- Mapa architektury
- Oświadczenie o pracach architektonicznych
Faza D ADM: Architektura technologii
Architektura technologii: rozwój architektury technologii w celu wsparcia uzgodnionej wizji architektury
Wyniki dostarczane:
- Dokument definiujący architekturę
- Zasady architektury
- Specyfikacja wymagań architektonicznych
- Mapa architektury
- Oświadczenie o pracach architektonicznych
Faza E ADM: Możliwości i rozwiązania
Możliwości i rozwiązania przeprowadzają wstępne planowanie wdrożenia oraz identyfikację środków dostawy dla architektury zdefiniowanej w poprzednich fazach
Wyniki dostarczane:
- Dokument definiujący architekturę
- Specyfikacja wymagań architektonicznych
- Mapa architektury
- Wizja architektury
- Ocena zdolności
- Plan wdrożenia i migracji
- Oświadczenie o pracach architektonicznych
Faza F ADM: Planowanie migracji
Planowanie migracji dotyczy sposobu przejścia od architektury bazowej do docelowej poprzez sfinalizowanie szczegółowego planu wdrożenia i migracji
- Bloki budowlane architektury
- Dokument definiujący architekturę
- Specyfikacja wymagań architektonicznych
- Mapa architektury
- Wniosek o zmianę planu wdrożenia i migracji
- Plan zarządzania wdrożeniami
- Wniosek o prace architektoniczne
- Oświadczenie o pracach architektonicznych
Faza G ADM: Zarządzanie wdrożeniem
Zarządzanie wdrożeniem zapewnia nadzór architektoniczny nad wdrożeniem
Wyniki dostarczane:
- Wniosek o zmianę
- Ocena zgodności
- Bloki budowlane rozwiązania
- Oświadczenie o pracach architektonicznych
Faza H ADM: Zarządzanie zmianą architektury
Zarządzanie zmianą architektury ustala procedury zarządzania zmianą w nowych wymaganiach architektonicznych. Zarządzanie wymaganiami bada proces zarządzania wymaganiami architektonicznymi w całym ADM
Podsumowanie
ADM jest kompleksową ogólną metodą
- Zaleca sekwencję różnych faz i kroków zaangażowanych w rozwój architektury
- Jest to metoda iteracyjna
- Czerpie z innych części TOGAF dotyczących zasobów i procesów
- Może być używane z innymi wynikami z innych ram
Oto przegląd ADM TOGAF dla każdej z faz rozwoju, jak pokazano na poniższym rysunku:


- Więcej o przewodniku TOGAF ADM
- Więcej o szablonach TOGAF Just-in-Time
- Więcej o narzędziach ArchiMate
- Wypróbuj Visual Paradigm ZA DARMO
Wprowadzenie do TOGAF
- Czym jest TOGAF?
- Samouczek TOGAF ADM
- TOGAF 9.1 Framework – Kompletny przewodnik
- Oprogramowanie TOGAF dla architektury korporacyjnej
- Najlepsze oprogramowanie TOGAF
ArchiMate 3
- Czym jest ArchiMate?
- Pełny przewodnik po punktach widzenia ArchiMate
- Aktualizacja ArchiMate 3
- Co nowego w ArchiMate 3?
- Używanie narzędzia ArchiMate z TOGAF ADM
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文