Nie od razu ROME zbudowano

Return of Modeling Effort?

Czyli; czy to modelowanie się w ogóle opłaca?

Im dłużej zajmuję się modelowaniem tym większe rozterki mną targają. Czy ta cała praca i wysiłek związany z przygotowaniem modeli, zbieraniem informacji i utrzymaniem ich aktualności jest opłacalna? Kto z tego skorzysta? W jaki sposób? Jak zaangażować innych do pracy i współpracy nad przygotowaniem modeli? Te i wiele innych pytań biega mi po głowie.

Ale też z biegiem lat i realizacją kolejnych projektów i wdrożeń coraz bardziej hołduje zasadzie 'less means more!’. Im więcej dostosowywania narzędzi, metodyk, notacji, procesów, dokumentów – tym więcej potem z tym problemów. Czemu takie rozwiązania jak Confluence połączony z JIRA zdobywa rynek? Ano bo jest prosty! Zniesie wszystko co tam komu sie w głowie urodzi, cała sztuka aby język giętki (tudzież palce) powiedział, co pomysli głowa… Tylko czy to jest efektywne podejście? Cytując klasyków „No, ja nie wiem…?!”

To co wiem, to na pe

Tak, to kolejny atut podejścia, które wyzwala Prolaborate.

Do dziś nie powstała platforma analityczna Enterprise Architect dla posiadaczy „komputerów z jabłuszkiem”. Wyjściem naprzeciw tej sytuacji miał być jak rozumiem WebEA ale UX w tym przypadku nie nie jest najmocniejsza stroną tego podejścia. Przypadek!?… Nie sądzę! 🙂

Niemniej bardzo często właśnie szeroko rozumiany biznes ale i UX’owcy, ServiceDesignerzy, projektanci czy DevOps korzystają z produktu Steve’a J. Co robić!?… 🙂

Szkoda byłoby stracić ich atencję. Z pomocą przychodzi Prolaborate. Wszystko, do czego powyższa grupa powinna się odnieść, możemy udostępnić przez przeglądarkę za pomocą Prolaborate.

Zakres informacji udostępnianych przez Prolaborate może być analogiczny jak ten w EA, chociaż nawiązując do LessIsMore’yzmu – nie ma sensu przeładowywać poszczególnych widoków informacją. Dopasujmy ją do potrzeb uzgadniając zakres interesujących informacji z potencjalnymi odbiorcami. Celem nadrzędnym nieustająco jest poprawa komunikacja, uzgodnienie zakresu, wypracowanie optymalnych rozwiązań ale jednocześnie zachowanie wartości jaką daje repozytorium analityczne w EA.

Jeśli dokumentacja jest rozproszona i np. Prototypy GUI powstają w jakimś zewnętrznym narzędziu typu „Invision” czy „Axure” połączenie ze sobą tych dwóch światów za pomocą Prolaborate staję dziecinnie proste.

Dla obiektu reprezentującego prototyp GUI w EA dołączamy link, który będzie prowadził wprost do prototypu GUI dostępnego we wspomaninych wyżej narzędziach. Nawigowanie po takim modelu będzie bardzo wygodne, bo model udostępniony przez Prolaborate staje się centralnym miejscem dostępu do wszelkiej informacji o projekcie od modelu analityczno – projektowego po techniczne aspekty rozwiązania a wszystko to odniesione do kontekstu biznesowego i zrozumiałego dla użytkownika końcowego działającego prototypu aplikacji.

Dlaczego w magicznym kwadracie Gartnera nie ma narzędzi Sparx Systems?

W ostatnim czasie z magicznego kwadratu Gartnera dla narzędzi do modelowania architektury korporacyjnej zniknął Sparx System!? Co się stało? Czy Enterprise Architect przestał wspierać modelowanie architektury korporacyjnej? Czy ustępuje miejsca innym narzędziom do modelowania architektury?

W swojej codziennej pracy używałem wielu narzędzi. Były to narzędzia do modelowania procesów biznesowych takie jak ADONIS, iGrafix, Metastorm Provision, kilka darmowych narzędzi jak np. ArgoUML, kilka wysoko specjalizowanych jak BIZAGGI. Elementy opisu architektury korporacyjnej a w szczególności domeny systemów utrzymywane w Metastorm Provision, Lean IX, AdoIT ale też w rozwiązaniach bardzo uproszczonych z dokładnością do 'obrazków’ i arkuszy excelowych za nimi stojących, rysowania w MS Visio skomplikowanych modeli dla wdrożenia na poziomie projektowym i implementacyjnym – tez się z tym zmierzyłem.

I po tych wszystkich latach doświadczeń nasuwa mi się jeden wniosek: każde z tych narzędzi mniej lub bardziej spełnia swoją rolę. Przy zachowaniu pewnej dyscypliny i zgodzie danej organizacji na ponoszenie kosztów związanych z utrzymywaniem tych repozytoriów czy tez obszarów informacji – dało się jakieś informacje uzyskać. Niestety słowo 'jakieś’ jest tu kluczowe.

Otóż w każdym z wymienionych wyżej przypadków dochodzi się do sytuacji, w której narzut na utrzymanie aktualności informacji przekracza potencjalne korzyści wynikające z posiadania takiego rozwiązania, patrząc z perspektywy poszczególnych domen i obszarów modelowania.

Z mojej perspektywy wciąż rosnąca popularność takich narzędzi jak Lean IX oprócz agresywnego marketingu wynika również z faktu, iż dostajemy do ręki gotowy zestaw narzędzi, technik i sposobów wizualizacji informacji.

A co jeśli jednak zaproponowana forma nie do końca odpowiada naszym potrzebom? Czy musimy być skazani na formę i zakres zdefiniowany przez dostawcę? Możliwości konfiguracji często bywają ograniczone. Co więcej – często są mało 'graficzne’ a bardziej tekstowo – tabelkowe. Do mnie ta forma wizualizacji nie przemawia.

I tu znowu zadnia są podzielone… Ja osobiście, nie lubię kiedy narzędzie mnie ogranicza! Nie lubię podążać utartymi ścieżkami, polegać tylko na tym, co jest dostępne bez możliwości zaprezentowania swojej wizji, pomysłu na ten czy inny obszar informacji.

Myślę, że w tym właśnie leży problem z Gartnerem, że bazuje na opiniach ludzi 'wygodnych’, którzy chcą korzystać z gotowych rozwiązań a nie budować coś od początku, samemu.

Które z pojeść wygra – trudno ocenić. Ja osobiście uważam, że Sparx pomimo swojego 'trudnego’ i mocno 'zmiennego’ z wersji na wersję układu interfejsu daje bardzo duże możliwości w obszarze modelowania architektury korporacyjnej. Czemu z tego nie skorzystać?

Optymalne środowisko pracy analityka?

Dużo piszę i mówię o repozytorium analitycznym i jego przeznaczeniu. Temat jest mi o tyle bliski, że od lat szukam sposobu, aby przybliżyć świat trosk i wyzwań analityków szerszej grupie osób zaangażowanych w dostarczanie rozwiązań dla biznesu. W tym również rozwiązań IT.

Poszukiwania te skłoniły mnie do następujących wniosków:

1. Repozytorium analityczne jest potrzebne (zwłaszcza dla dużych projektów)!
2. Czy zwinnie, czy klasycznie – baza wiedzy ma rację bytu!
3. Architektura informacji na miarę potrzeb a nie aspiracji!
4. Narzędzia CASE nie są przeszkodą – dobrze stosowane mogę uzdrowić sytuację…!

I na tym ostatnim chciałbym się skupić.

Z racji moich doświadczeń ale też wiedziony pasją do poznawania coraz to nowych rozwiązań i technologii od lat poszukuję sposobu aby ułatwić życie zawodowe sobie ale też może przy okazji innym. Nie lubię wykonywać tej samej pracy po kilka razy. Lubię dzielić się wiedzą i tym co udało mi się zrobić raz i dobrze. Cenię sobie informację zwrotną i rzeczową dyskusję oraz konstruktywną krytykę. Wyznaję zasadę „robić coś dobrze, albo wcale!”.

W powyższym kontekście w mojej pracy zawodowej postawiłem na narzędzie CASE firmy Sparx Systems – Enterprise Architect (w skrócie EA), jako rozwiązanie moich problemów z pracą u podstaw. Okazało się, że wiele z moich problemów z zarządzaniem dużym zakresem informacji, formułowaniem wniosków, analizą wielowymiarowych zagadnień znalazło swoje rozwiązanie w tym właśnie narzędziu i jego wykorzystaniu.

EA jako narzędzie CASE bardzo mocno rozwinął się na przestrzeni kilku ostatnich lat. Do wersji 11 stosunkowo niewiele się tak naprawdę działo. Głównie pojawiały się nowe dodatki (tzw. MDG – Model Driven Generation, zestawy przyborników wspierających metodyki, ramy architektoniczne i inne pojawiające się nowinki).

Od wersji 12 zaczął się naprawdę dynamiczny rozwój a kolejne wersje i pojawienie się PCS (Pro Cloud Server) to już istna rewolucja. Wreszcie pojawiła się możliwość pracy grupowej, przeniesienia repozytoriów do chmury, współdzielenia danych. Niemniej EA wywodzi się ze świata projektowego i cały czas ta specyfika jest tu obecna. Mówiąc wprost dalej jest to dość zaawansowane i techniczne narzędzie. Dla współpracy z biznesem raczej trudne do zaakceptowania począwszy od sposobu zbierania i utrzymana informacji aż po formy jej prezentacji. Według mnie rzecz gustu i przyzwyczajenia ale faktycznie wymaga trochę czasu oswojenie się z interfejsem graficznym. Co gorsza firma Sparxsystems cały czas zmienia ten interfejs poszukując optymalnego rozwiązania i muszę przyznać – idzie im coraz lepiej. W ostatniej wersji (14.0) położono bardzo duży nacisk na ergonomię i sposób prezentowania informacji. Pojawiło filtrowanie kontekstowe, różne listy, widoki kontekstowe – niemniej to dość zaawansowane funkcjonalności.

To czego przez cały czas mi brakowało w tym narzędziu i co dalej pozostaje trudnodostępne, to łatwości w dzieleniu się zebranymi informacjami i wnioskami, jakie na ich podstawie formułuję.

I tak oto znalazłem dwa narzędzia:

eaDocX to generator dokumentacji z repozytorium analitycznego jakim jest Enterprise Architect. Wbudowany w EA narzędzie do generowania dokumentacji jest dość skomplikowane i mało intuicyjne. Stąd też tak wiele inicjatyw mających na celu przygotowanie własnych narzędzi do wyciągania z EA informacji. Na rynku polskim swego czasu funkcjonowało narzędzie „Tormigo” firmy „Modesto”, autorstwa Michała Wolskiego. Była to całkiem udana próba zbudowania zestawu narzędzi raportowych, niemniej oferowała pewien zamknięty zakres raportów jakie przewidział autor i z mojej perspektywy okazało się to niewystarczające – musiałem szukać dalej.

Po wielu próbach z wbudowanym w EA generatorem natrafiłem w końcu na eaDocX – i to był przełom.

Wreszcie mogłem zdefiniować własny metamodel repozytorium i na jego podstawie przygotować punkty widzenia interesujące z perspektywy odbiorców mojej pracy. Co więcej, udało mi się odchudzić dokumentację i przejść z podejścia holistycznego, zbierającego wszystkie informacje umieszczone w pakietach w repozytorium analitycznym na podejście kontekstowe, bazujące na interesujących mnie informacjach, spiętych metamodelem. Eureka! Wreszcie! Nota bene później, ze względów sentymentalnych tak nazwałem metodykę pracy z repozytorium analitycznym, czerpiącą z moich doświadczeń. Metodyka ta stosowana jest w firmie Atena.

Przygotowany został zestaw szablonów dokumentów, wypełnianych treścią pochodzącą wprost z repozytorium a zadanie to wykonuję z wykorzystaniem narzędzia eaDocX.

Wystarczy modelować (podkreślam to słowo) w EA, zgodnie z wytycznymi (w tym przypadku metodyki Eureka) a mamy gwarancję, że przygotowane dokumenty będą spójne i zawierały tylko te informacje, których oczekuje dany interesariusz. Zakres i forma tych informacji przewidziany dla danego odbiorcy, adresuje zagadnienia występujące na danym etapie prowadzenia projektu. Na początek skupiamy się na budowaniu koncepcji rozwiązania i tu istotne będą biznesowy cel projektu i partykularne troski biznesu. Aby koncepcja była poprawna, ważne jest aby już na tym etapie referować do elementów modelu odpowiadającym planowanym pracom i zmianom w systemie. Oznacza to, każda troska biznesowa powinna być zaadresowana (lub świadomie pominięta) w zakresie projektu. Wskazujemy na elementy wymagające zmiany lub nowe jakie mają się pojawić w systemie. Tak opracowany model jest podstawą do przygotowania koncepcji rozwiązania na poziomie funkcjonalnym i architektury logicznej. A potem już tylko eaDocX… Mamy gotowy dokument dla klienta – załącznik do oferty.

Po zatwierdzeniu oferty, której integralną częścią jest powyższa koncepcja rozwijane są opisy wymagań  funkcjonalnych i następuje żmudna praca analityczna, skupiona na opisie intencjonalnym tego co system będzie realizował oraz planowaniu sposobu realizacji tych funkcjonalności, czyli przypadki użycia, prototypowanie GUI, opis logiki wewnętrznej systemu, integracji itd. A potem, już tylko eaDocX… I mamy dokument analizy szczegółowej.

Przystępujemy do fazy realizacji no i okazało się, że jednak o czymś zapomniano, coś zostało mylnie zinterpretowane. Pojawia się zgłoszenie zmiany! Należy wrócić do repozytorium i nanieść korekty. Ale uwaga, nie generujemy dokumentacji po raz kolejny a jedynie kontekst tego, co zostało dotknięte zmianą. A potem już eaDocX… no i tu pojawia się prawdziwa siła tego narzędzia! Nie musimy zastanawiać się, które elementy pobrać do dokumentu aby zilustrować skalę zmian. Wystarczy, że wskażemy te element w repozytorium poprzez relacje. A potem to już eaDocX… Możemy wysłać dokument opisujący zakres zmian CR wraz z wyceną i poprosić o akceptację.

Przykładów można mnożyć. Od pomysłowości i konstrukcji architektury informacji zależy, jak zaawansowane do kogo adresowane będą poszczególne zrzuty z modelu – dokumenty projektowe.

Wersja eaDocX bardziej zaawansowana posiada możliwość wersjonowania tych dokumentów oraz współpracy z XLS i wymiany informacji tym kanałem a następnie uzupełniania danych w modelu na podstawie danych wprowadzonych do arkusza – niemniej to funkcja pomocnicza eaDocX.

Kluczową jest funkcja przygotowania dokumentacji projektowej. Istotne jest też to, że inne informacje otrzyma manager a inne projektant, jeszcze inne tester a na koniec i tak można przygotować całościową dokumentację systemu dla określonej jego wersji w podziale na punkty widzenia istotne dla poszczególnych interesariuszy danego przedsięwzięcia ale źródło wiedzy jest jedno. Spójne. Aktualne. Zbierające i zawierające tyle wiedzy ile potrzeba.

Wydawałoby się, że to optymalne rozwiązanie. Ale czy aby na pewno? Nie dając za wygraną wciąż poszukiwałem rozwiązania, które pozwoli mi ograniczyć stosowanie podejścia 'wordowego’ na rzecz pracy w czasie rzeczywistym na aktualnych informacjach o realizowanym przedsięwzięciu. Bliski już byłem napisania własnego dodatku do EA. I tak oto znalazłem…

Otóż, okazuje się, że można lepiej, inaczej, efektywniej. Nie trzeba rezygnować z dokumentacji MS Word bo jest ona dla dużego grona czytelna i spełnia swoją rolę. Natomiast należy inaczej rozłożyć akcenty w procesie analitycznym i projektowym.

Wiadomo, że przygotowanie dokumentacji, nawet z wykorzystaniem tak dedykowanego narzędzia CASE, jakim jest EA wymaga czasu. Co więcej – późniejsza dystrybucja tej informacji zwłaszcza w podejściu klasycznym generuje inercję. Zebranie informacji zwrotnej, naniesienie jej na model, kolejna analiza wpływu… już słyszę 'Waterfall’, 'analityczne muzeum’, 'działajmy zwinnie, po co nam dokumentacja?’… Odpowiedź na te zarzuty mam jedną. Jest nią Prolaborate.

Prolaborate to nic innego jak przyjazny użytkownikowi interfejs graficzny do dystrybucji informacji o realizowanym przedsięwzięciach. Bazuje na widokach przygotowanych w EA, natomiast jego największą wartością jest wprowadzenie zwinności do procesu uzgodnień i ograniczenie zakresu informacji, podlegających obróbce. Pozwala na zdefiniowanie widoku (repository) i wybranie z (często olbrzymiego) repozytorium analitycznego interesujących fragmentów informacji a następnie dla zdefiniowanych grup użytkowników określenie poziomu dostępu do tych informacji i pracę na 'żywym organizmie’ jakim jest repozytorium, ze wszystkimi tego konsekwencjami. Czyli pozwala obserwować wpływ poszczególnych elementów modelu na pozostałe (śladowanie, impact analysis), widać aktualne statusy i inne atrybuty opisujące te obiekty. Można toczyć dyskusje na temat poprawności i aktualności zapisów dotyczących poszczególnych elementów opisu systemu. Można ewentualnie w funkcji posiadanych uprawnień dokonywać zmian w owych obiektach bezpośrednio na modelu lub wnioskować o zmiany tych zapisów w ramach toczących się dyskusji.

Prolaborate oferuje bogatą gamę integracji z takimi narzędziami jak JOOMLA, JIRA, CONFLUENCE czy wspomniany już eaDocX (w przygotowaniu kolejne integracje). Co ważne, nie wprowadza redundancji informacji a jedynie w inteligentny sposób wykorzystuje dostęp do informacji w narzędziach, z którymi się integruje i zarządza ich korelacją (korelacją informacji w nich zawartych).

Jeśli komuś nie wystarcza to, co oferuje sam Prolaborate w kontekście komunikacji i dyskusji – można wykorzystać integrację z JIRA. Komunikacja jest dwukierunkowa; z poziomu JIRA bardzo łatwo wrócić do modelu EA – za pośrednictwem linku do repozytorium Prolaborate i w ten sposób nie rozpraszać informacji zarządczej wszędzie gdzie się tylko da a bazować na jednym, spójnym repozytorium analitycznym.

Niniejszym zakres informacji, na którym pracujemy kurczy się. EA zapewnia nam jej konsystencję, możliwość analizy wpływu, analizy luk. Prolaborate wystawia tyle ile trzeba. Stajemy się zwinni, nie ma potrzeby przygotowywać kompletnej analizy. Uzgadniamy mały zakres projektu nie tracąc perspektywy całości. Możemy ten mały kawałek, już uzgodniony  skierować do biur wytwórczych a sami skupić się na kolejnej małej iteracji zakresu funkcjonalnego projektu.

Zaczynamy działać dynamicznie nie tracąc jednocześnie wartości jaką daje nam posiadanie repozytorium analitycznego.

I tu często pojawiają się pytania, czy trzeba mieć komplet informacji w EA? Oczywiście, że nie. Występuje tu tzw. efekt kuli śniegowej. Kolejne iteracje projektu dostarczają kolejnych informacji o realizowanych funkcjonalnościach i uzupełniają model. W konsekwencji wystarczy każdą funkcjonalność systemu „dotknąć” raz a jego obraz będzie w końcu kompletny.

W tym wszystkim pomoże nam Prolaborate jako biznesowy interfejs do naszego repozytorium prowadzonego w EA. Na koniec każdej iteracji procesu warto zadbać o przygotowanie dokumentacji na daną wersję systemu z wykorzystaniem eaDocX i odłożyć ją na witrynie projektowej np. na MS SharePoint, zaewidencjonować i odwołać się, kiedy ktoś zapyta o wersjonowanie i 'co było w wersji 1.12 naszego systemu? Jak działał skoro dziś mamy wersję 2.14?”. Tam należy szukać tej informacji.

Tak w skrócie wygląda podróż po narzędziach analitycznych i ich otoczeniu. Taka jest moja wizja, jak można radzić sobie z dużym zakresem informacji, jak ją efektywnie dystrybuować, jak z niej korzystać i jak na jej podstawie formułować wnioski. Wreszcie jak nie przeładować odbiorcy informacją a dostarczyć jednak kluczowych jej składników aby podnieść komfort pracy i dynamikę działań w dostarczaniu rozwiązań dla biznesu.

Wracając do podtytułu; czy to optymalne środowisko pracy? Zapewne uzupełnione, o to co w danej organizacji stosowane wcześniej (np. JIRA, Confluence itd.) dzięki zastosowaniu Prolaborate – może się takim stać. W kolejnych opracowaniach postaram się przybliżyć możliwości samego Prolaborate jak i przedstawić propozycję konfiguracji środowisk bazujących w w/w narzędziach.