piątek, 19 kwietnia 2013

Złożoność EA (1) - podejście do złożoności w architekturze korporacyjnej

Historia podejścia do złożoności w architekturze korporacyjnej wydaje się być analogiczna do historii podejścia do baz danych. Do roku 1970 bazy danych były w większości oparte o model sieciowy - rekordy bazy zawierały wskaźniki do rekordów, które zawierały wskaźniki do rekordów. Sieciowy model baz danych nie miał żadnych matematycznych, logicznych lub innych teoretycznych podstaw. Projektowanie takich baz danych było oparte na doświadczeniu i intuicji.

W 1970 roku Edgar Codd opublikował artykuł , w którym przedstawił osadzony w matematyce (bo oparty o matematyczne pojęcie relacji) model baz relacyjnych oraz sposoby walidacji, czy dane w bazie danych są dobrze lub źle zorganizowane (koncepcja normalizacji danych). Model ten był początkiem baz relacyjnych, jakie są dziś powszechnie stosowane.

Podobnie jest dzisiaj z architekturą korporacyjną. Mamy wiele metodyk projektowania architektury korporacyjnej. Jednak żadna z nich nie ma matematycznych lub logicznych podstaw. Zamiast tego polegają na doświadczeniu, intuicji czy szczęściu. Takie podejście czasami daje dobre wyniki a czasami nie. Innymi słowy wyniki konstruowania architektury korporacyjnej nie są dzisiaj ani powtarzalne ani weryfikowalne.

W swoich artykułach oraz w książce Simple Architectures for Complex Enterprises, Roger Session zaprezentował matematyczny model złożoności architektury korporacyjnej oraz ugruntowane w teorii zbiorów podejście prowadzące do zmniejszania i/lub unikania tej złożoności. Przy założeniu, że celem architekta korporacyjnego jest konstruowanie m.in. prostej architektury, podejście to może zapewnić powtarzalność i weryfikowalność wyników jej projektowania.

Ten artykuł jest pierwszym z serii artykułów poświęconych złożoności architektury korporacyjnej. Zaczynamy od jej (złożoności) zamodelowania.


Matematyczny model złożoności

Zgodnie z definicją CUEC (ang. Consortium for Untangling Enterprise Complexity): złożoność, to cecha systemu, która powoduje, że jest on trudny w użyciu, w zrozumieniu, w zarządzaniu i/lub trudny do implementacji . W swoich pracach Sessions stawia tezę, że najlepszym estymatorem złożoności systemu jest liczba znaczących stanów, w których ten system może się znaleźć (prawo złożoności oprogramowania Sessions'a).

Weźmy program, który rozpoznaje i wyświetla wynik rzutu jedną monetą - patrz poniższy rysunek (sposób wykrycia strony monety po jej rzucie jest tutaj nieistotny). Jeśli wykrytą stronę będzie orzeł, program wyświetla napis "Orzeł". Jeśli wykrytą stroną będzie reszka, program wyświetla napis "Reszka".


Program rozpoznający i wyświetlający wynik rzutu jedną monetą.


Taki program będzie miał jedną instrukcję IF badającą wartość z "czujnika" wykrywającego stronę, którą moneta upadła podczas rzutu i w zależności od dwóch możliwych wartości warunku wyświetli odpowiedni napis. Taki program będzie miał jedną zmienną o dwóch możliwych wartościach, przechowującą wynik rzutu jedną monetą. Taki program może znaleźć się w dwóch różnych stanach końcowych. Taki program ma dwie ścieżki przejścia więc w takim programie trzeba wykonać dwa testy, aby się upewnić, że program działa poprawnie. Gdyby ten program wspierał proces biznesowy sprawdzania stanu monety po rzucie jedną monetą, to ilość ścieżek w tym procesie biznesowym wynosiłaby również dwa.

Weźmy inny program, który tym razem wykrywa i wyświetla wynik rzutu dwiema ponumerowanymi monetami - patrz rysunek poniżej.

Program rozpoznający i wyświetlający wynik rzutu dwiema monetami.
Taki program będzie już miał kilka instrukcji IF rozpoznających różne kombinacje wynikowe. Taki program będzie już miał dwie zmienne, każda o dwóch możliwych wartościach, przechowujące wyniki rzutu dwiema monetami W takim programie możliwych stanów końcowych będzie wynosiła 4: orzeł+orzeł lub orzeł+reszka lub reszka+orzeł lub reszka+reszka. Taki program będzie miał już cztery ścieżki przejścia, więc w takim programie trzeba będzie wykonać cztery testy, aby się upewnić, że działa on poprawnie. Gdyby ten program wspierał proces biznesowy sprawdzania stanu monet po rzucie dwiema, ponumerowanymi monetami, to ilość ścieżek w tym procesie biznesowym wynosiłaby cztery. Widać, że po dodaniu jednej monety złożoność programu wzrosła dwukrotnie.

Istotną cechą takiego sposobu pomiaru złożoności jest to, że nawet jeśli dokładnie nie wiadomo, co to właściwie znaczy, że dany program ma złożoność 256, to wiadomo, że będzie on dwa razy bardziej złożony, niż program o złożoności 128. Z tego płynie Pierwszy Wniosek Sessions'a Złożoności Oprogramowania : relatywna złożoność dwóch systemów A i B jest taka sama, jak współczynnik wynikający z liczby stanów systemu A podzielonej przez liczbę stanów systemu B.

Z powyższych obserwacji można wyciągnąć następujący wniosek: liczba stanów systemu jest równa średniej liczbie znaczących / istotnych stanów kontrolowanych przez zmienne tego systemu, podniesionej do potęgi równej liczbie zmiennych tego systemu . System z dwiema zmiennymi, z których każda kontroluje średnio 6 istotnych stanów, jako całość może się znaleźć w 6^2 = 36 stanach. Taki system można przetestować w całości testując 36 różnych ścieżek przejścia. Reasumując, dla danego system, złożoność C tego systemu można wyrazić wzorem:
C = S^V
gdzie:
V = liczba zmiennych programu
S = liczba istotnych stanów, średnio, kontrolowanych przez każdą ze zmiennej

Liczba ścieżek w procesie biznesowym, analogicznie, równa jest liczbie punktów decyzyjnych, podniesionej do (średniej) liczby wynikowych decyzji w każdym z tych punktów. W procesie z dwoma punktami decyzyjnymi, z których każdy może skierować proces w jednym z sześciu kierunków, będziemy mieć 6^2 = 36 możliwych ścieżek przejścia procesu. Płynie stąd analogiczny do złożoności oprogramowania, sposób obliczania złożoności procesu biznesowego: złożoność procesu biznesowego jest funkcją liczby możliwych ścieżek w tym procesie (Prawo Złożoności Procesu Biznesowego Sessions'a). I analogicznie do Pierwszego Wniosku Sessions'a Złożoności Oprogramowania, Pierwszy Wniosek Sessions'a Złożoności Procesu Biznesowego brzmi: relatywna złożoność dwóch procesów biznesowych A i B jest taka sama, jak współczynnik wynikający z liczby ścieżek procesu A podzielonej przez liczbę ścieżek procesu B.

Reasumując, dla danego procesu biznesowego, złożoność C tego procesu można wyrazić wzorem:
C = P^D
gdzie:
D = liczba punktów decyzyjnych w procesie
P = średnia liczba ścieżek generowanych przez każdy z punktów decyzyjnych

Oba wzory na złożoność, złożoność oprogramowania oraz złożoność procesu biznesowego, mają postać C = x^z. Podobny wzór stosuje się w analizie probabilistycznej, gdy chcemy się dowiedzieć, ile permutacji ma dany układ D różnych kostek, z których każda ma F ścianek. Dla takiego układu liczba możliwych wyników rzutu będzie wyrażona wzorem:
O = F^D
gdzie:
O = liczba możliwych wyników rzutu kostkami
D = liczba kostek
F = liczba ścian każdej kostki

Dla przykładu, liczba możliwych wyników dla rzutu dwiema kostkami sześciościennymi będzie wynosiła 6^2 = 36.

Widać, że wszystkie 3 systemy są do siebie podobne (układ kostek, system komputerowy i proces biznesowy). Pozwala nam to na wyciąganie wniosków o jednym systemie na podstawie obserwacji cech drugiego. Innymi słowy można przyjąć, że wszystkie trzy systemy są ze sobą homomorficzne.

Model wzrostu złożoności układu

Układ złożony z 1 kostki sześciościennej ma 6 możliwych stanów, w których może się znaleźć. Układ złożony z 2 takich kostek ma już 36 możliwych stanów przy założeniu, że obie kostki są identyfikowalne (można stwierdzić, która jest pierwsza a która jest druga). W ogólności układ złożony z D kostek F ściennych ma F^D możliwych stanów. Poniższe zestawienie przedstawia liczbę stanów układu kostek sześciościennych w zależności od liczby kostek.
1 / 6 (liczba kostek / liczba stanów układu)
2 / 36
3 / 216
4 / 1.296
5 / 7.776
6 / 46.656
7 / 279.936
8 / 1.679.615
9 / 10.077.696
10 / 60.466.176
11 / 362.797.056
12 / 2.176.782.336

Przy założeniu, że układ 12 kostek jest homomorficzny z systemem informatycznym zawierającym 12 zmiennych, z których każda może się znaleźć w jednym z sześciu istotnych stanów, możemy przyjąć, że taki system będzie posiadał ponad 2 miliardy stanów, w których może się znaleźć. Podobnie z procesem biznesowym: przy założeniu, że układ 12 kostek jest homomorficzny z procesem biznesowym zawierającym 12 punktów decyzyjnych, w których można podjąć jedną z sześciu decyzji, możemy przyjąć, że taki proces biznesowy będzie posiadał ponad 2 miliardy stanów, w których może się znaleźć. Innymi słowy taki system lub proces biznesowy będzie bardzo, bardzo złożony.

Podsumowanie

W powyższym przykładzie zwiększenie liczby kostek z 11 do 12, czyli o mniej, niż 10%, powoduje sześciokrotny wzrost liczby stanów układu. Przenosząc tę analogię na system informatyczny możemy powiedzieć, że dodając niewielką liczbę funkcjonalności powodujemy bardzo duży wzrost złożoności systemu. Dlatego redukcja nawet małej liczby zbędnych elementów funkcji biznesowych, istotnie zmniejszy złożoność architektury, jako całości. A bardziej konkretnie - np. czy funkcja windykacji koniecznie musi wysyłać cokwartalne raporty? Jeśli nie - zrezygnujemy z nich. To istotnie zmniejszy złożoność procesów biznesowych i systemów informatycznych firmy.

Źródła

  • E. Codd, A relational Model for Large Shared Data Banks, [w:] Communications of the ACM, Volume 13, Issue 6, s. 377-387, czerwiec 1970, IBM Research Lab, San Jose.
  • Standard Definitions of Common Terms, CUEC (Consortium for Untangling Enterprise Complexity), www.cuec.info/standards/CUEC-Std-CommonTerminology-Latest.pdf, [2012-06-09].
  • R. Sessions, The Mathematics of IT Simplification, 2011-04-01, ObjectWatch, Inc., http://www.objectwatch.com/whitepapers/MathOfITSimplification-103.pdf, [2012-06-09]. 
  • R. Sessions, Simple Architectures for Complex Enterprises, 1 edycja kindle 2010, Microsoft Press.
  • S.N. Woodfield, An Experiment on Unit Increase in Problem Complexity, IEEE, 1979.