ArchiMate 2.0, czyli narodziny nowej gwiazdy

Luty 11, 2012

Gdzie ja byłem, kiedy rodził się ArchiMate 2.o? No tak,  zajmowałem się architekturą korporacyjną. Dopiero dziś zauważam,  że nowy standard ma wiele elementów, których brakowało młodszemu bratu ArchiMate 1.0, a które musiałem wprowadzić do środowiska sAF w formie rozszerzeń ArchiMate. To dobrze,  że specyfikujący notację zauważyli potrzebę uzupełnienia zbioru elementów o elementy zarządcze, jak choćby: zasada (ang. principle),  cel (ang. goal),  stabilizacja (ang. plateau),  luka (ang. gap).  W nowej specyfikacji znajdziemy dużo więcej elementów zarządczych. Czy, aby na pewno potrzebnych, tego nie wiem. Dziwi za to brak scenariuszy (ang. scenarios).  W zasadzie trudno jest ocenić wszystkie zmiany, ponieważ to wymaga rzetelnej analizy pełnej specyfikacji a to dopiero przede mną. Przyznam również, że trochę niepokoi mnie silne uzależnienie nowych elemenetów ArchiMate 2.0 od ADM TOGAF, tj. od podejścia tranzycyjnego. No, ale nie można było się spodziewać innego efektu, jeśli opiekę nad jezykiem ArchiMate jakiś czas temu przejęło The Open Group.

Monitorowanie jakości architektury

Grudzień 31, 2010

Wstęp

Opisana w artykule metoda monitorowania jakości architektury podlega weryfikacji. Dlatego zakładam, że artykuł ten będzie modyfikowany w momencie, kiedy pojawią się nowe przemyślenia, pomysły lub wnioski. Artykuł podzielony jest na trzy części. W pierwszej definiuję pojęcie jakości architektury. W kolejnym opisuję metodę monitorowania jakości a w ostatniej trzeciej na prostym przykładzie pokazuję, jak metoda może zostać użyta. Celem artykułu nie jest szczegółowa specyfikacja metody a przede wszystkim zrozumienie jej podstaw przez czytającego. W przypadku zagadnienia jakości architektury do pewnych przemyśleń należy dojść samemu a moim celem nie jest pozbawianie czytelnika tej przyjemności.

Funkcja czy usługa czyli kiedy funkcja może być usługą a usługa funkcją

Sierpień 25, 2010

Często dyskutując w gronie osób z branży IT pojawia się problem posługiwania się pojęciami określającymi elementy architektury i wzajemnego jednoznacznego ich rozumienia. Chodzi mianowicie o pojęcie funkcja/funkonalność, usługa, przypadek użycia, proces, podproces, zdolność (ang. capability), operacja. Pojęcia te są stosowane nie tyle zamiennie, co przypadkowo w różnych kontekstach w bardzo różny sposób. Inżynieria oprogramowania to dziedzina ścisła i dlatego przyznam bardzo irytuje mnie ta dowolność. Dowolność ta ma jednak bardzo proste wytłumaczenie. Nie, nie chodzi o niewiedzę dyskutantów a raczej o zbyt ogólne definicje pojęć serwowanych przez literaturę oraz brak określenia w gronie współpracowników uszczegółowionej definicji i kryteriów posługiwania się tymi pojęciami. No, bo przecież to wszystko jest tak oczywiste, że nie warto o tym mówić. Otóż nie, warto dlatego, że inaczej stan chaosu nie tylko w dyskusji ale i w opisie dokumentacji będzie się pogłębiać.

Identyfikowanie przypadków użycia poprzez cele użytkowników

Kwiecień 24, 2010

Pewien zespół analityczny w ciągu miesiąca musiał zrealizować jeden z etapów projektu polegający na opisie funkcjonalności aplikacji przedsiębiorstwa z użyciem przypadków użycia. Wyniki prac tego etapu były konieczne do realizacji kolejnego etapu projektu. Projekt był realizowany w dużym przedsiębiorstwie państwowym o niepowtarzalnym charakterze działalności w skali kraju. Liczba aplikacji podlegająca opisowi była bardzo duża. Część zespołu analitycznego przed przystąpieniem do prac pracowała już na rzecz tego przedsiębiorstwa, dlatego znana im była działalność przedsiębiorstwa oraz ogólne funkcjonalności aplikacji podlegających opisowi.

Scenariusze atrybutów jakościowych

Marzec 30, 2010

W ramach niniejszego wpisu, chciałbym zapoznać czytelnika z techniką ułatwiającą identyfikację i opisywanie wymagań niefunkcjonalnych, jakim są scenariusze atrybutów jakościowych. Założenia tej techniki zostały przez mnie zaczerpnięte z książki Software Architecture in Practice (2nd) autorów Len Bass, Paul Clements, Rick Kazman.

Technikę opisu atrybutów jakościowych poprzez scenariusze staram się wykorzystywać w pracy zawodowej i stosuję ją w odniesieniu do elementów architektury korporacyjnej – a więc na trochę wyższym poziomie niż zaproponowany przez autorów poziom i zakres obejmujący pojedynczą aplikację monolityczną. Tym nie mniej, technika ta zdaje egzamin również i w takich przypadkach.