Zastosowanie TOGAF do definiowania i nadzoru architektury zorientowanej na usługi (SOA)



Podobne dokumenty
Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej

Architektura korporacyjna jako narzędzie koordynacji wdrażania przetwarzania w chmurze

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

Pryncypia architektury korporacyjnej

Produkty i artefakty architektoniczne

Czym jest Minimum Viable (Architecture) Practice w kontekście instytucji finansowych? Prof. SGH, dr hab. Andrzej Sobczak

Dobre praktyki w zakresie zarządzania ładem architektury korporacyjnej

Budowa potencjału architektonicznego organizacji

Globalne podejście do transformacji organizacji z wykorzystaniem IT. Prof. SGH, dr. hab. Andrzej Sobczak Katedra Informatyki Gospodarczej SGH

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski

dr Mariusz Ulicki Dyrektor Biura Informatyki i Telekomunikacji Centrali KRUS

Wstęp do zarządzania projektami

Warsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni

Koncepcja metodycznego podejścia do podnoszenia poziomu interoperacyjności w organizacjach publicznych z zastosowaniem architektury korporacyjnej

Wstęp do zarządzania projektami

Data Governance jako część ładu korporacyjnego

Kierunek cyfryzacji w Polsce praktyczne konsekwencje zmian dla obywateli oraz przestrzeni publicznej

Projektowanie Modeli Usług dla rozwiązań typu SOA

Wstęp do zarządzania projektami

Charakterystyka kluczowych pojęć architektonicznych w obszarze danych

Formułowanie i zastosowanie pryncypiów architektury korporacyjnej w organizacjach publicznych

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami

Outsourcing procesów. dr Arkadiusz Wargin CTPartners S.A. Analiza projektu B2B Kielce, 18 października 2012

Kodeks dobrych praktyk architektów korporacyjnych jako narzędzie profesjonalizacji zawodowej

Zarządzanie usługami IT zwinność

Architektura korporacyjna państwa a nowoczesna administracja publiczna

Zastosowanie podejścia architektonicznego jako narzędzia przeprowadzenia transformacji jednostek administracji publicznej

Bezpieczeństwo dziś i jutro Security InsideOut

ZARZĄDZANIE STRATEGICZNE OPRACOWANIE

Architektura korporacyjna państwa narzędzie koordynacji informatyzacji organizacji sektora publicznego

Koncepcja cyfrowej transformacji sieci organizacji publicznych

Komentarz wprowadzający odnośnie do wprowadzania podejścia architektonicznego w administracji publicznej Prof. SGH, dr hab.

Założenia modelu dostarczenia wartości z budowy inteligentnego miasta

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Wdrożenie technologii procesowej IBM BPM w EFL

Zarządzanie projektami a zarządzanie ryzykiem

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

MSF. Microsoft Solution Framework

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011

COBIT 5 WHITE PAPER WSTĘP

CTPARTNERS W LICZBACH ~100% 4,9 >500. kompleksowe obszary zarządzania IT w ofercie. osób przeszkolonych z zakresu IT

System antyfraudowy w praktyce. marcin zastawa wiceprezes zarządu. Warszawa, października 2006r.

Tematy prac magisterskich Rok akademicki 2013/2014

Cykle życia systemu informatycznego

Prezentacja firmy i doświadczeń ze wspólnych projektów

Jak opisać wymagania zamawiającego wybrane elementy

Agile Project Management

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Zarządzanie budowlanym projektem inwestycyjnym dla inwestycji publicznych i komercyjnych

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC oraz BS doświadczenia audytora

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r.

Architektura korporacyjna państwa MICHAŁ BUKOWSKI, MAC

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Szkolenie 2. Zarządzanie programami

Architektura korporacyjna jako narzędzie transformacji cyfrowego państwa MICHAŁ BUKOWSKI, MAC

Usługa: Testowanie wydajności oprogramowania

Etapy życia oprogramowania

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Jarosław Żeliński analityk biznesowy, projektant systemów

Architektura oprogramowania w praktyce. Wydanie II.

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Procesowa specyfikacja systemów IT

Podstawy organizacji systemów zarządzania bezpieczeństwem informacji dokumenty podstawowe

Metodyki zarządzania projektami PRINCE2

Rekomendacja D w obszarze zarządzania projektami na przykładzie rozwiązań w Banku Polskiej Spółdzielczości S.A.

Michał Jaworski Wiceprezes PIIT

CRM w logistyce. Justyna Jakubowska. CRM7 Specjalista Marketingu

SUBDYSCYPLINY W NAUKACH O ZARZĄDZANIU I JAKOSCI 2.0

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Szkolenie 1. Zarządzanie projektami

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem.

Modelowanie i analiza systemów informatycznych

Surowce w gospodarce o obiegu zamkniętym Łukasz Sosnowski, Sekretarz Zespołu ds. Gospodarki o Obiegu Zamkniętym

Praktyki ITIL oraz narzędzia ITSM w procesie wdrożenia usług Agenta Transferowego w Banku Zachodnim WBK S.A.

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Kontrola zarządcza w jednostkach samorządu terytorialnego z perspektywy Ministerstwa Finansów

WPROWADZENIE DO UML-a

Organizacyjny aspekt projektu

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium

CTPARTNERS W LICZBACH ~100% 4,9 >500. kompleksowe obszary zarządzania IT w ofercie. osób przeszkolonych z zakresu IT

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

Zarządzanie Projektami zgodnie z PRINCE2

TRENING KOMPETENCJI MENEDŻERSKICH

Analityk i współczesna analiza

SPIS TREŚCI Audyt wewnętrzny wydanie II

REKOMENDACJA D Rok PO Rok PRZED

Egzamin ITIL Foundation

WSPÓŁCZESNA ANALIZA STRATEGII

SOA Web Services in Java

CLOUD ADOPTION PROGRAM

Stan zaawansowania prac dotyczących zamówienia na opracowanie i wdrożenie rdzenia systemu e Urząd.

Audyt systemów informatycznych w świetle standardów ISACA

Transkrypt:

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