Raporty Enterprise Architect jako narzędzie komunikacji

W realizacji projektów informatycznych podstawowym wyzwaniem jest kwestia szeroko rozumianej komunikacji. Najczęstszymi skutkami błędów w komunikacji jest spadek efektywności, obniżenie poziomu motywacji członków zespołu projektowego oraz popełniane błędy. Skutki te dotyczą zarówno komunikacji wewnątrz zespołu, jak również komunikacji z klientem.

Wyzwanie

Aby poprawić efektywność komunikacji stosujemy różnorodne techniki modelowania. Powszechnie znane jest chińskie przysłowie mówiące o tym, że jeden obraz wart jest tysiąca słów. Ale czy to wystarcza?
Nawet, gdy opracujemy doskonałe diagramy zgodne z przyjętą notacją, z których jesteśmy dumni może się okazać, że odbiorca ich nie rozumie. A co gorsza, nie przyzna się, że ich nie rozumie i nie sformułuje żadnych uwag.  W rezultacie przedstawimy materiał, do którego klient nie jest w stanie się odnieść i go zweryfikować.
Niby wszystko się zgadza z regułami sztuki: zamiast opisu tekstowego, który bywa niedoskonały tworzymy diagramy. Załóżmy, że taki diagram jest zgodny z wybraną metodyką oraz notacją. Więc o co chodzi? Problem jest w tym, że autor modelu posiada przygotowanie techniczne, podczas gdy odbiorca modelu może go nie posiadać. Autor modelu zna dobrze narzędzie typu CASE, w którym opracował model, a odbiorca modelu może go nie znać. Zatem brak znajomości aspektów technicznych, notacji oraz narzędzia stanowi barierę w komunikacji.

Podejście TOGAF®

Problem ten został zarysowany w ramach architektonicznych TOGAF®. Sposób, w jaki to zostało opisane bardzo mi odpowiada, dlatego też chciałbym to pokrótce omówić.
Poniższy diagram pochodzi ze strony pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html, gdzie zostało opisane zagadnienie tzw. metamodelu.

Relacje pomiędzy udziałowcami, modelami i repozytorium. Źródło: The Open Group.

Najważniejsze elementy na tym diagramie, które dotyczą komunikacji to:

• Architecture Repository (pol. Repozytorium architektoniczne) - system zarządzajacy wszystkimi danymi o korporacji, w tym modelami danych i procesów, oraz informacjami o korporacji. 
• Model - reprezentacja przedmiotu zainteresowania. Model dostarcza zmniejszonego, uproszczonego i/lub abstrakcyjnego odzwierciedlenia przedmiotu modelowanego. Tworzy się go jako środek do osiągnięcia celu. W kontekście architektury korporacyjnej, przedmiotem podlegającym modelowaniu jest całość lub część korporacji, zaś zamierzonym celem jest zdolność do konstruowania widoków odpowiadających na troski poszczególnych interesariuszy, w szczególności punktów widzenia związanych z analizowanym zagadnieniem.
• Viewpoint (pol. Punkt widzenia) - definiuje perspektywę, z której ujmowany jest widok. Jest to specyfikacja konwencji dla konstruowania i używania widoku. Widok jest tym, co widzisz; punkt widzenia jest tam, skąd patrzysz - dogodnym punktem odniesienia lub perspektywą, która określa, co widzisz.
• Stakeholder Views (pol. Widoki interesariuszy) - reprezentacja zbioru powiązanych ze sobą trosk. Widok architektoniczny może być przedstawiony jako model, aby zaprezentować interesariuszom ich obszar zainteresowania architekturą. Widok nie musi mieć postaci wizualnej lub graficznej.
• Stakeholder (pol. Interesariusz) - osoba, zespół lub organizacja (lub ich klasy) zainteresowana architekturą lub posiadająca troski związane z wynikami implementacji architektury.

Powyższe definicje zostały zaczerpnięte z dokumentu TOGAF®9 Translation Glossary: English - Polish.

Co to tak naprawdę oznacza?

Repozytorium, (które może być zarządzane przez program Enterprise Architect, ale wcale nie musi) służy do przechowywania modelu opisującego architekturę. Tak naprawdę nie ma potrzeby do ograniczania się tylko do modeli architektonicznych, można tę definicję rozszerzyć na dowolne modele. Model, (który nie jest wymieniony wprost na diagramie) przechowuje informacje, które są udostępniane (komunikowane) interesariuszom w postaci widoków, które są istotne z ich punktu widzenia.
Zatem opracowując model należy mieć na uwadze również potrzeby informacyjne interesariuszy. Zamiast publikować czy udostępniać całą zawartość modelu wszystkim zainteresowanym stronom warto zastanowić się, jakiego typu informacje kogo mogą interesować.
Ale warto pójść dalej tym tokiem myślenia. Już na etapie prac przygotowawczych do projektu warto zastanowić się, z czego powinien się składać model.
Czy wystarczy ograniczyć się do modelu danych, czy może rozszerzyć go o zakres funkcjonalny, model przypadków użycia? Czy wystarczy opisać biznesowe przypadki użycia, czy rozwinąć je w niskopoziomowe - systemowe? Czy wystarczy wymienić wymagania funkcjonalne, czy również wymagania biznesowe? Czy opisać strukturę organizacji? Czy wystarczy opisać łańcuchy wartości, czy modelować procesy biznesowe? Czy stworzyć model uprawnień? Czy opisywać aspekty wdrożeniowe? I tak dalej...
Aby odpowiedzieć sobie na tego typu pytania należy wyjść od potrzeb informacyjnych interesariuszy. Bo innego typu informacji wymaga departament informatyki, innego departamenty merytoryczne, a jeszcze innego departament bezpieczeństwa. A przy tym wszystkim warto też pamiętać o programistach, z którymi trzeba rozmawiać w inny sposób niż z biznesem.
Nie wystarczy udostępnić klientowi repozytorium i powiedzieć, że zawiera ono kompletny model rozwiązania. Klient po pierwsze może mieć trudności ze znalezieniem przeznaczonych dla niego informacji. Jeśli ich nie znajdzie, to oprócz wrażenia niedosytu może nie żądać ich dostarczenia, bo nie będzie potrafić odpowiednio sformułować wymagania.

Rozwiązanie

Jak traktować te abstrakcyjne pojęcia jak widok i punkt widzenia w praktyce?

W odniesieniu do programu Enterprise Architect widoki i punkty widzenia są realizowane przez mechanizm raportowania. EA umożliwia wygenerowanie raportów w formacie HTML oraz RTF. Ponadto część informacji może być dostarczana w innej formie za pomocą odpowiednich zapytań, czy transformacji.
Widok stanowi raport wygenerowany z repozytorium. Widok ten zawiera wybrane informacje w formie tekstowej i/lub graficznej. Raport taki może być generowany wielokrotnie, w różnych wersjach powstających w miarę dopracowywania zawartości modelu.
Aby ułatwić wielokrotne generowanie raportu można stworzyć w EA jego definicję. Definicja taka określa zakres informacyjny raportu i stanowi w praktyce określony punkt widzenia interesariusza.
Definicje raportów dostępne są w EA w oknie Resources. Poniższy rysunek zawiera przykład różnych definicji raportów przeznaczonych dla różnych odbiorców.

Dzięki opisanemu powyżej podejściu polegającemu na wyjściu od potrzeb informacyjnych różnego typu interesariuszy jesteśmy w stanie opracować dla każdego typu odbiorcy dokumenty napisane w zrozumiały przez nich sposób i nie przeładowane nadmiarem informacji. Jeśli dany odbiorca będzie odczuwał niedosyt informacji, wówczas możemy wskazać mu, że interesujące go informacje są dostępne z innego punktu widzenia, czyli w innym dokumencie, z którym może się zapoznać.
Zatem postępując według zasady "każdemu według potrzeb" z jednego modelu przy użyciu mechanizmów raportowania możemy opisywać jedno rozwiązanie z różnych perspektyw.

Oprócz samego zdefiniowania zawartości raportu poprzez określenie jego sekcji warto też określić również zakres informacyjny dotyczący opisu poszczególnych typów elementów. Na przykład w odniesieniu do wymagań funkcjonalnych dla departamentu merytorycznego może być istotne źródło wymagania, opis czy uzasadnienie. Dla departamentu informatyki może być istotny priorytet i data realizacji, zaś dla programistów sposób realizacji. Po uzgodnieniu zakresu informacyjnego z interesariuszami możemy filtrować (nie pokazywać) wybranych elementów opisu. Błędem bywa generowanie raportów opartych na domyślnych szablonach programu EA, w których prezentowane są wszystkie elementy opisu. Sprawia to, że dokument może zawierać setki stron, a istotne informacje są tak rzadko rozsiane, że zniechęcają do czytania.