Obydwa te, spotykane często w prasie, skróty mają wiele wspólnego: oznaczają aplikacje zarządzające obiegiem informacji i jej magazynowaniem (ECM – Electronic Content Management czyli zarządzanie treścią w postaci elektronicznej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawartą “nie wprost” w tych nazwach  jest zarządzanie także składowaniem i przepływem tej informacji. Osiem lat temu pisałem o kwestiach pojęciowych (czym jest wiedza, jej przetwarzanie, czym są dane):

Problematyka informacji w firmach, jej kolekcjonowania i przetwarzania jest częstym tematem artykułów w prasie specjalistycznej jak i opisem zakresów projektów IT. Termin ten jest jednak nie raz nadużywany. W prasie można pozwolić sobie na pewną dowolność jego interpretacji jednak w opisie zakresu projektu analitycznego pozycja o nazwie ?Zdefiniowanie potrzeb informacyjnych firmy? może rodzić poważne kłopoty z odbiorem tej części projektu gdyż tu na dowolność interpretacji nie powinno być miejsca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)

Niedawno, 26 stycznia 2016, miałem referat  na konferencji pod hasłem Business Process Management:

W trakcie referatu zwróciłem uwagę na to, że to co często nazywamy zarządzaniem procesami  (popularny skrót [[BPM]]) biznesowymi, tak na prawdę jest zarządzaniem przepływem pracy, zarządzaniem informacją i nadzorowaniem tych aktywności. Tu zwrócę uwagę na to, że przepływ pracy odwzorowywany jest w aplikacji jako ciąg raportów i notatek:

przełożony dowiaduje się o wykopaniu rowu nie z własnej obserwacji a z raportu swojego podwładnego 

dlatego oprogramowanie może operować wyłącznie udokumentowanymi faktami a nie zjawiskami w realnym świecie: to są zapisy jakimi zarządza oprogramowanie zarządzające szeroko pojętą treścią. Tak więc

zarządzanie procesami biznesowymi to nic innego jak zbieranie informacji, przetwarzanie ich i decydowanie o kolejnych pracach do wykonania, informując o tym wykonawców tych kolejnych prac.

Aplikacja wspierająca przepływ pracy to oprogramowanie, które pozwala na tworzenie formularzy (i zasad weryfikacji ich poprawności) specyficznych dla każdego zadania, reguł biznesowych narzucających opcjonalność i kolejność realizacji zadań (aktywności), kategoryzowanie treści i zadań, udostępnianie powstałych treści:

Powyższy diagram przypadków użycia można w zasadzie uznać za “referencyjny”, każda aplikacja tego typu tak mogła by wyglądać, czy to wystarczy dostawcy oprogramowania? Nie, bo cała wiedza o konkretnym wdrożeniu tkwi w szczegółach. Gdzie one są? Pisałem o tym prawie rok temu:

Tu warto na początek wrócić do klasyfikacji wymagań. W artykule Inżynieria wymagań opisałem trzy ich rodzaje: (1) funkcjonalne czyli usługi aplikacji (przypadki użycia tej aplikacji), (2) poza-funkcjonalne czyli cechy jakościowe, (3) dziedzinowe czyli logika biznesowa. I teraz bardzo ważna rzecz: które elementy architektury oprogramowania, za realizację których wymagań odpowiadają? (Źródło: Gdzie są te cholerne szczegóły | | Jarosław Żeliński IT-Consulting)

Jak widać, klucz tkwi w modelu dziedziny systemu czyli w specyfice branży, konkretnej firmy lub organizacji. Powyższe przypadki użycia, jak wyżej, to opis “dowolnego ECM/EOD”. Referencyjna architektura takiego systemu mogła by mieć taką postać:

Dlaczego tak? Komponent zarządzający procesami odpowiada za logikę kolejności przetwarzania treści. Repozytorium odpowiada za zachowywanie i udostępnianie treści. Dodano tu komponent Filesystem, gdyż osobiście jestem zwolennikiem podejścia, w którym dokumenty elektroniczne są składowane nie w bazie danych (tak zwane BLOB) a na dyskach, a logika zarządzania nimi to odrębne oprogramowanie (patrz europejksie zalecenia Moreq). Dzięki temu utrata lub zmian aplikacji (i bazy danych) nie powoduje utraty zasobów.

Na czym więc polega analiza biznesowa przed wdrożeniem EOD/ECM? Czym są tu wymagania? Są nimi reguły biznesowe, wzory dokumentów i słowniki pojęć (danych). To tu tkwi największe ryzyko wdrożenia, kluczem jest tu zawsze tak zwany model pojęciowy. Powyższa architektura jest przeze mnie traktowana jako referencyjna, gdyż gwarantuje możliwość odwzorowania dowolnego “systemu zarządzania informacją”, taką lub podobną zalecaną architekturę można spotkać w wielu opracowaniach na temat ECM.

Kolejna książka, tym razem coś w rodzaju podręcznika, zbioru metod. Jest to praca zbiorowa. Polecam wszystkim osobom, których rolą jest między innymi dokumentowanie architektury systemów IT. Wiele przykładów opartych o UML, SysML oraz planowany do upowszechnienia AADL (Architecture Analysis and Design Language). Ten ostatni jest w sferze planów, zobaczymy… (more…)

Szperałem w sieci szukając informacji o architekturze i microservisach, a wpadłem na to:

… communication between two different software modules is proportional to the communication between the designers and developers of these modules. Conway?s law exposes the vulnerability in monoliths as they grow in size. Micro-services may not be the best, but better than monoliths for the contemporary web based applications. (Źródło: Micro-Services: A comparison with Monoliths | My Blog)

To “prawo” wyjaśnia dlaczego powstają złe interfejsy a nawet zła architektura: z reguły dlatego, że to – architektura – jest lepszym lub gorszym kompromisem pomiędzy zespołami programistów, ich obciążenia, krótkich terminów itp. Obserwuję to dość często w organizacji pracy developerów.

Jednak, żeby powstała taka “dobra architektura”, ktoś “ponad zespołem developerów” powinien zaprojektować architekturę: komponenty z ich odpowiedzialnościami i interfejsy między nimi.

Typowym problemem jaki napotykam, nie tylko w dużych projektach dla “budżetówki”, jest architektura będąca efektem przepychanek, polityki, walki o “mendejsy”, czyli o to który dostawca  (albo wewnętrzny zespół) dostanie większy budżet. To najgorsze i niestety nie raz spotykane metody budowy architektury.

Jak to robić dobrze? Idąc za Fowlerem, podstawą budowy (ustalania) granicy odpowiedzialności komponentu jest “granica kontekstu”. Można to przedstawić tak:

Powyżej pokazano wynik analizy, mamy tu model pojęciowy. Widać, że pewne pojęcia (docelowo klasy, ich operacje i atrybuty) są dość gęsto powiązane, inne luźno. Granice pomiędzy komponentami  powinno budować się tak, by silnie powiązane elementy były w jednym komponencie (nigdy nie rozdzielaj rodziny) a interfejsy między nimi były jak najprostsze. Stosowanie DTO oznacza, że komponent powinien jednorazowo zażądać całego agregatu danych (dokumentu) i samemu skorzystać, nawet tylko z części danych które dostał, zamiast detalicznie prosić o poszczególne pola. Innymi słowy niezależnie od tego czy w danym momencie potrzebujemy tylko wartości konkretnej faktury, danych nabywcy czy faktycznie całej jej zawartości, zawsze żądamy całej faktury. Dzięki temu interfejs (API) jest prostsze, liczba wywołań API jest zawsze mała. Powyższy przypadek zaowocuje poniższym podziałem na komponenty:

Metoda ta i podejście (jako dobra praktyka), i u Fowlera (cytowany DTO) i u Evansa (autor wzorca Domain Driven Design) nazywana jest “bounded context” (granica kontekstu, rodzina zawsze razem i tylko jedna rodzina w jednym mieszkaniu). Dzięki temu uzyskujemy bardzo dobry, przy okazji zgodny z zasadą “[[Open Close Pryncypia]]”, model architektury, który pozwala zlecić komponenty do wykonania, definiując wyłącznie opracowane już interfejsy, kolejność ich (komponentów) wykonania nie ma znaczenia dla całości.

Przy okazji ujawnia się “zło” jakie wyrządza budowanie złożonego oprogramowania na bazie integracji poprzez współdzielenie danych:

Komponenty są silnie od siebie uzależnione (współdzielona baza danych w modelu relacyjnym), nie da się tworzyć (kodować) tych komponentów niezależnie od siebie, bo trzeba uzgadniać a potem uznać, wspólny model danych. Ingerencja w jakikolwiek komponent z reguły oznacza ingerencję w całą aplikację.

Dzieląc system na niezależne komponenty (każdy komponent sam zarządza swoimi danymi) , ustalamy integrację z użyciem interfejsów a nie współdzieląc dane, z czego całkowicie rezygnujemy:

To jest powód dla którego, w dobrych firmach developerskich kluczową rolę pełni architekt. Na poziomie logiki biznesowej, w zasadzie jest nim – takim architektem – analityk biznesowy-projektant, który po zakończeniu etapu analizy i projektowania, pełni rolę “[[product ownera]]”, prowadzącego nadzór autorski i zarządzanie zmianą wymagań.

Tak więc architektura powinna być efektem głębokiej analizy i projektowania z testami, dopiero potem powinna się stać – być może każdy komponent osobno – materiałem do zlecenia dla developerów. Najgorszy wariant to podział na komponenty z pomocą negocjacji, polityki i walki o budżet. 

Niecały miesiąc temu polecałem artykuł firmy Jamasoftware, na temat “ewolucji” Manifestu Agile:

Czyli jest czas by wyciągnąć wnioski. …

Źródło: Modernizacja Manifestu Agile | Jarosław Żeliński IT-Consulting

Celem było zwrócenie uwagi na wnioski z ponad dziesięcioletniego korzystania z metodyk zwinnych: jednak przeproszono się nieco z analizą i projektowaniem.

Dzisiaj z tego samego tekstu Jamasoftware przywołam inną konkluzję:

Kluczowe zmiany jakie zaszły od momentu opublikowania Manifestu Agile (rok 2001) to:  dysponujemy nadmiarem informacji, coraz więcej rzeczy nie jest dokumentowanych, rosnąca luka komunikacyjna w rozproszonych zespołach, dramatycznemu skróceniu uległ wymagany czas na opracowanie nowego produktu (lub jego nowej wersji), rosnące oczekiwania użytkowników. Co ciekawe odsetek porażek w projektach IT nie zmienił się od tamtej pory…

Do tego dochodzi “rosnąca inteligencja” urządzeń a nawet całych ich systemów, mamy “internet rzeczy”, oprogramowanie “embedded” itp.  Tak zwane “smart-” jako przedrostek wielu nazw urządzeń czy całych linii produkcyjnych. W efekcie system IT nawet średniej firmy staje się niejako z musu systemem komponentowym.

W efekcie powstaje drugi powód, dla którego wielkie zintegrowane ERPII zejdą do niszy jako “całościowe wdrożenia”. Pierwszy powód opisałem tu “Nigdy więcej ERP w jednym kawałku!” (koszty wdrożenia i mała podatność na zmiany, centralna współdzielona baza danych jak kluczowe ograniczenie).

Drugim powodem jest trend do przesuwania “inteligencji” w stronę sprzętu ([[embedded software]]) do tego stopnia, że   np. nowoczesna hala magazynowa wysokiego składowania ma swój wbudowany system WMS ([[Warehouse Management System]], system zarządzania magazynem) a dostawcy zaawansowanych linii produkcyjnych dostarczają współpracujące systemy MES ([[Manufacturing Execution System]], system zarządzania produkcją) i CAD/CAM (a nie raz i PLM – zarządzanie cyklem życia produktu).

W efekcie systemy nazywane nadal ERP to raczej już tylko jądro zarządzania (nadal bardzo ważne) integrowane z dziedzinowymi podsystemami (np. wymienionymi wyżej) innych producentów, aniżeli wielki zintegrowany, kosztowny i we wdrożeniu i w utrzymaniu moloch. ERP w reklamowanej jako “system do wszystkiego” ma raczej sens w małej firmie o nieskomplikowanej działalności, większe firmy wymagają jednak większej podatności ma zmiany czego ERP w “jednym kawałku” nigdy nie da, a duży jednorazowy koszt jest zbyt wielkim ryzykiem.

O analizie pojęciowej pisałem nie raz, chyba pierwszy raz w krótkim artykule Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych. Niestety nadal problemem większości  dokumentów, takich jak analizy i specyfikacje, jest ich niespójność i niejednoznaczność.

W niedawnym artykule SBVR czyli reguły biznesowe i słownik pisałem o diagramie faktów, o regułach i o słowniku pojęć, dzisiaj co nieco o pojęciach (tych ze słownika pojęć ;)).

Ostatnia wersja specyfikacji SBVR v.1.3. z maja tego roku, zawiera rozszerzony rozdział:  8 Linguistic Foundations, 8.1 Things, Meanings, and Expressions, 8.1.1 Semiotic/Semantic Triangle in SBVR Terms rozpoczynający się tak:

This sub clause introduces the concepts that comprise one leg, ?meaning corresponds to thing?, of the Semiotic/Semantic Triangle which was first introduced by Charles Sanders Peirce at the beginning of the twentieth century and later by (Ogden and Richards 1923). See ?Ontology, Metadata, and Semiotics? [Sowa].

Semiotic/Semantic Triangle in SBVR Terms

The Semiotic/Semantic Triangle is the theoretic basis for SBVR?s linguistics-based architecture in general and for the fundamental separation of representation (expression) from meanings in SBVR?s architecture. Being a linguisitic-based standard the instances of concepts are the things in the universe of discourse, i.e., the world of the organization that uses the SBVR Business Vocabulary, and not concepts in the SBVR model. (Źródło: SBVR)

Generalnie semantyka, semiotyka i pragmatyka to trzy kluczowe elementy lingwistyki: pojęcie (termin) mające swoja definicję (semantyka), dalej byty znaczone przez te pojęcia (pojęcie znaczy-denotuje “to coś”) to semiotyka, oraz wyrażenia zawierającego to pojęcie, które nadaje mu kontekst (pragmatyka). Nauka o tym jak rozumiemy znaki, semiotyka  (słowa są także znakami), mówi że znaczenie terminu wskazuje na zbiór rzeczywistych elementów (bytów), słowo [kot] definiowane jest jak pewien typ ssaka, denotuje wszystkie zwierzęta rozpoznawane przez nas jako koty. Denotacja wynika jednak z kontekstu, czyli tego w jakim “otoczeniu znaczeniowym” słowo (znak) został użyty. Np. kształt “trójkąt” w zeszycie do geometrii oznacza abstrakcyjną  figurę geometryczną, ten sam znak na drzwiach w długim korytarzy oznacza (spodziewamy się tego) męską toaletę. Dlatego stosuje się (buduje się) wyrażenia (expression) tworzące kontekst (do terminów dodaje się fakty z nimi powiązane, co wskazuje na konkretne znaczenie), zawierające dany (definiowany) termin (słowo), dla doprecyzowania znaczenia tego terminu (trójkąt umieszczany w zeszycie do geometrii, lub trójkąt umieszczany na drzwiach toalety, wyrażenie (w SBVR “wording”) “umieszczany w…” to fakt nadający pojęciu “trójkąt” kontekst).

Takimi kontekstami są tak zwane diagramy faktów. Są to diagramy, na których pojęcia zawarte w słowniku pojęć, są przedstawiane wraz z opisem, faktami, doprecyzowującymi ich znaczenie poprzez użycie w określonym kontekście. Ten kontekst, opisanie go, w toku analizy, ma jeszcze dodatkowe znaczenie: pozwala skupić się wyłącznie na tym jednym kontekście, a jest nim kontekst TEGO projektu.  Z zupełnie innej strony spotykamy się z tym samym problemem przy okazji modelowania “dziedziny systemu” (lub komponentu) przy okazji projektowania komponentów, tak zwanych mikroserwisów, czy metodyki i wzorca Domain Driven Design. Pojęcie “bounded context” to nic innego jak konieczność ograniczenia analizowanego problemu do jednego kontekstu, właśnie dla zachowania spójności i jednoznaczności modelu systemu oraz jego “odpowiedzialności”, stanowiącego wymaganie np. wobec oprogramowania. Model to nic innego jak opis mechanizmu działania serca każdego systemu (core domain).

Tworząc oprogramowanie świadomie dzielimy je na komponenty bo zbyt duży (szeroki) zakres funkcjonalny prowadzi do tego, że nie możliwe jest uniknięcie niejednoznaczności. Jeden poprawnie zaprojektowany komponent obsługuje wyłącznie “jeden kontekst”, gwarantuje to spójność pojęć i spójność “modelu domeny”. Widać ten problem w zbyt dużych systemach ERP:

jeżeli chcemy obsłużyć np. takie pojęcie jak “maszyna”, to zupełnie inne ma to pojęcie znaczenie na liście środków trwałych (pozycja kosztowa, jedna z wielu, z jej cechami księgowymi) a inne na liście wyposażenia hali produkcyjnej (maszyna mająca cechy konstrukcyjne i określona przydatność), oba te byty “zachowują się” inaczej w obu tych kontekstach, każdy jest powiązany z innymi faktami w organizacji (kupiony określonym kosztem, tu nie różni się od kupionych usług, oraz jest smarowany by nie uległ awarii, tu  jest to ewidentnie złożony podzespół). Tu pojawia się problem normalizacji dużych baz danych relacyjnych: próba jednokrotnego użycia każdego pojęcia (normalizacja) w wielo-kontekstowym systemie,  kłóci się z wieloma kontekstami jakimi są poszczególne moduły tematyczne aplikacji. To dlatego jeden znormalizowany model danych dla dużego zintegrowanego systemu nigdy nie będzie poprawny, zawsze będzie szkodliwym kompromisem. Systemy składające się z całkowicie odseparowanych komponentów (nie współdzielą żadnych danych we wspólnej bazie danych!) są znacznie lepsze w użyciu.

(więcej w artykule Granice kontekstu i mikroserwisy)

Jakość biznesowego słownika terminów wyznacza wręcz jakość całej analizy, a potem projektu. Wszelkie niejednoznaczności pojęciowe prowadzą do niejednoznaczności logiki tekstu (opisu), na podstawie takiego tekstu nie da się stworzyć poprawnie działającego mechanizmu działania (np. kodu programu). Pierwszym miejscem, w którym widać te problemy są umowy i słowniki pojęć na ich początku. Poprawnie zbudowany słownik to czysta logika: definicje pojęć w słowniku powinny się wzajemnie wykluczać  (zasada wyłączonego środka w logice) zaś w ramach jednego słownika (poziomu definiowanych pojęć) definicje pojęć nie mogą zawierać pojęć definiowanych.

…analiza danej dziedziny to opracowanie jej modelu z pomocą konkretnego systemu pojęciowego. Czy to łatwe? Niestety nie. Sito jest łatwe w użyciu bo jedynym kryterium kwalifikacji jest rozmiar i można to robić mechanicznie. Analiza treści wyrażonej językiem naturalnym w postaci mowy lub pisma jest znacznie trudniejsza. (Źródło: Trzy zasady, nazywane czasem najwyższymi prawami myślenia czyli czym jest poprawna analiza | Jarosław Żeliński IT-Consulting)

Tak więc podejmując się analizy, warto robić to “dobrze”, można to nazwać metodą naukową i nie będzie w tym przesady. Reguły biznesowe, rygory ich tworzenia, słownik pojęć, model pojęciowy, to wszystko służy poprawie jakości wyników analizy, dokumentacji, późniejszego projektu. Specyfikacja SBVR bardzo w tym pomaga. (o formalizacji modeli)

Jeżeli mieliście kiedyś problem z projektem, to jest bardzo prawdopodobne, że jedną z kluczowych tego przyczyn był zły (lub jego brak) model  pojęciowy.

Analitycy! Studiujcie logikę 😉