Month: May 2015

Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć…

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below (click on the practice for information). At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. (Źródło: Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation)

Po co modelować?

agileModeling

Co dają nam narzędzia? Same z siebie niewiele, bo to tylko narzędzia:

agileModelingTools

 

Te książkę dla odmiany polecam doświadczonym analitykom i projektantom. 12 lat to szmat czasu e tej branży, ale doświadczony czytelnik znajdzie w niej wiele cennych wskazówek, będzie w stanie porównać swoje doświadczenia z doświadczeniem autora i zapewne wyciągnie wiele wniosków…

Jednym z moich niedawnych nabytków jest bardzo wartościowa książka, jednak nie jest to podręcznik analizy i modelowania, a opis wieloletnich doświadczeń autorów w tworzeniu i dokumentowaniu architektury oprogramowania.

The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization?s business profile, and the architect?s professional practices. The authors also have greatly expanded their treatment of quality attributes, which remain central to their architecture philosophy?with an entire chapter devoted to each attribute?and broadened their treatment of architectural patterns.

If you design, develop, or manage large software systems (or plan to do so), you will find this book to be a valuable resource for getting up to speed on the state of the art. (Źródło: Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering): Len Bass, Paul Clements, Rick Kazman: 9780321815736: Amazon.com: Books)

Autorzy opisują wszystkie aspekty architektury, od jakości, przez wydajność, cykl życia do jej biznesowych aspektów. Książka moim zdaniem jest bardzo dobrym źródłem wiedzy dla kierowników projektów, dla analityków także, ale raczej z perspektywy tego co projekt i dokumentacja architektury powinny zawierać.

Software Architecture in Practice (3rd Edition)
October 5, 2012
Len Bass (Author), Paul Clements (Author), Rick Kazman (Author)
ISBN-13: 978-0321815736 ISBN-10: 0321815734 Edition: 3rd

Wprowadzenie

Tym razem coś pozornie całkiem innego niż zwykle: żadnych klas ani procesów :). Bardzo rzadko o tym (tytuł) pisze, ale nie mało moich projektów, także tych związanych z wdrażaniem IT, zawiera w swoim zakresie “rekomendacje związane z poprawą funkcjonowania przedsiębiorstwa”. Nie możemy się tu zatrzymać na poziomie “automatyzacji przepływu pracy i efektywności interfejsu użytkownika “bo to tylko narzędzia, a narzędzia nie czynią sukcesu (no, bardzo rzadko).

Poprawa funkcjonowania firmy

Trzeba mieć świadomość, że poprawa funkcjonowania organizacji to nie tylko szybszy nowy komputer i nowe funkcjonalności oprogramowania. Warto pamiętać, że nie wykazano żadnej korelacji pomiędzy tym, które miejsce w rankingach liderów rynku zajmuje firma a tym ile wydaje ona na IT.  

Niedawno pisałem czego potrzebują dostawy aplikacji biznesowych. Dostawcy oprogramowania, które ma wspierać zarządzanie firmą…

… Potrzebują bardzo zwięzłej i spójnej dokumentacji (ale raczej 50-ciu stron niż setek, że nie wspomnę o kilku tysiącach, tak ? widywałem takie), i po stronie klienta (jednej) osoby, która ten dokument zna, rozumie, ma dostęp do kluczowych osób w organizacji. Najchętniej do autora tego dokumentu? (Źródło: Kim jest product owner? | Jarosław Żeliński IT-Consulting)

Problem w tym, że nie jest sztuką napisać (opisać) to co firma robi, sztuką jest wiedzieć i rozumieć dlaczego tak robi i czy nie może tego robić lepiej. Product Owner to ktoś decyduje o tym czym jest wdrażane oprogramowanie a najlepszym kandydatem jest autor opisu wymagań na ten produkt.

Zawsze mnie zastanawiało na jakiej podstawie dostawca oprogramowania, będąc pierwszy raz w firmie swojego potencjalnego klienta, ma odwagę powiedzieć, że jego oprogramowanie cokolwiek poprawi w tej firmie?

Analiza organizacji i projektowanie zmian

Podmiot gospodarczy to podmiot działający na rynku, i w związku z tym podlega prawom ekonomii. Szeroko pojętej ekonomii. Bez jej znajomości i rozumienia, żadna analiza biznesowa nie ma sensu! To co widzę pod nazwą Analiza Biznesowa, to nie żadna analiza biznesowa tylko lepszy lub gorszy opis (struktura) funkcjonowania firmy. Dobry opis działania jest jak opis gry w szachy: reguły gry, zły opis to kilkaset godzin filmu nakręconych nad planszą do gry w szachy [zotpressInText item=”{5085975:3K664DGK}”].

Opis działania firmy to opis mechanizmu jej działania a nie jej historia. Ta może być dowodem poprawności opisanego mechanizmu [zotpressInText item=”{5085975:6J8ZX2MR},{5085975:EMPAJKU9}”].

Druga ważna rzecz: jeżeli firma to system, to jej otoczenie rynkowe jest drugim systemem, albo “nad-systemem (super-systemem)”, albo jeżeli rynek to system, to firma jest jednym z jego podsystemów. To bardzo ważne, nie zapominajmy, że “to wszystko – rynek – to system współdziałających obiektów”. Kluczem jest to rozumienie mechanizmu jego działania, a ten mechanizm to prawa ekonomiczne [zotpressInText item=”{5085975:6J8ZX2MR},{5085975:EMPAJKU9}”].

Dzisiaj skupie się na kilku aspektach, mających duży wpływ na zrozumienie tego dlaczego firma ma pieniądze (lub zaczyna ich nie mieć…). Brzmi dziwnie ale po kolei. Powszechnie spotykanym terminem w analizach biznesowy jest “model biznesowy”. W 2006 roku już pisałem, że

Pojęcie modelu biznesowego plącze się po sieci i literaturze. Praktycznie każda firma go ma ale mało, która wie o tym i potrafi go udokumentować. Ma taki model, bo funkcjonuje na rynku ale ile firm ma te zasady udokumentowane w sposób spójny i zrozumiały dla pracowników i otoczenia? Osobną kwestią jest to, czy aktualny model jest dobry dla tej firmy bo okazuje się, że nie raz nie koniecznie. Nie raz okazuje się, że aktualny model prowadzi prostą drogą do bankructwa jednak o tym dowiadują się właściciele firm już po fakcie. (Źródło: Modele biznesowe | Jarosław Żeliński IT-Consulting)

Popatrzmy na definicje:

Model biznesowy – jest to plan, który tworzy przedsiębiorstwo w celu wygenerowania przychodu i maksymalizacji zysku operacyjnego. Określa relacje pomiędzy uczestnikami rynku, informuje jak przedsiębiorstwa działają, tj. w jaki sposób tworzą wartość dla klientów, towary i usługi oraz z czego czerpią zyski.

Jak podaje Timmers, model biznesowy to struktura produktu, usługi i przepływu informacji, zawierająca wyszczególnienie tzw. aktorów biznesowych wraz z ich rolami i opisem potencjalnych korzyści jakie odnoszą. Innymi słowy, jest to definicja źródeł przychodów[1].

Amit i Zott określają model biznesowy jako zawartość, strukturę i kierowanie transakcjami zaprojektowany w taki sposób, aby tworzyć wartość poprzez wykorzystywanie szans biznesowych.

Według Portera model biznesowy jest opisem działalności przedsiębiorstwa, które zapewniają mu zyski. Sprowadza się to do określenia roli organizacji w łańcuchu wartości, w jakim działa.

W kompleksowym ujęciu chodzi o metodę przyjętą przez firmę, przez realizację której będzie ona powiększać i wykorzystywać zasoby tak, aby oferować klientom większą wartość od konkurencji. Dzięki temu przedsiębiorstwo osiągnie wyższe zyski, a może nawet uzyska i utrzyma trwałą przewagę konkurencyjną.

Obłój definiuje model biznesowy jako ?połączenie koncepcji strategicznej firmy i technologii jej praktycznej realizacji, rozumianej jako budowa łańcucha wartości pozwalającego na skuteczną eksploatację oraz odnowę zasobów i umiejętności?. Wskazuje, że model biznesowy powinien odpowiadać na pytania: Co firma będzie robić? Jaki są jej podstawowe zasoby i kompetencje? W jaki sposób zasoby i kompetencje są skonfigurowane w praktyce codziennego działania? (Źródło: Model biznesowy ? Encyklopedia Zarządzania)

Sama główna definicja w moich oczach nie budzi wątpliwości. Popatrzmy jednak na rozwinięcia różnych autorów. Timmer mówi, że to “struktura”. U Amita i Zott’a pojawia się pojęcie “kierowanie”. Porter pisze, że to rola organizacji w łańcuchu wartości [zotpressInText item=”{5085975:2QJ8TSR7}”]. To co nazwano “kompleksowe ujęcie” zawiera pojęcie “metoda”. Obłój także raczej opisuje “strukturę”. Widać tu więc dwa główne sposoby postrzegania modelu biznesowego: (1) jest to struktura, (2) jest to mechanizm działania.

Osobiście jestem za tym, że “model” to “mechanizm” (ten zawsze zawiera swoją strukturę) z bardzo prostego powodu: model biznesowy to także model systemu jakim jest dana organizacja. Jeżeli uznamy, że model systemu to:

przedstawienie interesujących nas istotnych właściwości rzeczywistego (lub tworzonego) systemu w dogodnej dla nas postaci. Model systemu jest z reguły uproszczeniem rzeczywistości. Powinien zewnętrznie zachowywać się podobnie jak system, aczkolwiek może mieć inną strukturę wewnętrzną [zotpressInText item=”{5085975:UVCQZPJU}”].

to jeżeli ma się on (model) “zachowywać podobnie jak system (modelowany)”, to model ten musi także zawierać “mechanizm działania” (zachowania, czyli reakcje na bodźce). Mechanizm działania opisują “prawa” (reguły działania, i te narzucone i te naturalne).

 

Tak więc dochodzimy do sedna: model biznesowy. pojmowany jak wyżej, musi zawierać poza swoją wewnętrzną strukturą, także mechanizmy działania, to jak się zachowuje w określonych warunkach. Wynika z tego, że definicje modeli biznesowych określające je jako “struktury” są gruntu złe. Powodem dla których tworzymy modele, jest przewidywanie (zachowań, reakcji np. na zmiany).  Model nie zawierający mechanizmu jego działania na nic nie reaguje więc nie posłuży do żadnej analizy.

Na tym tle model (wzorzec) Lean Canvas jest wyłącznie pewną strukturą, która może posłużyć do oceny oceny organizacji, ale nie jest to model.  Model oparty np. na BMM (Business Motivation Model) zawiera między inny: strategię, taktykę, reguły biznesowe, polityki działania, czyli ustalone mechanizmy zachowania się (ograniczenia to także mechanizmy, opisałem to tu: Strategia, model biznesowy, architektura korporacyjna…).

Ekonomia i rynek

Teraz pora na ekonomię ;). Pewnie większość z Was słyszała o czymś takim jak “prawo popytu i podaży” na rynku. Otóż to znane prawo ma szerszy kontekst. Jest bardzo ważne w analizie biznesowej, bo modelując organizacje (przypominam, że model zawiera mechanizm działania i zachowania czyli reakcje na bodźce: reguły i prawa) należy zrozumieć jak się zachowują, dlaczego, i umieć to zapisać (stworzyć model). Jednak sama podaż i popyt to mało. Idąc za Porterem, kluczem jest pojęcie postrzeganej wartości dodanej, niedoboru czy nasycenia rynku.

Prawo popytu i podaży mówi, że w warunkach niezmienności innych zjawisk rynkowych, popyt zmienia się z reguły w odwrotnym co cena, a podaż w tym samym kierunku co popyt. Nadwyżka popytu nad podażą powoduje wzrost ceny, nadwyżka podaży nad popytem jest przyczyną spadku ceny. Prawo to jest słusznie uznawane za podstawę ekonomii, jednak ono samo z siebie nie daje się stosować bezpośrednio gdyż, założenie “niezmienności innych zjawisk rynkowych” jest na dzisiaj nie do przyjęcia, a same zależności nie są jednak liniowe. Tak więc to, fundamentalne prawo wskazujące na ogólny mechanizm, jest w warunkach rzeczywistych zbyt proste i ogólne, jest bezwartościowe. Do analiz należy użyć modeli zawierających opis mechanizmu działania rynku odwzorowujący rzeczywistość czyli fakty.

Pierwsza rzecz to cena tego samego lub takiego samego, produktu.

cenaAPopyt

Najprostsza z tych zależności, pokazuje, że cena spada wraz zer wzrostem popytu (bo, jak pamiętamy rośnie podaż)  rośnie podaż. Jednak nie jest to spadek liniowy i ma określony próg:  jest to koszt produktu w miejscu jego sprzedaży. Świadomie nie napisałem “koszt wytworzenia” bo to nie prawda. Koszt w miejscu sprzedaży to koszt wytworzenia plus koszt dystrybucji plus koszt sprzedaży (lokal, wynagrodzenie sprzedawcy, itp.).  Dla porządku dodałem pojęcie dumpingu czyli sprzedaż po cenie niższej od kosztów (element spekulacji i nieuczciwej konkurencji, w wielu krajach tyleż zakazany co trudny do udowodnienia).

W marketingu znane jest pojęcie substytutu: jest to inny produkt ale niosący te same korzyści kupującemu: np. (nie zawsze) wypożyczenie samochodu jest w określonych sytuacjach substytutem jego zakupu a tabletka przeciw bólowi zęba może być substytutem usunięcia bolącego zęba. Te wszystkie niuanse należy zawsze zrozumieć tworząc model biznesowy.

Kolejny wykres to uzupełnienie poprzedniego:

cenaANiedobor

Prawo popytu i sprzedaży, odbierane wprost, nie bierze pod uwagę pojęcia  wartości postrzeganej lub maksymalnej wartości akceptowanej. Przede wszystkim nie są to wartości obiektywne (w razie wątpliwości zastanówcie się ile Wy jesteście skłonni zapłacić za przedwojenny znaczek pocztowy). Należy więc, przed jej oszacowaniem, zdefiniować sobie cechy i motywację do zakupu potencjalnego klienta. To się nazywa definicją grupy docelowej. Istotne są także warunki, np. cena butelkowanej wody mineralnej rośnie natychmiast na terenach dotkniętych powodziami czy trzęsieniami ziemi (niedobór wody pitnej wywołany kataklizmem). Tak więc wzrost niedoboru jest przyczyną wzrostu cen tylko do pewnego określonego poziomu: jest nim maksymalna wartość postrzegana (wartość przy której jesteśmy skłonni do dokonania wymiany).

Popatrzmy na całość:

cenaAPodaz

(wszystkie powyższe wykresy to opracowanie własne autora)

Na tym wykresie pokazałem wpływ podaży na cenę uwzględniając powyższe “cząstkowe zależności”.  Zaczynając od niedoboru (lewa strona), cena jest najwyższa, progowa (wartość postrzegana). W miarę rosnącej podaży zaczyna spadać. Tu mała uwaga: to podaż kształtuje cenę a nie cena podaż 😉 (nie jest to symetryczna zależność). Rosnąca podaż prowadzi do ceny najniższej możliwej wyznaczonej przez koszt.

Dopiero na takim wykresie można prowadzić “badania”, ten wykres to mechanizm działania rynku (z jakiejś perspektywy i w jakimś uproszczeniu). Tłumaczy on np. mechanizm akcyzy: produkt o bardzo wysokiej postrzeganej wartości, mimo dużej podaży (np. alkohol) może mieć na rynku wysoką cenę, za sprawą Państwa, które poprzez akcyzę podnosi koszty. Jak nie trudno się domyśleć, może to zrobić wyłącznie Państwo jako jedyny legalny monopolista. To także tłumaczy, dlaczego praktycznie na całym świecie Państwa uznają wszelkie zmowy (kartele, trusty) tworzące monopole, za nielegalne dlatego, że jest to mechanizm spekulacyjny. Owszem są legalne formy monopolu takie jak patenty i prawo autorskie, jednak prawo dopuszcza je wyłącznie wtedy, gdy dane dobro nie jest uznawane za podstawowe dla życia, bo wtedy wkracza Państwowy regulator. Jaskrawym przykładem była niedawna idea państwowego podręcznika jako odpowiedź na zmowę cen ich wydawców.

W tym miejscu mała niespodzianka. Napisałem na początku, że nie będzie dzisiaj żadnych klas ani procesów, i jest to “prawie prawda” :). Otóż, gdybyśmy chcieli modelować analizowaną firmę, mielibyśmy model w postaci dwóch obiektów: Firma oraz Rynek. Ten drugi miałby operację “Za ile kupisz mój produkt”, a wynikiem tej operacji była by Możliwa Cena Zakupu tego produktu, metoda (mechanizm realizujący tę operację) była by zależnością opisaną tym ostatnim wykresem.

Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje:
– sama struktura to nie model,
– tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury,
– dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]),
bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek  zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.

(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Dwa tygodnie temu, na konferencji o jakości systemów IT, prezentowałem między innymi dwa poniższe wykresy:

Koszty rozwoju


Pierwszy wykres jest bardzo popularny w literaturze przedmiotu, tu jeden z wielu przykładów. Powołam się na niego później.

Effective software delivery. White paper. May 2009

Drugi jest wynikiem moich studiów literatury , własnych badan i doświadczenia i właśnie o nim nieco więcej. Wyjaśnię jak powstał.

W zasadzie wystarczy uznać, że jeżeli spełnienie zasady “[[open closed principle in object oriented software]]” (architektura systemu jest otwarta na rozszerzenia i zamknięta na zmiany) jest możliwe, to kod tak zbudowanej aplikacji  “rośnie” liniowo, a koszt rozwoju podobnie. Początkowy koszt, to koszt opracowania szkieletu (zwanego [[core domain]]). To właśnie – w aplikacjach konstruowanych zgodnie z [[zasadami SOLID]] – powoduje, że koszt początkowy jest relatywnie wyższy niż koszt architektury budowanej “ad-hoc” (oznaczonej ???).

Nie mam ambicji tworzenia przykładu “brzydkiej architektury”, chyba już nie umiem 😉 dlatego poniżej tylko struktura aplikacji (architektura komponentu Model/MVC) w obiektowym paradygmacie (aplikacja to współpracujące obiekty) zgodna z SOLID:

Obiektowy model dziedziny Zasada SOLID
Przykład architektury na bazie wzorca BCE (BCCE)

Model ten powstał z użyciem bloków funkcjonalnych wzorca BCE (opisałem go tu: Wzorzec analityczny Boundary Control Entity). Dla wyjaśnienia: powyższy diagram to w pełni poprawny Model dziedziny wykonany z użyciem diagramu klas UML, klasy mają stereotypy boundary, control i entity (powyżej od lewej do prawej), stereotypy te są reprezentowane symbolami opisanymi (ikonami) w BCE. Kilka cech tej architektury:

  1. każdy przypadek użycia ma dedykowaną klasę (ta połączona z aktorem) odpowiedzialną za jego interfejs i scenariusz (ale nie logikę biznesową!),
  2. scenariusz przypadku użycia to “recepta” na to, kiedy i czego wewnątrz aplikacji należy użyć do realizacji celu użytkownika,
  3. to co “potrafi” aplikacja to usługi wewnętrzne (logika biznesowa),
  4. to co aplikacja musi “wiedzieć”  zapamiętało się (jest przechowywane) w repozytoriach,
  5. żadne informacje nie są, logicznie ani w szczególności fizycznie, współdzielone: każde repozytorium, powyżej są trzy,  jest w 100% hermetyzowane (implementacja repozytoriów to absolutnie! nie jest jedna współdzielona relacyjna baza danych i mapowanie ORM!).

Widać (mam nadzieję na tym dość prostym schemacie), że każdy przypadek użycia to odrębny “serwis”, praktycznie niezależna usługa (u Fowlera nazywane mikroserwisami).  Są od siebie całkowicie odseparowane, co najwyżej korzystają z tych samych specjalizowanych usług wewnętrznych (np. z generatora plików PDF będzie korzystała każda usługa operująca na dokumentach do druku). Dodanie kolejnego przypadku użycia  w ogóle nie wpływa na resztę  aplikacji (zaleta hermetyzacji), ewentualne redundancje są raczej zbawieniem niż wadą, gdyż każda usługa ma swój kontekst i własny cykl życia, i jakiekolwiek współdzielenie treści (nie mylić z wykorzystaniem tych samych) raczej zmusi do (zgniłego) kompromisu.

Współdzielenie danych najczęściej przynosi szkody, np. współdzielenie listy produktów pomiędzy zamówieniem i fakturą powoduje zależność uniemożliwiającą wystawienie faktury na produkty inne (w innej ilości) niż na tym zamówienia (nie takie rzadkie zjawisko w dostępnych na rynku systemach ERP). Utworzenie faktury poprzez skopiowanie (wykorzystanie) zawartości Zamówienia, pozwala na jej (faktury) dowolną modyfikację bez potrzeby zmiany Zamówienia (żądania powtórnego jego przysłania lub o zgrozo, wewnętrznej korekty!). Współdzielenie danych firm pomiędzy np. fakturami i rejestrem kontrahentów, skutkuje problemem gdy aktualizacja adresu kontrahenta przenosi się na historyczne faktury. Owszem może nam się przytrafić koszt nowej usługi wewnętrznej, ale zrobimy to bez jakiejkolwiek ingerencji w dotychczasową logikę (i kod).

Aplikacje, których architektura wewnętrzna bazuje na współdzielonych danych, relacyjnej jednej bazie danych (jeden spójny system tablic relacyjnej bazy danych “pod” aplikacją), gęstej sieci wewnętrznych zależności, wymagają – dla dodania nowej usługi lub zmiany istniejącej – prawie zawsze częściowego lub całkowitego re-faktoringu, a w skrajnych przypadkach nawet migracji danych do nowej ich struktury. W efekcie, to co użytkownik postrzega jako rozszerzenie, dla dewelopera stanowi pracochłonny refaktoring, tym bardziej pracochłonny im większa ta aplikacja. Z tego powodu koszty wprowadzania zmian do tak stworzonej aplikacji są tym większe im większa i złożona jest ta aplikacja (czerwona linia na wykresie kosztu rozszerzenia funkcjonalności).

Pisanie oprogramowania ad-hoc, bez przemyślanej logiki i architektury całości, prowadzi do powstawania tak zwanego “[[długu architektonicznego]]” (analogicznie do [[dług technologiczny]]). To dlatego bardzo często źle pojmowane “agile” pozwala bardzo szybko uzyskać pierwsze efekty, niestety okupione bardzo kosztownym późniejszym utrzymaniem i rozwojem  takiej aplikacji. Chyba, że produkt taki potraktowany zostanie jako efemeryda albo jako prototyp odrzucany.

Niestety wiele systemów ERP i i nie tylko, powstało w latach 90’tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i “nad nią” funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie – jak to zachwalają ich dostawcy – zaletą…

SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu:

Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at Formal Versions Of SBVR  (Źródło: SBVR)

A dzisiaj kilka słów na temat aneksu:  Annex F – The Business Rules Approach i związku modeli pojęciowych z regułami biznesowymi. Aneks zawiera wyciąg kluczowych punktów Manifestu Reguł Biznesowych (kluczowe punkty):

  1. Pierwszoplanowe, a nie wtórne, wymagania  1.1. Reguły są pierwszoplanowymi obywatelami świata wymagań. 1.2. Reguły są kluczowe dla modeli biznesowych oraz technologicznych, stanowiąc jednocześnie ich autonomiczną część.
  2. Oddzielone od procesów, a nie zawierające się w nich 2.1. Reguły są bezpośrednimi ograniczeniami narzuconymi na funkcjonowanie organizacji jak również mogą stanowić wsparcie dla jej funkcjonowania. 2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte. 2.3. Reguły mają zastosowanie ponad i pomiędzy procesami i procedurami. Powinny stanowić jeden spójny organizm, stosowany konsekwentnie w odpowiednich obszarach aktywności biznesowej.
  3. Świadomie rozwijana dziedzina wiedzy, nie produkt uboczny 3.1. Reguły budowane są na faktach, a fakty budowane są na koncepcjach wyrażonych poprzez terminy. 3.2. Terminy wyrażają koncepcje biznesowe; fakty dostarczają stwierdzeń odnośnie tych koncepcji , reguły ograniczają oraz wzbogacają te fakty. 3.3. Reguły muszą być wyrażone explicite. Reguły nie stanowią domniemań odnośnie koncepcji, czy faktów. 3.4. Reguły stanowią podstawę tego, co biznes wie o sobie ? to znaczy, podstawę wiedzy biznesowej. 3.5. O reguły powinno się dbać; reguły powinny być chronione oraz zarządzane.
  4. Deklaratywne, nie imperatywne 4.1. Reguły powinny być wyrażane deklaratywnie w formie zdań w języku naturalnym dla docelowego odbiorcy biznesowego. 4.2. Jeżeli coś nie może być wyrażone, nie jest regułą. 4.3. Zbiór wyrażeń uznaje się za deklaratywny, gdy wyrażenia w zbiorze nie zależne od jakiegokolwiek uporządkowania. 4.4. Dowolne wyrażenie dotyczące reguł, które wymaga konstrukcji różnych od pojęć i faktów implikuje założenia odnośnie systemowej implementacji. 4.5. Reguła jest różna od jakiegokolwiek zastosowania dla niej zdefiniowanego. Reguła oraz jej zastosowanie powinny być rozważane oddzielnie. 4.6. Reguły powinny być definiowane niezależnie od tego kto, gdzie, kiedy i jak je zastosuje. 4.7. Wyjątki od reguł są wyrażane innymi regułami.
  5. Precyzyjnie skonstruowane wyrażenie, nie zlepek wyrazów 5.1. Reguły biznesowe powinny być wyrażane w sposób pozwalający na walidację ich poprawności przez ludzi biznesu. 5.2. Reguły biznesowe powinny być wyrażane w sposób pozwalający na weryfikację ich wzajemnej spójności. 5.3. Logiki formalne, takie jak logika predykatów, są fundamentem dobrze wyrażonych reguł, wykorzystujących terminy biznesowe oraz technologii implementujących reguły.
  6. Architektura oparta o reguły, nie mimowolne zastosowanie 6.1. Aplikacja reguł biznesowych jest budowana z myślą o absorpcji stałych zmian reguł biznesowych. Platforma, na której działa aplikacja powinna uwzględniać konieczność wprowadzania ciągłych zmian. 6.2. Bezpośrednie wykonywanie reguł biznesowych ? dla przykładu w silniku reguł biznesowych ? jest lepszą strategią implementacji od przekształcania reguł do postaci proceduralnej. 6.3. System reguł biznesowych musi być w stanie zawsze wyjaśnić powody dochodzenia do określonych wniosków albo podjęcia określonych akcji. 6.4. Reguły są oparte na prawdziwych wartościach. Sposób wyznaczania oraz pielęgnowania prawdziwości reguł jest ukryty przed użytkownikami. 6.5. Związek łączący zdarzenia oraz reguły ma liczność wiele-do-wielu.
  7. Procesy ukierunkowane na reguły, a nie programowanie oparte o sytuacje wyjątkowe 7.1. Reguły definiują granicę pomiędzy akceptowanymi i nieakceptowanymi działaniami. 7.2. Reguły często wymagają specjalnej lub selektywnej obsługi wykrytych odstępstw. Taka obsługa odstępstwa jest aktywnością jak wszystkie inne aktywności. 7.3. Obsługa nieakceptowalnych działań powinna być oddzielona od obsługi działań akceptowalnych w celu maksymalizacji spójności oraz zwiększenia liczby wielokrotnego wykorzystania reguł.

Kluczowe elementy manifestu pogrubiłem.

Kolejną ważną rzeczą jest zwrócenie uwagi na bardzo ważną, i w zasadzie oczywistą rzecz: liczba możliwych scenariuszy partii szachów dla człowieka jest niewyobrażalna jednak zasady gry w szachy decydujące o tych scenariuszach mieszczą się na dwóch stronach A4. Podobnie ma się rzecz z większością gier. Czemu o tym piszę? To co się z dnia na dzień dzieje w firmach i organizacjach to kolejne rozgrywki tej samej gry. Reguły są stałe: prawo i wewnętrzne regulacje, liczba możliwych scenariuszy nieskończona… Czemu więc służą żmudne wywiady, warsztaty, burze mózgów w toku analiz firm? Zaryzykuję, tezę, że niczemu nie służą. Polecam punkt 7. manifestu (powyżej). Prosty  przykład: umowa handlowa danej firmy jest ważna, jeżeli jest podpisana przez osoby uprawnione (opis w KRS). W tym momencie wypisywanie (np. na modelach procesów) wszelkich możliwych kombinacji zebrania tych podpisów jest niczym innym jak brnięciem w opisywanie kolejnych możliwych partii szachów. Robienie tego, po pierwsze nie doprowadzi do wypisania wszystkich wariantów (jest ich zbyt wiele), po drugie ewentualne tworzenie na podstawie takiego opisu, oprogramowania, nie doprowadzi do postania sensownego systemu bo będzie z zasady (zbyt wiele kombinacji do opisani) niekompletny.

Pora na SBVR, stanowi on w dużym stopniu sformalizowaną i rozszerzona wersję Manifestu Reguł Biznesowych (autorzy Manifestu są współautorami SBVR, pracują dla OMG).

How SBVR Supports the Business Rules

Czym jest reguła biznesowa? Podam przykład:

Każdy wniosek zakupowy, którego wartość przekracza III próg decyzyjny, musi być kierowany do zatwierdzenia przez członka zarządu, za wyjątkiem zamówień na surowce do produkcji z tytułu zawartych umów.

Popatrzmy na powyższą regułę i diagram nad nią. Kolorem czarnym oznaczono “operatory”, kolorem czerwonym kluczowe pojęcia (koncepty) zaś zielonym “fakty” (czasowniki związane z pojęciami), które łączą logicznie pojęcia. Kluczowe pojęcia to “byty” w biznesowej przestrzeni nazw, wymagające precyzyjnej definicji.

Nie brnąc w szczegóły, wyobraźcie sobie teraz – wiedząc, że rodzajów kosztów  jest bardzo dużo, jak wyglądał by model procesu, mający opisać je wszystkie? A wystarczy na modelu procesu biznesowego użyć pojęcia (nośnik danych w BPMN) Wniosek zakupowy, rolę Członek zarządu, pojęcie Zamówienie, zdefiniowane pojęcie “próg decyzyjny” oraz powołać się na powyższą regułę biznesową, by stworzyć model procesu przyjmowania faktur kosztowych łatwy w percepcji i nie zajmujący więcej niż stronę A4.

Do testowania modelu pojęciowego tworzy się, opisany w specyfikacji SBVR, diagram faktów.  Modele pojęciowe można tworzyć z pomocą diagramu klas notacji UML (patrz tekst Cholerny diagram klas).  Jednak w SBVR diagram faktów to nie jest diagram klas. Diagram faktów opisałem w artykule Reguły biznesowe jako motor... tu tylko wyjaśnię, że diagram faktów to diagram zawierający wyłącznie kluczowe pojęcia słownika pojęć oraz fakty (patrz wyżej kolor zielony) je łączące.

Reguły biznesowe, także jako wymagania, są elementem modeli modelu bezsensowego CIM w MDA:

sbvr_MDA-CIM_Model

Na koniec jako przykład model pojęciowy i tekst na bazie którego powstał (analiza opisu spółki giełdowej):

Model pojęciowy