Zastosowanie TOGAF do definiowania i nadzoru architektury zorientowanej na usługi (SOA) Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl
Cel prezentacji Wariant optymistyczny: przekonanie Państwa, że warto wykonaćwysiłek organizacyjny w zakresie usystematyzowanego wdrażania SOA. Wariant realistyczny: zaprezentowanie listy czynników, które należy rozważyć budując rejestr ryzyk w przedsięwzięciu dotyczącym wdrażania SOA. Wariant pesymistyczny: przedstawienie dobrych praktyk w zakresie wdrażania SOA w organizacji.
Cel prezentacji Wariant optymistyczny: przekonanie Państwa, że warto wykonaćwysiłek organizacyjny w zakresie usystematyzowanego wdrażania SOA. Wariant realistyczny: zaprezentowanie listy czynników, które należy rozważyć budując rejestr ryzyk w przedsięwzięciu dotyczącym wdrażania SOA. Wariant pesymistyczny: przedstawienie dobrych praktyk w zakresie wdrażania SOA w organizacji.
Cel prezentacji Wariant optymistyczny: przekonanie Państwa, że warto wykonaćwysiłek organizacyjny w zakresie usystematyzowanego wdrażania SOA. Wariant realistyczny: zaprezentowanie listy czynników, które należy rozważyć budując rejestr ryzyk w przedsięwzięciu dotyczącym wdrażania SOA. Wariant pesymistyczny: przedstawienie dobrych praktyk w zakresie wdrażania SOA w organizacji.
Plan prezentacji Zamiast wstępu: Usystematyzowanie relacji pomiędzy kluczowymi pojęciami na styku architektury korporacyjnej, TOGAF i SOA TOGAF jako metodyka wdrażania SOA w dużych organizacjach Etapy realizacji SOA zgodne z TOGAF ADM Adaptacja metamodelu TOGAF 9 w kontekście SOA Pomiar dojrzałości organizacji w obszarze SOA Podsumowanie
Usystematyzowanie relacji pomiędzy kluczowymi pojęciami na styku architektury korporacyjnej, TOGAF i SOA Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl
The Open Group The Open Group jest międzynarodowym, niezależnym i nie związanym z konkretnymi technologiami konsorcjum, którego kluczowy zadaniem jest tworzenie standardów przemysłowych IT na zasadzie konsensusu. Wizja The Open Group: Przepływ informacji bez barier: umożliwiający dostęp do zintegrowanej informacji, wewnątrz i pomiędzy organizacjami, bazujący na otwartych standardach.
TOGAF The Open Group Architecture Framework Usystematyzowane podejście do tworzenia architektury (korporacyjnej) w dowolnym typie i wielkości organizacji. Niezależne od dostawców, powstałe na drodze konsensusu, wypracowywanego pomiędzy jego użytkownikami. Zawierające rygorystycznąmetodętworzenia Architektury (Architecture Development Method ADM), która pozwala na zaprojektowanie i zrealizowaniearchitektury dedykowanej konkretnej organizacji. Przedstawia zestaw pojęć, standardów, modeli referencyjnych, metody i technik związanych z budową architektury (korporacyjnej).
korporacyjna 1. korporacyjna formalny opis struktury funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypia i wytyczne odnośnie do zarządzania projektowaniem i zmianą tych komponentów w czasie.
korporacyjna 1. korporacyjna formalny opis struktury funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypia i wytyczne odnośnie do zarządzania projektowaniem i zmianą tych komponentów w czasie. 2. korporacyjna dyscyplina z pogranicza zarządzania i IT zajmująca się projektowaniem komponentów korporacji i nadzorowania ich realizacji.
SOA SOA styl architektoniczny realizujący podejście/myślenie usługowe w całejorganizacji (a nie tylko w obszarze IT); stanowi on możliwy sposób realizacji określonego zakresu architektury korporacyjnej.
Relacje pomiędzy pojęciami The Open Group TOGAF korporacyjna SOA Twórca narzędzia Narzędzie Produkt pośredni zastosowania narzędzia Sposób realizacji części architektury korporacyjnej
Stos metodyczny The Open Group w obszarze architektury korporacyjnej i SOA The Open Group Guide The Open Group Technical Standard The Open Group Technical Standard The Open Group Technical Standard The Open Group Technical Standard The Open Group Technical Standard Using TOGAF to Define and Govern Service- Oriented Architectures The Open Group Service Integration Maturity Model SOA Governance Framework Service-Oriented Architecture Ontology SOA Reference Architecture Service Oriented Infrastructure
TOGAF jako metodyka wdrażania SOA w dużych organizacjach Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl
Kontekst: struktura TOGAF
Struktura TOGAF a ADM Ramy potencjału architektonicznego ` (część VII) Metoda Budowy Architektury (część II) Przewodniki i techniki ADM (część III) ADM Ramy zawartości architektonicznej (część IV) Kontinuum korporacyjne i narzędzia (część V) Modele referencyjne TOGAF (część VI)
Cykl ADM Cykl ADM (Architecture Development Method) cykl tworzenia i rozwoju dowolnejarchitektury (w tym korporacyjnej) składający się z serii następujących po sobie faz, z których każda składa sięz pewnej liczby kroków. Cykl ADM zakłada iteracyjne podejście Iteracyjność całych cykli Iteracyjność wewnątrz cyklu Iteracyjność wewnątrz faz G Nadzór nad implementacją H Zarządzanie zmianą architektury F Planowanie migracji A Wizja architektury Zarządzanie wymaganiami E Możliwości i rozwiązania Faza wstępna B biznesowa D techniczna C danych i aplikacji
Cykl ADM filozofia opisu fazy Produkty wejściowe Faza Krok 1 Krok 2 Krok Krok n Produkty wyjściowe Produkty dzielimy na: architektoniczne i niearchitektonicznie. Uwaga: TOGAF nie definiuje CRUD na poziomie produktów.
Cykl ADM filozofia opisu fazy Model organizacyjny architektury korporacyjnej Dopasowane ramy architektoniczne Pryncypia aplikacji Oświadczenie o pracy architektonicznej Wizja architektury Repozytorium architektoniczne Szkic dokumentu definiującego architekturę Szkic specyfikacji wymagań architektonicznych Komponenty architektury biznesowej i danych z architektonicznej mapy drogowej Żądanie pracy architektonicznej Wybór modeli referencyjnych, technik modelowania, określenie punktów widzenia Stworzenie architektury bazowej Stworzenie architektury docelowej Wykonanie analizy luk Zdefiniowanie mapy drogowej komponentów Zdefiniowanie wpływu prac na krajobraz architektoniczny organizacji Przeprowadzenie przeglądu z interesariuszami Sfinalizowanie prac architektonicznych Stworzenie dokumentu definiującego architekturę Udoskonalone i zaktualizowane wersje produktów pochodzących z fazy Wizja Architektury (tam, gdzie ma to zastosowanie) Dokument definiujący architekturę Specyfikacja wymagań architektonicznych Komponenty architektoniczne umieszczone na mapie drogowej
Uwagi metodyczne TOGAF dopuszcza, aby w kontrolowany sposób: Zmieniać kolejność realizacji faz Łączyćfazy ze sobą Zmieniać kolejność kroków wewnątrz każdej z faz Łączyćkroki wewnątrz faz Pomijać kroki wewnątrz fazy Kroki wewnątrz faz proponuje siępotraktowaćjako swego rodzaju check-listę do analizy czy wykonano określone działania, a jeżeli nie, to czy ich pominięcie było świadome.
Faza wstępna G Nadzór nad implementacją H Zarządzanie zmianą architektury F Planowanie migracji A Wizja architektury Zarządzanie wymaganiami E Możliwości i rozwiązania Faza wstępna B biznesowa D techniczna C danych i aplikacji W fazie wstępnej następuje określenie sposobu w jaki SOA będzie realizowana w ramach organizacji, co obejmuje: Ustanowienie kontekstu biznesowego wprowadzenia SOA Pozyskanie wsparcia Sponsora Zmierzenie dojrzałości usługowej organizacji Ustanowienie struktury zarządzania SOA Zdefiniowanie pryncypiów dotyczących SOA Wdrożenie repozytorium, umożliwiającego tworzenie modeli architektonicznych. SLAJD 21 of 24
Faza wstępna ustanowienie kontekstu biznesowego i pozyskanie sponsora Kontekst biznesowy TOGAF nie podaje metody obliczenia ROI z wdrażania podejścia architektonicznego, w tym w szczególności SOA. Rozwiązania alternatywne
Faza wstępna ustanowienie kontekstu biznesowego i pozyskanie sponsora Sponsor prac architektonicznych TOGAF wskazuje szczególnąrolęsponsora prac architektonicznych i jego umiejscowienia w organizacji. Zgodnie z TOGAF dobrym kandydatem na sponsora jest wiceprezes ds. operacyjnych, wiceprezes ds. innowacji itp. Zgodnie z TOGAF nie najlepszym kandydatem na sponsora jest wiceprezes ds. IT.
Struktura TOGAF a model dojrzałości Model dojrzałości
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model) Możliwość otrzymania jedno jak i wielowymiar owej oceny dojrzałości
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model) Ujęcie statystyczne modelu: 7 poziomów dojrzałości 7 wymiarów oceny 7 badanych czynników dojrzałości Blisko 90 pytań ewaluacyjnych Blisko 140 atrybutów do oceny dojrzałości SLAJD 26 of 24
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model)
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model) Pytania Kwestionariusz ew. cz. I Kwestionariusz ew. cz. II
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model)
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model)
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model) Pytania Kwestionariusz ew. cz. I Kwestionariusz ew. cz. II
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model)
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model)
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model)
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model) Wyniki przeglądu dla przykładowej organizacji
Faza wstępna model dojrzałości (The Open Group Service Integration Maturity Model) Wyniki przeglądu dla przykładowej organizacji
Struktura TOGAF a model dojrzałości Ład SOA
Pojęcie ładu architektonicznego Ład architektoniczny system (mechanizm) za pomocąktórego ustanawiany jest zbiór celów tworzenia architektury (w tym np. SOA) oraz środków, poprzez które możliwe jest osiąganie tych celów i monitorowanie wydajności ich realizacji. Relacje z innymi metodykami i podejściami aplikacji Pomiary Struktura organizacyjna, role i odpowiedzialności techniczna Wymagania biznesowe biznesowa danych Pryncypia, polityki i standardy Zarządcze procesy architektonicze
Faza wstępna ramy ładu architektonicznego w ujęciu TOGAF Ład korporacyjny Ład IT Ład architektoniczny
Faza wstępna ramy ładu architektonicznego w kontekście SOA
Faza wstępna ramy ładu architektonicznego Procesy architektoniczne związane z SOA Proces wprowadzania usługi do organizacji Proces zarządzania zmianą usługi Proces wycofania usługi. Artefakty architektoniczne związane z SOA Katalog standardów architektonicznych Katalog usług biznesowych (+SLA) Katalog usług aplikacyjnych (+SLA) Macierz usług biznesowych i procesów biznesowych Diagram rozmieszczenia usług.
Faza wstępna struktura zarządzania SOA Role i ciała oraz ich odpowiedzialności w kontekście SOA Rekomenduje się powołanie SOA Center of Excellence Architekt ds. Integracji Zespółds. Szyny Integracyjnej
Faza wstępna pryncypia architektoniczne Nazwa Zorientowanie na usługi Stwierdzenie organizacji bazuje na podejściu usługowym (w obszarze biznesu, aplikacji jak i infrastruktury technicznej) z dobrze określonymi poziomami ich świadczenia Uzasadnienie Podejście usługowe zwiększa elastyczność organizacji oraz zapewnia przepływ informacji bez barier. Implikacje Biznes musi zdefiniować katalog usług biznesowych i określić ich SLA, a następnie wskazać ich relacje do procesów biznesowych. Należy zdefiniować szczególnego rodzaju wymagania na otwarte standardy w szczególności w zakresie interoperacyjności. Wymagane jest wprowadzenie skutecznych mechanizmów ładu architektonicznego w obszarze SOA w szczególności dotyczy to zasad re-używalności usług. Wymagane jest zdefiniowanie testu papierka lakmusowego, który określa czy dana usługa została we właściwy sposób zaprojektowana i zrealizowana.
Faza wstępna pryncypia architektoniczne Przykłady innych pryncypiów: Usługi są reużuwalne Organizacja wprowadziła i monitoruje KPI, w tym KPI usług Organizacja posługuje sięmodelami referencyjnymi, w tym modelem referencyjnym SOA Organizacja automatyzuje swoje procesy z zastosowaniem podejścia usługowego Organizacja gromadzi informacje o metadanych usług Organizacja definiuje i używa kontraktów do określania wymagań biznesowych i IT
Kontekst: struktura TOGAF Metamodel
Metamodel zawartości TOGAF 9 Pryncypia architektoniczne, wizja oraz wymagania Faza wstępna Wizja architektury Wymagania architektoniczne biznesowa Motywacja systemów informatycznych Dane Aplikacje techniczna Organizacja Funkcja Realizacja architektury Możliwości, rozwiązania i planowanie migracji Nadzór nad implementacją
Metamodel zawartości z TOGAF 9
Rdzeńmetamodelu i jego rozszerzenia
Rdzeńmetamodelu i jego rozszerzenia
Faza wstępna wybór narzędzia Na tym etapie prac następuje wybór narzędzia do modelowania architektury (w tym SOA). Nie oznacza to wyboru narzędzia do realizacji architektury zorientowanej na usługi.
FazaA Wizja architektury Faza wstępna Celem fazy A jest zdefiniowanie zakresu prac, identyfikacja interesariuszy, utworzenie wizji organizacji działającej zgodnie z SOA oraz otrzymanie akceptacji sponsora odnośnie do dalszych działań. G Nadzór nad implementacją H Zarządzanie zmianą architektury A Wizja architektury Zarządzanie wymaganiami B biznesowa C danych i aplikacji F Planowanie migracji E Możliwości i rozwiązania D techniczna
FazaA zakres prac Poziom szczegółów
FazaA identyfikacja interesariuszy Moc
Faza A Wizja architektury Wyzwania: Zidentyfikowanie kluczowych wymagań, odzwierciedlonych następnie w modelu rozwiązania docelowego. Opisanie organizacji w stanie docelowym za pomocą zbioru scenariuszy biznesowych podkreślających rolęaspektów integracyjnych (przełamujących silosy organizacyjne). Scenariusz biznesowy opisuje (mega) proces biznesowy, którego realizacja jest możliwa dzięki realizacji określonego zbioru usług biznesowych, automatyzowanych przez usługi IT.
FazaB biznesowa Faza wstępna H Zarządzanie zmianą architektury A Wizja architektury B biznesowa Celem fazy B jest opis bazowej architektury biznesowej i stworzenie docelowej architektury biznesowej w podejściu usługowym oraz opracowanie analiz luk G Nadzór nad implementacją Zarządzanie wymaganiami C danych i aplikacji F Planowanie migracji E Możliwości i rozwiązania D techniczna
Faza B biznesowa
Faza B biznesowa Wyzwania: Problemy ze stworzeniem katalogu usług biznesowych. Problemy z określeniem SLA biznesowego. Problemy z powiązaniem usług biznesowych z procesami biznesowymi. Według TOGAF: proces jest zbiorem usług biznesowych i ich kontraktów; usługa może byćwykorzystywana w jednym lub więcej procesie biznesowym.
Faza C danych i aplikacji H Zarządzanie zmianą architektury A Wizja architektury Faza wstępna B biznesowa Celem fazy aplikacji jest opis bazowej architektury aplikacji i stworzenie docelowej architektury aplikacji w podejściu usługowym oraz opracowanie analiz luk G Nadzór nad implementacją F Planowanie migracji Zarządzanie wymaganiami E Możliwości i rozwiązania D techniczna C danych i aplikacji Celem fazy danych jest opis bazowej architektury danych i stworzenie docelowej architektury danych oraz opracowanie analiz luk
Faza C danych i aplikacji
Faza C danych i aplikacji Wyzwania: Opisanie stanu bazowego (opis aplikacji) zgodnie z podejściem usługowym. Stworzenie korporacyjnego modelu danych. Zdefiniowanie docelowego katalogu usług systemów informatycznych na odpowiednim poziomie granulacji. Przełożenie SLA biznesowego na SLA dla usług systemów informatycznych. Problemy z komunikacją z działem utrzymania (oni też mają usługi!).
FazaD techniczna Faza wstępna H Zarządzanie zmianą architektury A Wizja architektury B biznesowa G Nadzór nad implementacją F Planowanie migracji Zarządzanie wymaganiami E Możliwości i rozwiązania D techniczna C danych i aplikacji Celem fazy techniczna jest opis bazowej architektury technicznej i stworzenie docelowej architektury technicznej w podejściu usługowym oraz opracowanie analiz luk
Faza D techniczna
Faza D techniczna Service Oriented Infrastructure Reference Model
Faza D techniczna Wyzwania: Opisanie stanu bazowego w ujęciu logicznym jednocześnie z uwzględnieniem paradygmatu usługowego (problem oderwanie sięod CMDB). Problemy z komunikacją z działem utrzymania (oni też mają usługi!). Problemy z uwzględnieniem cloud computing (w tym podejściu może być realizowana istotna część usług platform).
FazaE Możliwości i rozwiązania Faza wstępna G Nadzór nad implementacją H Zarządzanie zmianą architektury F Planowanie migracji A Wizja architektury Zarządzanie wymaganiami E Możliwości i rozwiązania B biznesowa D techniczna C danych i aplikacji 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. Będą one stanowiły podstawę planu migracji.
Faza E Możliwości i rozwiązania
Faza E Możliwości i rozwiązania Wyzwania: Problemy z właściwym zdefiniowaniem zakresu poszczególnych architektur pośrednich. Właściwe zidentyfikowanie ryzyk przy wdrażaniu SOA.
Faza F Planowanie migracji Faza wstępna i pryncypia Celem fazy F jest ułożenie poszczególnych projektów zgodnie z ich priorytetami. H Zarządzanie zmianą architektury A Wizja architektury B biznesowa Następuje oszacowanie zależności, kosztów i korzyści związanych z poszczególnymi projektami migracyjnymi. G Nadzór nad implementacją Zarządzanie wymaganiami C danych i aplikacji Spriorytetyzowana lista projektów stanowi podstawą planu migracji. F Planowanie migracji E Możliwości i rozwiązania D techniczna
Faza F Planowanie migracji Wyzwania: Przypisanie wartości biznesowej każdemu projektowi. Zabezpieczenie sięprzed quick-wins biznesu, który nagle dochodzi do wniosku, że silosy nie były złe.
Faza G Nadzór nad implementacją Faza wstępna i pryncypia Celem fazy G jest sformułowanie rekomendacji dla każdego projektu w formie kontraktu architektonicznego, służącego do zarządzania implementacją i implementacją danego systemu. System ten jest następnie implementowany i wdrażany podczas tej fazy. G Nadzór nad implementacją H Zarządzanie zmianą architektury F Planowanie migracji A Wizja architektury Zarządzanie wymaganiami E Możliwości i rozwiązania B biznesowa D techniczna C danych i aplikacji
Faza G Nadzór nad implementacją Wyzwania: Umiejętne zdefiniowanie kontraktów architektonicznych. Koniecznośćposiadania zasobów niezbędnych do realizacji nadzoru architektonicznego.
FazaH Zarządzanie zmianą Faza wstępna i pryncypia Celem fazy H jest ustanowienie procesu zarządzania zmianami dla nowej bazowej architektury j, która jest osiągania z momentem zakończenia fazy nadzoru nad implementacją. H Zarządzanie zmianą architektury A Wizja architektury B biznesowa W ramach tego procesu prowadzi się ciągły monitoring rozwój technologicznego i zmian w środowisku biznesowym w celu decydowania czy formalnie zainicjować nowy cykl rozwoju architektury. G Nadzór nad implementacją F Planowanie migracji Zarządzanie wymaganiami E Możliwości i rozwiązania D techniczna SLAJD 75 of 24 C danych i aplikacji
Faza H Zarządzanie zmianą Wyzwania: Konieczność wykonywania analizy what-if. Zapobieganie nadmiernemu mnożeniu się usług. Powracająca tendencja łączenia systemów punkt-punkt.
Faza Zarządzanie wymaganiami Faza wstępna i pryncypia H Zarządzanie zmianą architektury A Wizja architektury B biznesowa Podczas każdej fazy prace są walidowane pod kątem bieżących wymagań biznesowych, które sterują rozwojem architektury. G Nadzór nad implementacją Zarządzanie wymaganiami C danych i aplikacji F Planowanie migracji E Możliwości i rozwiązania D techniczna SLAJD 77 of 24
Faza Zarządzanie wymaganiami Wyzwania: Nauczenie biznesu funkcjonowania zgodnie z paradygmatem usługowym. Przełożenie często rozmytych wymagań biznesowych na zapisy w SLA.
Podsumowanie Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl
Podsumowanie (1) Przedstawione podejście ma charakter modelowy. Samo The Open Group wskazuje, że oczekiwana jest adaptacja tego podejścia do potrzeb konkretnej organizacji. TOGAF mówi co ma byćzrobione. TOGAF bardzo często (a jużna pewno nie w szczegółach) NIE mówi jak coś ma być zrobione. Adaptacja TOGAF w obszarze: Procesów Produktów Terminologii Wskazane jest zawsze umieszczenie uzasadnienia w repozytorium architektonicznym, dlaczego pewne rzeczy wykonuje się inaczej (lub dlaczego pewne rzeczy zostały pominięte).
Podsumowanie (2) Struktura repozytorium architektonicznego
Podsumowanie (3) Niektórzy twierdzą, że organizacje, które nie uwierzyły w skutecznośćrekomendowanego podejścia, po nie udanym wdrożeniu SOA, w wewnętrznych audytach wykazują, że przyczyną niepowodzeń był brak elementów wykazywanych jako krytyczne w Using TOGAF to Define and Govern Service-Oriented Architectures.
Dziękuję za uwagę zapraszam do kontaktu sobczak@sgh.waw.pl