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.

Jakość architektury

Jakość to pojęcie określające zespół atrybutów produktu lub usługi, które noszą w sobie zdolność zaspokojenia określonej potrzeby (patrz. [1]) lub właściwość jednostki odnosząca się do jej zdolności zaspokojenia atrybutów jakościowych (patrz [1]). W przypadku jakości architektury pojęcie to nabiera znaczenia, które często sprowadza się do zadania pytania: no właśnie, co upoważnia nas do mówienia o tym, że architektura w naszym przedsiębiorstwie jest dobra, albo nie jest dobra?

Punkt widzenia

Nie można myśleć o jakości z perspektywy tylko jednego interesariusza, bo będzie to wybiórcze potraktowanie problemu. Wyobraźmy sobie, że jakość architektury obserwujemy dla atrybutu jakościowego wydajność aplikacji. Niech miarą wydajności będzie liczba przetwarzanych żądań na minutę. Czym wyższa wydajność tym lepiej dla właściciela systemu. Wydajność aplikacji wpływa na utylizację zasobów obliczeniowych, które również z powodu wzrostu wydajności wzrastają, co z punktu widzenia menedżera zasobów może, ale nie musi być korzystne (ponieważ utylizacja zasobów uzasadnia ich bytność oraz możliwość rozbudowy). No, ale pies jest pogrzebany gdzie indziej. Otóż wzrost wydajności i utylizacji może wpływać niekorzystnie na czas odpowiedzi po stronie użytkownika, który zainteresowany jest głównie ergonomią i szybkością prac z aplikacją. Na tym przykładzie widać już, że mówienie o jakości architektury z jednego wybranego punktu widzenia, np. architekta, który stopień zgodności rozwiązań ze standardem (np. SOA) uznaje za najważniejsze z kryteriów jest niewystarczające i prowadzi do niewłaściwych wniosków. Chcąc oceniać jakość trzeba brać pod uwagę dla określonych atrybutów różne punkty widzenia.

Z punktu widzenia każdego interesariusza jakość w odniesieniu do rozwiązania ma inne znaczenie. Np. dla testera architektura dobrej jakości to taka architektura, która pozwala na szybką lokalizację błędów. Dla pracownika operacyjnego ważna jest wydajność, ergonomia, niezawodność. Dla pracowników marketingu dobra architektura to taka, która pozwala na szybkie i tanie wprowadzanie nowych produktów i usług.

Architektura

Należy pamiętać, że samo pojęcie architektury ma wiele znaczeń. W rozumieniu architektury korporacyjnej przez architekturę rozumieć będziemy zestaw elementów oraz zdefiniowanych relacji pomiędzy nimi (model), które to elementy i relacje odnoszą się do stanu bieżącego (opisuje architekturę obecnie działającą w przedsiębiorstwie), docelowego (stan oczekiwany), lub stanów pośrednich (stany pośrednie pomiędzy architekturą bieżącą i docelową).

Cele architektury korporacyjnej

W największym skrócie można napisać, że dyscyplina, jaką jest architektura korporacyjna dąży do zbalansowania jakości reakcji na zmiany w otoczeniu (cel: zwinność) w stosunku do spójności rozwiązań wynikających z tych zmian (cel: spójność). Równoważenie zmian wynikających z potrzeby reakcji na otoczenie (zwinność) a spójnością obszarów i warstw w przedsiębiorstwie to zadanie, ale i wyzwanie dla architektury korporacyjnej.

Trzy warstwy architektury korporacyjnej

Jakość architektury w ujęciu architektury korporacyjnej powinna dotyczyć trzech warstw (biznesowa, aplikacji, infrastruktury). Wybiórcze spojrzenie na architekturę przedsiębiorstwa poprzez monitorowanie tylko jej wycinka nie spowoduje, że mierząc jakość architektury będziemy w stanie wyciągać wnioski, które następnie będzie można uznać za obiektywne.

Dziewięć obszarów architektury

W każdej z warstw wyróżnić należy trzy obszary (patrz [2]) – informacje, zachowania, struktury. W każdym z obszarów istotne są inne elementy architektury i to te elementy powinniśmy poddawać monitoringowi.

Rysunek 1 Obszary przedsiębiorstwa

Metoda

Szukamy mechanizmów, które pozwolą ocenić jakość podejmowanych decyzji architektonicznych. Tak, jak rezultat podjętej decyzji możliwy jest do weryfikacji na zasadzie – „zrealizowany” lub „niezrealizowany”, tak w przypadku jakości architektury prosta weryfikacja jest niemożliwa. Ponieważ, jak napisałem w pierwszym zdaniu na jakość składa się wiele czynników (atrybutów jakościowych) oraz zależności między tymi atrybutami, których właściwe wysterowanie jest dopiero wyznacznikiem tego, czy architekturę można uznać za „dobrą”, lub „złą”. Rzadko kiedy jednak ze stuprocentową pewnością będziemy mogli stwierdzić, że architektura, którą kontrolujemy, jest faktycznie dobra, bo taka ocena najczęściej opiera się na subiektywnych przesłankach. Aby ten subiektywny pogląd był jednak bliski obiektywnemu spojrzeniu istotne jest racjonalne dobranie atrybutów, które będziemy kontrolować.

Przedsiębiorstwo

Zmiany w przedsiębiorstwie mają różną przyczynę i różne „paliwo” napędzające zmianę, tak jak i architektura przedsiębiorstwa opisywana jest różnymi kryteriami. W zależności od tego, czy dane przedsiębiorstwo nakierowane jest na zwinność (przedsiębiorstwo napędzane wymaganiami) czy na spójność (przedsiębiorstwo napędzane kosztami) zależeć będzie sam zestaw atrybutów jakościowych, które należy brać pod uwagę przy monitorowaniu jakości.

Postulat

Tworząc metodę monitorowania należy mieć na uwadze kulturę pracy organizacji, w której zostanie użyta. Przez kulturę pracy rozumiem między innymi możliwość użycia metody. Trudno jest, bowiem tworzyć metodę opartą o symulacje, czy silnie ukierunkowaną na analizę ilościową w sytuacji, kiedy organizacja danymi dobrej jakości nie dysponuje, lub kiedy sam proces prowadzenie a wcześniej przygotowania symulacji będzie dłuższy od niejednego cyklu zmian w przedsiębiorstwie lub bardziej kosztowny od samej zmiany. Dlatego tworząc metodę należy oprzeć ją na prostocie i ewentualnie w trakcie użytkowania metodę usprawniać, modyfikować, czy nawet komplikować.

Metoda

Poniżej zamieszczam prostą metodę monitorowania jakości architektury w przedsiębiorstwie. Przy czym przez architekturę rozumiem tutaj jej stan bieżący, lub przyszły. Zasadniczo jednak metoda ta lepiej sprawdzać się będzie na rzeczywistych danych. Metoda zbudowana jest w oparciu o założenia środowiska sAF (patrz. [3]), ale do jej zrozumienia znajomość środowiska nie jest potrzebna.

Dziedziny celów

Cele architektury korporacyjnej to zrównoważenie realizacji celów poprawy zwinności i stałego wzrostu spójności. W zależności od tego, czy architekturę napędzają wymagania czy np. koszty inny nacisk będzie kładziony na zwinność a inny na spójność. Dla poprawy zwinnościowi dziedziną tego celu są wymagania (przypadek użycia, wymaganie na nowy produkt, ofertę, itd.) a dla poprawy spójności dziedziną celu są żądania (zamówienie, dokument przetwarzany w aplikacji, itd.).

W przypadku wymagań istotne jest abyśmy zdawali sobie sprawę z jednego faktu -wymagania muszą podlegać klasyfikacji na te, które wynikają z celów strategicznych i na wymagania pozostałe. Dlaczego? Architektura korporacyjna skupiać się powinna na dostosowaniu przedsiębiorstwa do realizacji celów strategicznych, ponieważ wynika to z jej statusowych zadań. Trudno oceniać jakość architektury w sytuacji, kiedy wymagania nie wynikają z celów a są wręcz sprzeczne w stosunku do strategii firmy i budowanych od lat rozwiązań mających te cele realizować.

Atrybuty

Cele architektury korporacyjnej definiowane są bardzo ogólnie. Dlatego konieczne jest zdefiniowanie atrybutów, dla których następnie będziemy badać zachowania w obszarach. I tak, dla zwinności atrybutem tej zwinności może być szybkość reakcji na zmianę (TTM), zdolność konfiguracyjna, zdolność testowa, itd. Dla spójności może to być integracja (ludzka, maszyny), niezawodność, wydajność, zgodność ze standardami, itd.

Scenariusze

W środowisku sAF do opisu sposobu mierzenia danego atrybutu stosuje się scenariusze. Scenariusze definiowane są na potrzeby mierzenia osiągania pewnych poziomów w obrębie atrybutów (instancje scenariusza). Sama definicja scenariusza bez wskazania wartości bieżących, docelowych, służy do mierzenia stanu, na jakim architektura obserwowana przez scenariusz znajduje się faktycznie.

Scenariusz powinien być opisany tak, aby było wiadomo jak można go zweryfikować, tj. czego dotyczy i co w rezultacie jego weryfikacji otrzymujemy. Najlepiej, jeśli scenariusz pozwala przekształcić wartości dziedziny na wartości funkcji, której swoistą reprezentacją jest sam scenariusz, np. Sc. Liczba komponentów modyfikowanych dla żądania dodania nowej oferty handlowej, jest przykładem scenariusza gdzie wymaganie zostaje przekształcone na działania w komponentach a wartość funkcji określa liczbę zmienianych komponentów. Przy czym dla potrzeb monitorowania jakości architektury może się wydać również zasadne, a może nawet bardziej zasadne, budowanie scenariuszy działających na całych dziedzinach, tj. np. Sc. Liczba komponentów modyfikowanych w ramach paczki wymagań realizowanych w cyklu półrocznym.

Rysunek 2 Powiązanie pomiędzy celem, atrybutem i scenariuszem

Zależności

Konieczne jest również określanie zależności pomiędzy atrybutami. Przykładowo szybkość zmian (cel: zwinność) bardzo mocno zależy od zdolności konfiguracyjnych (cel: zwinność). Zdefiniowane zależności mogą posłużyć do wiązania atrybutów i ich scenariuszy w grupy, lub analizy wielowymiarowej, tj. obejmującej nie tylko jeden scenariusz a powiązane scenariusze.

Monitorowanie

W najprostszym wydaniu monitorowanie może być oparte o niezależne śledzenie zmian poszczególnych scenariuszy lub poprzez zestawienia scenariuszy tego samego atrybutu lub różnych atrybutów. Np. można weryfikować trend zmian dla niezawodności (cel: spójność) w stosunku do funkcjonalności systemów (cel: spójność), lub niezawodności (cel: spójność) i szybkości (cel: zwinność).

Metoda

Poniżej zamieszczam w punktach najważniejsze czynności metody:

1. Określanie atrybutówW obrębie celów architektury zdefiniuj najważniejsze atrybuty jakościowe istotne dla przedsiębiorstwa.
2. Definicja scenariuszyDla każdego atrybutu zdefiniuj scenariusze na poziomie obszarów lub elementów obszarów, dla których zainteresowanie wyrażają interesariusze i które można weryfikować. Określ wartości docelowe lub właściwy trend zmiany dla scenariusza.
3. Monitorowanie

Monitoruj zmiany i zależności pomiędzy powiązanymi wartości wynikających z zastosowanych scenariuszy po zastosowaniu decyzji architektonicznych w cyklach, tj. jednostkach czasu, które są istotne dla twojego przedsiębiorstwa, np. co pół roku, lub po ukończeniu projektu, grupy projektów, itd.

Przykład

W teorii metoda wydaje się prosta. Jakość weryfikujemy poprzez obserwację zbioru atrybutów opisywanych przez scenariusze. W praktyce tak to jednak nie wygląda, ponieważ przy próbie określania samych atrybutów pewnie nie raz zatrzymamy się zaczniemy zastanawiać. Jeszcze trudniejsze jest właściwe zdefiniowanie scenariuszy. Istotne jest natomiast to, że robimy to tylko raz i nie koniecznie wszystko musimy zrobić od razu.

Poniżej opiszę przykład, który na pewno pozwoli zrozumieć metodę. Przykład zostanie zbudowany w oparciu o dwa cele i jeden atrybut dla każdego celu.

Kontekst dla przykładu

Pewne przedsiębiorstwo napędzane nie kosztami a rosnącą liczbą wymagań chce, aby architektura przedsiębiorstwa była gotowa na zmiany. Szybkość zmian jest krytyczna dla tego przedsiębiorstwa, ponieważ pragnie być liderem usług na rynku.

Zastosowanie metody

Ad 1. Określanie atrybutów

Przedsiębiorstwo z przykładu głównie skupia się nie na kosztach a na realizacji wymagań. Dlatego też najważniejszym z atrybutów (i jedynym w przykładzie) dla celu zwinność będzie zdolność konfiguracyjna. Dla statutowej działalności architektury korporacyjnej istotna jest również spójność i tutaj za atrybut niech posłuży wydajność.

Ad 2. Definiowanie scenariuszy

Ponieważ architektura korporacyjna zajmuje się trzema warstwami przedsiębiorstwa dla każdej warstwy zdefiniujemy przynajmniej jeden scenariusz. Skupię się na aspektach przetwarzania procesów biznesowych.

Zakładam, że:

paczka wymagań – to liczba wymagań zgodnych z wymaganiami strategicznymi,

paczka zamówień – określona liczba zamówień istotna z punktu widzenia wydajności architektury,

zmieniany – oznacza modyfikowany, dodawany lub usuwany.

W ramach poprawy zwinności atrybut zdolności konfiguracyjne (procesu) opisywać będą scenariusze w tabeli 1.

Tabela 1 Scenariusze monitorowania zwinności w obszarze konfiguracji

W pustych obszarach nie zdefiniowałem scenariuszy.

W ramach poprawy spójności atrybut wydajność (procesu) opisywać będą scenariusze w tabeli 2.

Tabela 2 Scenariusze monitorowania spójności w obszarze wydajności

Prezentowane powyżej scenariusze to jedynie wstępne propozycje pozwalające jedynie zrozumieć ideę i źródło do przemyśleń. We własnym wdrożeniu metody dobremu zdefiniowaniu scenariuszy należy poświęcić sporo czasu.

Ad 3. Monitorowanie

Ten punkt metody trudno jest opisać na czysto teoretycznym przykładzie. Ważne jest, aby zbudować miejsce, w którym wartości dla scenariuszy będziemy mogli składować po to, aby następnie porównywać je ze sobą, jak i porównywać trendy zmian.

Wskazówki

Zamieszczam również kilka wskazówek, które mogą uchronić potencjalnego użytkownika metody przed potencjalnymi pułapkami.

1. Nie liczba scenariuszy a ich definicja oraz możliwość faktycznej ich weryfikacji jest istotna.
2. W ramach każdego atrybutu scenariusze powinny opisywać te same operacje w obszarach, np. tworzenie, modyfikowanie, usuwanie, konfigurowanie.
3. Scenariusze opisujące pojedyncze elementy architektury (w ujęciu architektury korporacyjnej) są lepsze od tych opisywanych na poziomie obszarów, a te są lepsze od scenariuszy definiowanych na poziomie warstw.
4. Scenariusze dla dziedzin nie wydają się mieć związku z jakością architektury a jakością prac zespołów architektonicznych. Np. stosunek liczby wymagań zgodnych z celami architektury (celami strategicznymi przedsiębiorstwa) do liczby wszystkich wymagań nie daje odpowiedzi w żaden sposób czy architektura jest właściwa za to może powiedzieć na ile świadomie definiuje się wymagania w firmie. Czym współczynnik niższy tym świadomość i zestrojenie architektury korporacyjnej są niższe.
5. Warto dokładnie opisać, czym są operacje konfiguracji, modyfikacji, usuwania i dodawania w obszarach przedsiębiorstwa.

Kwestie otwarte

Jak napisałem na początku, metoda podlega weryfikacji. Pewne problemy czekają wciąż na rozwiązanie. Do najważniejszych kwestii otwartych zaliczyłbym te przedstawione poniżej.

1. Kiedy wiadomo, że pokrywamy wszystkie atrybuty i właściwie określamy dla nich scenariusze?
2. Jak nie blokując prac zespołów architektonicznych i analitycznych klasyfikować wymagania na wymagania zgodne ze strategią od tych, które zgodne nie są?
3. Czy zawsze lepiej budować scenariusze w ramach całych dziedzin, czy dla konkretnych argumentów tej dziedziny, np. dla konkretnego typu wymagania, czy dla całych paczek wymagań?
4. Czy dla każdego atrybutu konieczne jest określenie scenariuszy w każdym obszarze?

Odnośniki

[1] http://pl.wikipedia.org/wiki/Jakość

[2] ArchiMate – język modelowania architektury korporacyjnej – czy potrzebujemy kolejnego języka modelowania?

[3] Środowisko sAF