TOGAF jest otwartą strukturą organizacyjną. Sama struktura jest dobrze udokumentowanym zbiorem wiedzy, obejmującym szczegółową metodologię oraz zestaw narzędzi wspierających rozwój architektur przedsiębiorstw. TOGAF 9.2 to najnowsza wersja tej struktury.
- TOGAF jest rozwijany i utrzymywany przez członków The Open Group, pracujących w zespole zwanym Architecture Forum. Początkowy rozwój wersji 1 TOGAF miał miejsce w 1995 roku, a kolejne wersje TOGAF rozszerzyły i poprawiły ten zbiór wiedzy.
- TOGAF został opracowany dzięki wspólnym wysiłkom ponad 300 członków Architecture Forum, reprezentujących niektóre z wiodących firm i organizacji na świecie – dlatego jest doskonałym 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 przedsiębiorstwa, 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 uwzględnia bieżące potrzeby oraz przyszłe postrzegane potrzeby biznesowe.
Czym jest ADM?
Metodologia Rozwoju Architektury – często określana jako akronim ADM – to szczegółowy proces krok po kroku dotyczący rozwijania lub zmiany architektury przedsiębiorstwa.
ADM opisuje 10 faz obejmujących cykl rozwoju architektury.
Te kroki to:
- etap wstępny
- Faza A: Wizja Architektury
- Faza B: Architektura Biznesowa
- Faza C: Architektura Systemów Informacyjnych
- Faza D: Architektura Techniczna
- Faza E: Możliwości i Rozwiązania
- Faza F: Planowanie Migracji
- Faza G: Wdrażanie Zarządzania
- Faza H: Zarządzanie Zmianą Architektury
- Zarządzanie Wymaganiami Architektury ADM
Etap wstępny:
Głównym celem etapu wstępnego jest zidentyfikowanie i ustalenie zdolności architektonicznych wymaganych przez organizację.
Kluczowym elementem tego jest zidentyfikowanie, co należy zrobić i jak to wdrożyć.Na przykład, głównym wynikiem jest wniosek o prace architektoniczne 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 dostosowywany do potrzeb nadchodzącej iteracji ADM. Definiujemy fundamentalne zasady, oceniamy zdolność architektury przedsiębiorstwa i biznesu do wprowadzenia wymaganych zmian oraz integrujemy TOGAF z innymi ramami zarządzania. W tej fazie są kroki mające na celu ograniczenie organizacji przedsiębiorstwa dotkniętej proponowaną zmianą, zidentyfikowanie odpowiednich ram zarządzania i wsparcia, zdefiniowanie i ustanowienie zespołu EA oraz organizacji, zidentyfikowanie i ustanowienie zasad architektonicznych, dostosowanie TOGAF i innych ram oraz wdrożenie narzędzi. Na koniec tej fazy zespół EA powinien być gotowy do podjęcia 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 architektoniczne oświadczenie o pracy, które będzie realizowane w iteracjach ADM. Dostarcza również wizji proponowanej architektury przedsiębiorstwa. To poczucie kierunku jest kluczowe w kierowaniu pracą ADM przez całą iterację. To oświadczenie o pracy architektonicznejokreśla procedury pracy dotyczące rozwijania i wdrażania architektury określonej w wizji architektonicznej. To wizja, która dostarcza wysokiego poziomu pragnienia dla zdolności i wartości biznesowej, które proponowana architektura przedsiębiorstwa zapewni. Zaczynając od wniosku o pracę budowlaną, Faza A dostarcza narzędzie (tę wizję), aby sprzedać korzyści z proponowanej zdolności interesariuszom i decydentom w firmie. Scenariusze biznesowe są używane do zrozumienia wymagań biznesowych i pomagają wyjaśnić wymagania architektoniczne implikowane przez wymaganą funkcjonalność. Jest to dokumentowane w Oświadczeniu o Pracy Architektonicznej, które jest używane do budowania konsensusu w celu wsparcia ostatecznej architektury. Konsensus występuje, gdy organizacja sponsorująca podpisuje dokument.
Kroki w Fazie A dotyczą przekształcania wniosku o prace budowlane w jasne oświadczenie o pracy architektonicznej oraz zapewnienia, że firma jest w stanie, gotowa, chętna i zobowiązana do wprowadzenia niezbędnych zmian architektonicznych. Obejmuje to ustanowienie projektu architektury, w tym zdefiniowanie jego zakresu, a także zidentyfikowanie i rozwinięcie zasad architektonicznych i biznesowych. Faza A identyfikuje interesariuszy oraz ich obawy i wymagania, a także identyfikuje cele biznesowe, czynniki i ograniczenia w etapie wstępnym. Aby zapewnić sukces, ocenia również zdolności biznesowe, ocenia gotowość do transformacji biznesowej i zajmuje się wszelkimi ryzykami transformacyjnymi.
Faza B: Architektura Biznesowa:
TOGAF przyjmuje architekturę przedsiębiorstwa jako sposób na poprawę zdolności biznesowych – dlatego pierwsza faza rozwoju architektury dotyczy architektury biznesowej .
ADM zaczyna od perspektywy biznesowej – silne wymagania biznesowe są identyfikowane w Wniosku o Prace Architektoniczne w Etapie Wstępnym i dalej dopracowywane w Pracach Architektonicznych oraz Wizji Architektury Oświadczeniu w Fazie A.
Kluczowym celem fazy architektury biznesowej jest opracowanie docelowej architektury biznesowej, która pokazuje, jak przedsiębiorstwo realizuje wizję architektury i odpowiada na wnioski o prace architektoniczne. Jej drugim celem jest najpierw zidentyfikowanie komponentów mapy drogowej architektury, które mają na celu wypełnienie luki między architekturą bazową a docelową architekturą biznesową. TOGAF uważa wiedzę na temat architektury biznesowej za warunek wstępny dla prac architektonicznych w innych dziedzinach, takich jak dane, aplikacje i technologia. Architektura biznesowa pokazuje również wartość biznesową i zwrot z inwestycji w wysiłek architektoniczny dla kluczowych interesariuszy. modele biznesowe, takie jak modele aktywności lub procesów, modele przypadków użycia i klas, czy diagramy połączeń węzłów,
Podobne kroki są stosowane we wszystkich trzech fazach rozwoju architektury (B, C i D). Ważne jest, aby ponownie wykorzystać dostępne modele referencyjne i dostosować wszystkie wyniki do perspektyw interesariuszy. Architekt następnie opracowuje opis architektury biznesowej w wersji bazowej i docelowej oraz przeprowadza analizę luk, aby określić, jak przejść z jednej do drugiej.
Faza C: Architektura Systemów Informacyjnych:
TOGAF dzieli Fazę C – Architektura Systemów Informacyjnych – na dwie części, obejmujące rozwój danych i aplikacja architektury. Dokumentacja TOGAF zawiera krótki rozdział wprowadzający, który obejmuje oba obszary, a następnie osobne rozdziały dotyczące danych i aplikacji. Podobnie jak w przypadku innych faz rozwoju architektury (B&D), celem jest opracowanie docelowej architektury systemu informacyjnego dla danych i aplikacji oraz zidentyfikowanie komponentów mapy architektury na podstawie luk między architekturami bazowymi a docelowymi.
Faza C zawsze obejmuje połączenie architektury danych i aplikacji. Nie ma znaczenia, w jakiej kolejności są one dostarczane, byleby obie były uwzględnione – są zwolennicy obu podejść. Kroki dla danych i aplikacji są bardzo podobne – wybór modeli referencyjnych, punktów widzenia i narzędzi; opracowanie bazy, a następnie zlokalizowanie opisu architektury, przeprowadzenie analizy luk i zdefiniowanie komponentów mapy kandydatów; oraz uwzględnienie wszelkich wpływów w kontekście architektonicznym. Po formalnej recenzji interesariuszy architektura została sfinalizowana, a dokument definicji architektury został stworzony.
Główna różnica między danymi a aplikacjami dotyczy przedmiotu, co znajduje odzwierciedlenie w użyciu różnych modeli referencyjnych, technik i reprezentacji architektonicznych. Na przykład architektura danych może korzystać z diagramów encji i relacji lub diagramów klas, podczas gdy architektura aplikacji może korzystać z 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), umożliwiając komponenty biznesowe.
Architektury opracowane w fazach B, C i D łączą się, aby zrealizować wizję architektoniczną – odpowiadając na obawy interesariuszy i prośby o prace budowlane. Podobnie jak w innych fazach rozwoju architektury, Faza D identyfikuje komponenty mapy architektury kandydatów, aby umożliwić przejście z poziomu bazowego do docelowego. Kroki w Fazie D są prawie identyczne z tymi w fazach B i 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ść utrzymania, lokalizacja oraz opóźnienie lub dostępność.
Ważne jest, aby zidentyfikować wyniki i dostarczane produkty, aby pomóc w budowie architektury technicznej, która naprawdę wspiera system informacyjny i architekturę biznesową. Odpowiedni zakres może przyspieszyć zwrot z inwestycji, podczas gdy zbyt duży zakres utrudni pomyślną realizację. Nie chodzi o wdrażanie samej technologii, ale o rozwijanie architektury technicznej, która naprawdę odpowiada wizji architektonicznej i prośbom o pracę.
Faza E: Możliwości i rozwiązania:
Faza E otrzymuje swoją nazwę – szuka możliwości dostarczenia docelowej architektury poprzez wdrożenie konkretnego rozwiązania. Faza E generuje pierwszą pełną wersję mapy architektury, łącząc analizy i rekomendacje faz rozwoju budynku – B, C i D.
Ta faza koncentruje się na tym, jak dostarczyć schemat. Dlatego zajmuje się tworzeniem mapy 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 architektury bazowej do docelowej, Faza E skutkuje podejściem inkrementalnym, składającym się z architektur pośrednich lub przejściowych. Faza E mapuje wymagane zmiany architektoniczne do programów inwestycyjnych i projektów z finansowaniem i zasobami do realizacji pakietów roboczych oraz dostarczenia architektur przejściowych i docelowych. Wejściem do tego etapu jest praktycznie wszystko, co zostało wyjściem z wcześniejszych etapów. Te kroki biorą te wyniki; konsolidują je, analizują zależności i godzą różnice; oraz potwierdzają, że organizacja jest zdolna do wprowadzania zmian. Faza E udoskonala i aktualizuje wymagania, dokumentację architektoniczną oraz mapę architektury. Kluczowym wynikiem jest pierwszy krok w planie wdrożenia i migracji.
Faza F: Planowanie migracji:
Wczesne etapy ADM identyfikują potrzebę zmian architektonicznych, a następnie rozwijają architektury biznesowe, danych, aplikacji i techniczne, aby wspierać tę potrzebę. Druga faza rozwija następnie architekturę na wysokim poziomie plan wdrożenia i migracji aby wykorzystać możliwości inwestycyjne i zidentyfikować konkretne rozwiązania. docelowa architektura. Faza F finalizuje szczegółowy plan wdrożenia i migracji, a także ostateczną mapę architektury.
Zapewnia również, że plan jest zgodny z podejściem do zarządzania zmianami stosowanym w przedsiębiorstwie oraz z innymi planami w ramach portfela zmian. Wreszcie Faza F zapewnia, że kluczowi interesariusze w pełni rozumieją wartość biznesową, koszt pakietu roboczego oraz architekturę przejściową i przyszłą. Podczas gdy wczesne etapy ADM są w dużej mierze kierowane przez zespół architektury korporacyjnej, etapy od E do H wymagają współpracy z innymi agentami zmian. Faza F szczególnie wymaga, aby cztery ramy zarządzania ściśle współpracowały, aby program wdrożenia i przesiedlenia był udany. Cztery obszary to:
- plan biznesowy
- Architektura korporacyjna
- Zarządzanie portfelem
- zarządzanie projektem
Wspólnie te cztery obszary muszą priorytetyzować pracę, korzystając z kryteriów takich jak pomiar wydajności, zwrot z inwestycji, wartość biznesowa, krytyczne czynniki sukcesu, miary efektywności i dopasowanie strategiczne.
Faza G: Wdrażanie zarządzania:
Rzeczywisty rozwój i wdrożenie odbywa się równolegle z Fazą G. Faza G zapewnia, że projekt wdrożeniowy, a także inne trwające projekty, są zgodne z określoną architekturą.
Zazwyczaj docelowa architektura jest rozwijana jako seria przejść, aby jak najszybciej zrealizować wartość biznesową i korzyści oraz zredukować ryzyko w planie transformacji. Każda transformacja reprezentuje krok w kierunku docelowej firmy i realizuje własne interesy biznesowe.
Kiedy osiągamy Fazę G, architektura została opracowana (w Fazie A do Fazy D), zidentyfikowano możliwości i rozwiązania do dostarczenia architektury (w Fazie E), a szczegółowy plan wdrożenia i migracji został ukończony (w Fazie F). Dlatego rolą zespołu architektury Fazy G jest zapewnienie nadzoru nad wdrożeniem architektury. Odbywa się to poprzez potwierdzenie zakresu i priorytetu wdrożenia, kierowanie rozwojem i wdrażaniem rozwiązań oraz przeprowadzanie przeglądów zgodności. Dokumenty umowy architektonicznej są wykorzystywane do wprowadzania zmian architektonicznych. Wygenerowane na początku Fazy G i zatwierdzone przez funkcję architektury oraz osoby odpowiedzialne za wdrożenie, stanowią mechanizm oceny zgodności z zarządzaniem architekturą.
Faza H: Zarządzanie zmianami architektury:
Nic nie idzie dokładnie zgodnie z planem – zawsze będą nowe wymagania i potrzeby zmiany architektury. Faza H opisuje proces zarządzania zmianami, aby zarządzać zmianami w architekturze w spójny i architektoniczny sposób. Często wymaga to ciągłego monitorowania próśb o zarządzanie, nowych technologii lub zmian w otoczeniu biznesowym.
Proces powinien wspierać wdrożoną architekturę korporacyjną jako dynamiczne środowisko, które może elastycznie ewoluować szybko w odpowiedzi na te zmiany. W Fazie H kluczowe jest, aby organ zarządzający ustalił kryteria oceny, czy prośba o zmianę wymaga prostego aktualizacji architektury, czy też należy zainicjować nowy cykl Metody Rozwoju Architektury (ADM). Ważne jest, aby unikać „łagodnego pełzania”, więc zmiany muszą być bezpośrednio związane z wartością biznesową. Jak wykorzystywana jest architektura korporacyjna, jest najważniejszą częścią cyklu rozwoju architektury, więc monitorowanie wzrostu i spadku biznesu w Fazie H jest kluczowe. Ostatecznie architektura korporacyjna, która działała dla organizacji wczoraj, już nie wspiera obecnej ani przyszłej funkcjonalności. Wyniki próśb o zmiany z Fazy H można sklasyfikować jako uproszczenie – zazwyczaj napędzane potrzebą redukcji inwestycji; zmiana inkrementalna – wymagana do uchwycenia dodatkowej wartości z istniejącej inwestycji; lub zmiana redesignu, która jest napędzana potrzebą zwiększenia inwestycji i stworzenia nowej wartości.
Zarządzanie wymaganiami architektonicznymi:
Wymagania są generowane, analizowane i przeglądane na każdym etapie ADM. Faza zarządzania wymaganiami opisuje proces zarządzania tymi wymaganiami architektonicznymi w całym ADM. Faza zarządzania wymaganiami jest sercem ADM – dlatego jest pokazana w centrum Okręgu Klipowego ADM. Ta faza opisuje proces zarządzania wymaganiami i jak ten proces łączy się z innymi fazami ADM. Wymagania nie są statyczne – ewoluują dynamicznie, gdy kończymy każdy etap ADM i między cyklami ADM. Wymagania architektury korporacyjnej oraz późniejsze zmiany tych wymagań będą identyfikowane, przechowywane oraz związane z wejściem i wyjściem w odniesieniu do faz ADM oraz między cyklami ADM. Radzenie sobie ze zmianami popytu jest kluczowe. Architektura zajmuje się niepewnością i zmianą – „szara strefa” między oczekiwaniami interesariuszy a możliwościami! Dlatego wymagania architektoniczne są zawsze podatne na zmiany. Ponadto architektura wiąże się z wieloma czynnikami i ograniczeniami, które są poza kontrolą biznesu – takimi jak zmieniające się warunki rynkowe czy nowe przepisy – które mogą w nieprzewidywalny sposób powodować zmiany w popycie. TOGAF podkreśla, że proces zarządzania wymaganiami sam w sobie nie zajmuje się, nie rozwiązuje ani nie priorytetyzuje wymagań, ponieważ odbywa się to w odpowiedniej fazie ADM. Faza zarządzania wymaganiami to po prostu proces zarządzania wymaganiami w całym ADM. Dlatego wymagania architektoniczne są zawsze podatne na zmiany. Ponadto architektura wiąże się z wieloma czynnikami i ograniczeniami, które są poza kontrolą biznesu – takimi jak zmieniające się warunki rynkowe czy nowe przepisy – które mogą w nieprzewidywalny sposób powodować zmiany w popycie. TOGAF podkreśla, że proces zarządzania wymaganiami sam w sobie nie zajmuje się, nie rozwiązuje ani nie priorytetyzuje wymagań, ponieważ odbywa się to w odpowiedniej fazie ADM. Faza zarządzania wymaganiami to po prostu proces zarządzania wymaganiami w całym ADM. Dlatego wymagania architektoniczne są zawsze podatne na zmiany. Ponadto architektura wiąże się z wieloma czynnikami i ograniczeniami, które są poza kontrolą biznesu – takimi jak zmieniające się warunki rynkowe czy nowe przepisy – które wszystkie powodują zmiany w popycie w nieprzewidywalny sposób. TOGAF podkreśla, że proces zarządzania wymaganiami sam w sobie nie zajmuje się, nie rozwiązuje ani nie priorytetyzuje wymagań, ponieważ odbywa się to w odpowiedniej fazie ADM. Faza zarządzania wymaganiami to po prostu proces zarządzania wymaganiami w całym ADM. TOGAF podkreśla, że proces zarządzania wymaganiami sam w sobie nie zajmuje się, nie rozwiązuje ani nie priorytetyzuje wymagań, ponieważ odbywa się to w odpowiedniej fazie ADM. Faza zarządzania wymaganiami to po prostu proces zarządzania wymaganiami w całym ADM.
(*Źródło: TOGAF ADM: Co to jest i dlaczego jest tak ważne?)
TOGAF
- Czym jest TOGAF?
- Samouczek TOGAF ADM
- TOGAF 9.1 Framework – Kompleksowy 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 繁體中文