Witam w nowym roku Uśmiech. To już przed ostania część artykułów o wykorzystaniu Enterprise Architect w modelowaniu architektury korporacyjnej. Ostatni tekst skończyłem modelem biznesowym z macierzą powiązań.

Analizując macierz powiązań jesteśmy w stanie wyśledzić, które usługi aplikacji znajdą się w obszarze naszych zainteresować podczas modelowania architektury aplikacji. Rozwiązanie to wykaże nam jednak tylko bezpośrednie powiązania pomiędzy analizowanymi elementami. Analizując obszar zmian w architekturze korporacyjnej musimy jednak bardzo często przeanalizować także powiązania pośrednie pomiędzy elementami. W tej sytuacji pomocny jest widok Traceability Enterprise Architecta. Za jego pomocą możemy wyśledzić wszystkie pośrednie i bezpośrednie powiązania danego elementu w modelu z innymi elementami. Widok Traceability możemy uruchomić wybierając z menu głównego aplikacji opcję View | Traceability (skrót klawiszowy Ctrl + Shift + 4). Na rysunku poniżej przedstawiłem przykładowy widok Traceability za pomocą którego możemy ustalić, że usługa aplikacji Zarządzanie dokumentami jest powiązana z głównym procesem biznesowym Sprzedaż kredytu hipotecznego, ponieważ pozostaje ona w relacji z procesem biznesowym Rejestracja wniosku o kredyt hipoteczny, który jest częścią wymienionego procesu głównego.

image

Rysunek 21 Przykład widoku Traceability

Gdy już zidentyfikowaliśmy usługi aplikacji, które będą objęte zakresem prac architektonicznych związanych z danym projektem możemy przyjrzeć się bliżej architekturze aplikacji. W naszym przykładzie bank po akwizycji dwóch spółek musi podjąć kroki związane z integracją oferty nowo nabytych firm ze swoją ofertą. Ważne jest aby analizą objąć nie tylko procesy biznesowe, ale także infrastrukturę techniczną oraz oprogramowanie używane przez wszystkie integrowane podmioty. Na diagramach poniżej przedstawiłem obecny stan dla architektury aplikacji w poszczególnych firmach.

image

Rysunek 22 Architektura istniejąca: Aplikacje KS

image

Rysunek 23 Architektura istniejąca: Aplikacje TS

image

Rysunek 24 Architektura istniejąca: Aplikacje ModBank

Analizując funkcje aplikacji i przypisane do nich komponenty możemy zauważyć, że niektóre z nich realizują podobną funkcjonalność w poszczególnych firmach. Wszystkie systemy CRM realizują te same funkcje. Utrzymanie oddzielnych baz klientów może spowodować, iż konsultanci albo pominą docelową grupę klientów, albo zwielokrotnią tą samą ofertę – co może podnosić koszty marketingu, a także negatywnie być odebrane przez klientów. Dodatkowo utrzymanie wielu podobnych aplikacji jest kosztowne i może wpływać na konflikt, niespójność i nieaktualność danych oraz w znacznym stopniu ogranicza zdolność szybkiego dostosowania ich do nowych wymagań stawianych przez biznes. W związku z tym należy zastanowić się nad możliwością zastąpienia trzech systemów CRM jednym. Należy rozważyć możliwość utworzenia nowego wspólnego systemu CRM lub pozostawienie któregoś z już istniejących. Możemy także zauważyć, że system zarządzania kredytami samochodowymi i system zarządzania mikropożyczkami zapewne implementują podobne funkcje wspólne dla ogólnej funkcjonalności zarządzania kredytami, jak np. uruchomienie kredytu. W związku z tym należy rozważyć możliwość implementacji ich funkcjonalności w systemie ModBanku „Zarządzanie kredytami”. Podobna sytuacja dotyczy także systemów realizujących usługę aplikacji „Ocena ryzyka”. Na diagramie poniżej przedstawiona została proponowana architektura docelowa dla warstwy aplikacji.

image

Rysunek 25 Architektura docelowa: Aplikacje

Analizując diagramy istniejącej i docelowej architektury aplikacji możemy zauważyć, że w naszym przykładzie zdecydowano się na wykorzystanie istniejącego systemu ModBank CRM do obsługi kontaktów z klientami. Zdecydowano się także na implementację specjalistycznej funkcjonalności systemów (jak np. wycena samochodu, zarządzanie mikropożyczką) jako moduły w ramach istniejących systemów w ModBanku: systemu analiz i systemu zarządzania kredytami.

Podczas projektowania architektury biznesowej, aplikacji, danych i technologii ważnym krokiem na każdym z tych etapów jest przeprowadzenie analizy luk pomiędzy architekturą istniejącą i docelową. Analiza ta będzie wykorzystana podczas planowania implementacji i migracji pomiędzy architekturą istniejącą, architekturami przejścia i architekturą docelową. Do przeprowadzenia analizy luk możemy wykorzystać macierz analizy luk narzędzia Enterprise Architect Gap Analysis Matrix. Kolumny macierzy zawierają wybrane elementy architektury docelowej, a wiersze elementy architektury istniejącej. Uzupełnienie kolumn i wierszy elementami odbywa się przez wybranie za pomocą przycisku oznaczonego trzema kropkami pakietu zawierającego elementy dla architektury docelowej (pole Target Architecture) i istniejącej (pole Baseline Architecture). Dodatkowo za pomocą pól Filter możemy ograniczyć typ wyświetlanych elementów. W polu Profile możemy wybrać jeden z zapisanych profili, który będzie zawierał ustawione przez nas opcje oraz przeprowadzoną analizę luk. Aby zapisać profil zawierający aktualny widok Gap Analysis Matrix należy skorzystać z menu rozwijanego dostępnego po naciśnięciu przycisku Options lub jeżeli pracujemy już na utworzonym profilu skorzystać z opcji Save. Pole Record Gap As natomiast pozwala nam na określenie typu elementu jaki będzie użyty podczas tworzenia luki w naszym repozytorium.

image

Rysunek 26 Widok narzędzia Gap Analysis Matrix podczas wybierania pakietu z elementami dla architektury istniejącej

Analizując widok macierzy możemy przeanalizować, które elementy występują zarówno w architekturze istniejącej, jak i docelowej. Na przykład jeżeli element występuję architekturze docelowej i istniejącej oznaczamy go przez opis „Włączony” w komórce znajdującej się na przecięciu odpowiedniej kolumny z odpowiednim wierszem. Jeżeli jakiegoś elementu nie ma w architekturze docelowej, to możemy komórce znajdującej się na skrzyżowaniu ostatniej kolumny (Missing/Eliminated) i wiersza zawierającego ten element opisać dany element jako np. „Wyeliminowany”. Możemy także powiązać tą komórkę z istniejącym w naszym repozytorium elementem opisującym lukę (opcja Link to Existing Gap Element w menu kontekstowym dostępnym po kliknięciu prawym przyciskiem myszy w obszarze komórki) lub dodać nowy element opisujący lukę (opcja Create Gap Element w menu kontekstowym dla danej komórki). W analogiczny sposób możemy dodać opis luk dla elementów, które występują w architekturze docelowej, a które nie występują w architekturze istniejącej. W takim wypadku do opisu luk wykorzystujemy ostatni wiersz macierzy (New). Poniżej zaprezentowałem przykładowy widok Gap Analysis Matrix dla komponentów aplikacji architektury istniejącej i docelowej.

image

image

Rysunek 27 Przykładowy widok Gap Analysis Matrix dla komponentów aplikacji (obrazek jest podzielony na dwie części gdyż był problem z jego czytelnością)

Za tydzień 6 i ostatnia cześć tego artykułu. ZapraszamUśmiech

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close