Wizualizacja modeli architektonicznych

Architektura_IT

Modele architektoniczne tworzy się właściwie na wszystkich etapach pracy nad oprogramowaniem. Już sam pomysł na nowy system to najczęściej szkic złożony z paru kółek, prostokątów, kresek, a nierzadko małych ludzików rysowanych z wprawą dziecka z przedszkola. Potem, im bardziej chcemy oddać naturę rozwiązania, diagramy stają się coraz bardziej skomplikowane, a do ich stworzenia nie wystarczają już kartka i ołówek. Rynek oferuje całą listę standardów, które dokładnie określają, jakich symboli należy użyć, aby oddać istotę rzeczy. Możemy również przebierać w narzędziach – zarówno komercyjnych, jak i darmowych. Generalnie jednak główny cel tworzenia obrazków jest bardzo prosty: przekazać informację w sposób prosty, czytelny i zrozumiały.

Pojęć „model” i „diagram” bardzo często używa się zamiennie. Rzeczywiście, na pierwszy rzut oka oba terminy wydają się znaczyć niemal to samo. Jednakże jest pewna zasadnicza różnica. Model to abstrakcja, która zwiera wszystkie elementy niezbędne do opisania modelowanej rzeczywistości. Diagram zaś to jeden ze sposobów spojrzenia na całość bądź część modelu w pewnym określonym kontekście. Innymi słowy, na podstawie modelu możemy stworzyć wiele diagramów, dla różnych grup odbiorców, w taki sposób, by dla każdej z nich był zrozumiały. Inaczej pokażemy pewne aspekty związane z tworzonym systemem osobom związanym z biznesem, by przekonać ich, że właściwie zrozumieliśmy specyfikę ich działalności, a inaczej programistom, którzy tę specyfikę przełożą na użyteczny system informatyczny.

Informacja przekazywana na diagramach powinna być dla odbiorcy wartościowa i zrozumiała. Aby nadać informacji odpowiednią wartość, bardzo często na diagramie pojawia się zbyt wiele elementów, przez co staje się… niezrozumiały. Z drugiej strony zrozumiały diagram, z małą ilością wartościowych informacji, staje się często zbyt trywialny, by wzbudzić zainteresowanie odbiorców. Nie ma recepty na to, aby algorytmicznie wyznaczyć „złoty środek”. Zdolność do jego wskazania to zazwyczaj wypadkowa doświadczenia, znajomości odbiorcy, tematu i szczęścia.

Modelując architekturę korporacyjną, tworzy się modele w czterech różnych domenach: biznesowej, aplikacji, danych oraz infrastruktury. Każdy z nich niesie z sobą określoną wartość, ale dopiero połączenie interdyscyplinarne w pełni pokazuje ich niebagatelną wartość. Twórca modeli i diagramów z łatwością ją dostrzega. Ale jak ją pokazać tym, którzy sponsorują nasze prace i oczekują nie tylko efektywnego, ale również efektownego ich zwieńczenia? Jak pokazać zależności i wzajemny wpływ modeli z poszczególnych dziedzin, jeśli diagramy prezentujące fragmenty pojedynczych modeli już są niewiarygodnie skomplikowane?

Próbując odpowiedzieć na postawione wyżej pytania, postanowiliśmy, w ramach prac laboratoryjnych, rozwinąć własne rozwiązanie. Wśród wielu założeń znalazły się między innymi poniższe.

  1. Idziemy na całość, jeśli chodzi o interfejs użytkownika. Nie sugerujemy się typowymi rozwiązaniami biurowymi. Dwa wymiary to za mało, by móc prezentować złożone informacje z różnych dziedzin domenowych wraz z powiązaniami.
  2. Interfejs użytkownika jest nie tylko estetyczny, ale również ergonomiczny, jeśli chodzi o nawigację oraz w czytelny sposób prezentuje informacje.
  3. Aplikacja przeznaczona jest na różne platformy – w tym mobilne (tablety, smartfony).
  4. Aplikacja nie umożliwia rejestracji informacji, a jedynie łączy się z dostępnymi źródłami, analizuje, interpretuje, po czym wyświetla w przejrzystej formie.

Aby nasza praca nie była całkowicie abstrakcyjna, wykonaliśmy ją w kontekście modelowania architektury biznesowej oraz IT jednego z naszych klientów. Z perspektywy czasu można powiedzieć, że takie podejście było słuszne, ponieważ w doskonały sposób weryfikowało wiele naszych koncepcji – zazwyczaj negatywnie: nasze pomysły okazywały się nieużyteczne biznesowo.

Za punkt wyjścia przyjęliśmy domeny architektury korporacyjnej: biznesową, IT (aplikacyjną i danych) oraz infrastruktury. Gromadząc informacje na temat poszczególnych domen, badając ich charakter oraz relacje, doszliśmy do wniosku, że w pierwszej kolejności skupimy się na pewnych aspektach domeny biznesowej oraz aplikacyjnej. Wynikało to głównie z bieżących potrzeb biznesu: konieczności badania wpływu zmian w systemach IT na procesy biznesowe.

Uznaliśmy, że w kwestii nawigacji oraz prezentacji informacji odejdziemy od typowych dla aplikacji biznesowych rozwiązań, czyli wielopoziomowego menu. Użytkownik dociera do interesujących go informacji, poruszając się po menu w postaci układu planetarnego.

Wchodząc w Systemy IT informacja prezentowana jest w podobny sposób, tyle że zamiast domen biznesowych mamy grupy systemów: techniczno-ubezpieczeniowe, sprzedażowe, wspierające likwidację szkód itd.

Architektura 3D 2 Widok Systemy IT

Jak łatwo odgadnąć, wskazanie konkretnej grupy pozwala na zbudowanie układu złożonego z konkretnych systemów.

Architektura 3D 3 Widok Grupy Systemów

W efekcie otrzymujemy dynamiczny raport, w którym możemy odpowiednio sterować zakresem prezentowanej informacji. Powyżej widzimy nie tylko systemy sprzedażowe (wewnętrzna orbita), ale również inne systemy, które z nimi współpracują. Widać także procesy biznesowe, wspierane przez systemy sprzedażowe. W widoku możemy usuwać bądź dodawać całe orbity oraz poszczególne planety z orbit. Możliwe akcje dostępne są z menu umieszczonego w prawym dolnym rogu, a także  pod prawym przyciskiem myszy.

Oczywiście możemy również wyświetlić podstawowe informacje o każdej z planet.

Architektura 3D 4 Szczegóły Systemu

Jeśli chodzi o prezentowanie zmian w Architekturze IT, uznaliśmy, że sprawdzi się układ, w którym kolejne wersje umieścimy na przewijalnym pierścieniu.

Architektura 3D 5 Zmiany w Architekturze

Posiadając dwa takie pierścienie, możemy w łatwy sposób wybrać na każdym z nich modele z różnych punktów w czasie i porównać w kolejnym widoku.

Architektura 3D Zmiany w Architekturze

W odpowiedni sposób zostały wyróżnione różnice między modelami (nowe oraz usunięte systemy). Powrót do widoku z pierścieniami nie jest potrzebny, aby móc wybrać inną wersję modelu. Można to zrobić bezpośrednio z listy dostępnych wersji (dla modelu w górnej części ekranu po prawej stronie, dla modelu z dolnej części ekranu – po lewej) lub też przeglądać kolejne wersje przy pomocy strzałek NEXT i PREV umieszczonych w górnym i dolnym narożnikach obu warstw. W ten sposób możemy w bardzo łatwy sposób prześledzić zmiany w Architekturze IT poszczególnych grup systemów.

Powrót do układów planetarnych wyższego poziomu możliwy jest dzięki menu umieszczonym w dolnej części ekranu. Zagłębienie się w kolejny poziom powoduje odłożenie się skrótu do właśnie opuszczonego układu.

W części dotyczącej domeny biznesowej pierwsze widoki są bardzo podobne do widoków z domeny IT.

Architektura 3D Biznes

Tym razem w układzie widzimy dwie orbity. Na wewnętrznej mamy grupy procesów podstawowych, na zewnętrznej – grupy procesów pomocniczych. Po wybraniu jednej z grup uzyskujemy listę procesów z danej grupy.

Architektura 3D Procesy

Oprócz listy procesów (z prawej strony) możemy zobaczyć schemat przebiegu procesu (na karcie po lewej). Oczywiście jest on mało czytelny dla dokładniejszej analizy procesu, dlatego kliknięcie go umożliwia prześledzenie jego przebiegu w dużym oknie.

Architektura 3D Przebieg procesu

W lewym górnym rogu mamy miniaturę przebiegu procesu, która ułatwia nam nawigację. Pokazuje ona, w której części procesu jesteśmy oraz umożliwia szybkie przesunięcie się do jego innego fragmentu. Po wielu próbach zrezygnowaliśmy z prezentacji całych procesów na jednym ekranie – bywają procesy tak złożone, że po odpowiednim przeskalowaniu diagram ich przebiegu stałby się zupełnie nieczytelny. Modelując procesy, zadbano o to, aby gromadzić wiedzę np. na temat różnego rodzaju dokumentacji poszczególnych aktywności, czyli rozporządzeń, instrukcji stanowiskowych, szablonów, a nawet filmów instruktażowych. W rezultacie mamy do nich bezpośredni dostęp z diagramu.

Architektura 3D Przebieg procesu Informacje Dodatkowe

Wybierając aktywność, otrzymujemy cały pakiet dodatkowych materiałów na jej temat. Można sobie wyobrazić, o ile prostsze staje się wdrożenie nowego pracownika. Wystarczy wskazać mu odpowiednią rolą w procesie, a cała informacja na temat jego obsługi znajduje się w jednym miejscu, podana w czytelny i atrakcyjny sposób.

Architektura 3D Przebieg Procesu HR

Warto również wspomnieć, że tory w diagramie zintegrowane są kartoteką pracowników, dzięki czemu można łatwo uzyskać informację o tym, kto odpowiada za realizację aktywności w torze oraz uzyskać dane kontaktowe wybranej osoby.

Jak widać na slajdach, zrezygnowaliśmy ze standardowej notacji BPMN. Taka wydała nam się atrakcyjniejsza i lepiej pasująca do estetyki całego rozwiązania.

Ostatni widok pokazuje relacje między domeną biznesową a IT.

Architektura 3D Warstwy

W warstwie środkowej znajduje się diagram przebiegu procesu. Poniżej jej są systemy wspierające poszczególne aktywności procesu, a powyżej – ryzyka, z jakimi związana jest realizacja aktywności procesu. Również w tym widoku można powiększyć jego wybrane fragmenty.

Architektura 3D Warstwy Szczegóły

Dla zilustrowania artykułu wykorzystałem fragmenty prezentacji, którą w całości można obejrzeć poniżej. O tym, w jaki sposób i w jakim stopniu wizja została zrealizowana – w kolejnym odcinku.

Prezentacja: Architektura 3D Atena

Dodaj komentarz

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