Analiza rozwiązań IT

TOGAF dla rozwiązań typu SOA
Założenia metodyki TOGAF

The Open Group Architecture Framework (TOGAF) stanowi szczegółowy sposób i zestaw narzędzi pomocniczych rozwoju architektury korporacyjnej.
Wspiera cztery domeny architektury:

  1. Architekturę biznesową (ang. Business Architecture) – definiującą strategię biznesową, nadzór organizacyjny, model organizacyjny oraz główne procesy biznesowe.
  2. Architekturę danych (ang. Data Achitecture) – opisującą strukturę fizyczną oraz logiczną danych przechowywanych i przetwarzanych przez organizację.
  3. Architekturę oprogramowania (ang. Applications Architecture) – dostarczającą plan systemów informatycznych, ich interakcji i powiązań z głównymi procesami biznesowymi.
  4. Architekturę infrastruktury (ang. Technology Architecture) – opisującą infrastrukturę pod kątem oprogramowania oraz sprzętu wspierających usługi IT i inne procesy organizacji.

 

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.

togaf_r1

Diagram ilustrujący cykl ADM (udostępniony przez The Open Group)

Faza Wstępna

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.


W ramach fazy wstępnej zakłada się podjęcie następujących działań:

  • Wskazanie pryncypiów orientacji na usługi według pryncypiów architektonicznych.
  • Dokonanie oceny dojrzałości istniejącej już architektury przy pomocy The Open Group Service Integration Maturity Model (OSIMM).
  • Zdefiniowanie procesu nadzoru i strategii wsparcia architektury SOA – proces nadzoru powinien rozszerzać proces nadzoru IT i architektury korporacyjnej.
  • Wypełnienia repozytorium architektonicznego związanego z architekturą SOA takich jak: Referencja Architektoniczna (SOA Reference Architecture), Bloki Budowlane (SOA Building Blocks), Bloki Budowlane Rozwiązań (SOA SBB), Komponenty Techniczne (SOA Technical Components).
  • Utworzenie Center of Excellence (CoE) – zespół do spraw przywództwa, dobrych praktyk, badań, wsparcia i/lub szkolenia oraz zespół architektów.

W ramach tej fazy tworzony jest metamodel architektoniczny. Metamodel w postaci diagramu klas obejmuje wszystkie cztery domeny architektoniczne i opisuje związki między nimi w notacji UML. Metamodel może zostać uznany za formalną specyfikację wymagań produktów architektonicznych.

A. Wizja Architektoniczna
togaf_r2

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.

B. Architektura Biznesowa

Domenę biznesowa stanowią:

  • opis architektury biznesowej i procesów biznesowych,
  • model i opis biznesowych przypadków użycia,
  • specyfikację realizacji biznesowych przypadków użycia,
  • model obiektów biznesowych,
  • definicje reguł biznesowych.

Zakłada się, że pomiędzy fazą A, a fazą B (w ramach procesu zarządzania wymaganiami architektonicznymi), powstanie właściwy dokument specyfikacji wymagań architektonicznych (ang. Architecture Requirements Specification) i będzie on następnie rozwijany i uzupełniany pomiędzy fazami B – F. Dokument ten powinien dać ilościowy obraz rezultatu dostarczającego mierzalnych kryteriów, które powinny zostać spełnione przez projekt implementacji nowej architektury.

 

Rekomendowana zawartość dokumentu specyfikacji wymagań architektonicznych jest następująca:

  • miary sukcesu projektu (ang. success measures),
  • wymagania architektoniczne (ang. architecture requirements),
  • umowy na usługi biznesowe (ang. business service contracts),
  • umowy na usługi aplikacyjne (ang. application service contracts),
  • wytyczne implementacyjne (ang. implementation guidelines),
  • specyfikacje implementacyjne (ang. implementation specifications),
  • standardy implementacyjne (ang. implementation standards),
  • wymagania wobec interoperacyjności (ang. interoperability requirements),
  • wymagania wobec zarządzania usługami IT (ang. IT service management requirements),
  • ograniczenia (ang. constraints),
  • przyjęte założenia (ang. assumptions).

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.

C. Architektura Systemów Informatycznych

Domenę aplikacji stanowią:

  • model przypadków użycia wraz z opisem,
  • specyfikację wymagań dla systemów,
  • opis architektury systemu,
  • definicje interfejsów i protokołów,
  • model prototypu interfejsu użytkownika,
  • definicje komponentów programowych,
  • modele analityczne i projektowe systemu.

Domena danych stanowi szczegółowy opis modelu (zarówno na poziomie logicznym jak i fizycznym):

  • danych systemu,
  • metadanych systemów.

Faza C skupia się na portfelu usług aplikacji i strukturze organizacyjnej. Największe zmiany w tej fazie dokonywane są w warstwie architektury aplikacji. Opis stanu bazowego dokonywany jest zgodnie z podejściem usługowym i obejmuje:

  • Stworzenie korporacyjnego modelu danych.
  • Zdefiniowanie docelowego katalogu usług systemów informatycznych na odpowiednim poziomie granulacji.

Artefakty są opisywane za pomocą diagramów w celu ich prezentacji interesariuszom.

D. Architektura Techniczna

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.

E. Szanse i Rozwiązania

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.

F. Planowanie migracji

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.

G. Proces nadzoru nad implementacją

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.

H. Zarządzanie Zmianą 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.