Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem?

Ten artykuł polecam “biznesowi” który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo “takie są fakty”.

Wpadłem jakiś czas temu na stronę SemanticCore.ORG, oto krótki cytat z pierwszej strony :

The semantic core represents a vision of complex systems that are defined and provisioned based on high-level models. This vision is being pursued by multiple groups in multiple organizations based on a variety of paradigms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the semantic core to integrate these diverse paradigms into family of languages that leverages their commonality while taking advantage of their unique capabilities. We will define normalized Meta-Models capturing unique semantics, independent of the notation. […] It is our intent to create a combined submission appropriate for multiple OMG initiatives including Ontologies, Business Rules, Business Process Modeling and a UML infrastructure library.[…] the semantic core will define models for a family of ontologically grounded models defining all aspects of systems, including their requirements, environment, specification and implementation. This will enable a transition from traditional and manual systems building techniques to an automated and human-focused paradigm. (źr. Semantic Core).

Powyżej (moje wytłuszczenia) główne cele tej organizacji (polecam zapoznanie się z całą stroną)

• nasza wizja to złożone systemy opisywane i przedstawiane w postaci modeli na wysokim poziomie abstrakcji,
• w tym celu definiujemy znormalizowany metamodel opisany systemem znaczeń (semantyka) niezależnym od notacji,
• tworzymy to w zgodzie z inicjatywami OMG (www.omg.org),
• “semantic core”  określa standardowy zestaw kluczowych pojęć i ich znaczeń, opisujących wszystkie aspekty systemów, w tym ich wymagania, otoczenie, specyfikacji i implementacje.

Wygląda jak bajka ale nie jest tak źle, a coś takiego jest bardzo przydatne. Nie ma sensu budowanie jednej mega-notacji do wszystkiego, widać to po pracach OMG (i po tym, że UML jednak nie zastąpił innych notacji, i nikt rozsądny chyba już tego nie planuje). Jednak uznając fakt, że używamy (dobra praktyka) notacji właściwych dla rozwiązywanego problemu (zaryzykuję tezę: właściwa to możliwie najprostsza i wystarczająca) warto jednak zadbać o ich “kompatybilność”. Część wspólna to nie nowa notacja, a utrzymanie spójności znaczeń współdzielonych pojęć istniejących już notacji.

O złożoności

Na co warto zwrócić uwagę? Otóż w procesie każdej większej analizy pojawia się złożoność, nad którą należy zapanować. Bez tego opanowania pojawia się coś co zabija projekty analityczne: utrata panowania nad złożonością problemu, pojawiają się mega-diagramy i mega  formularze danych.

Kilka tygodni temu, w jednym z moich projektów, miałem okazję wejść w mały spór na temat tego, kiedy udokumentować szczegółowo sposób klasyfikacji (oznaczania) pozycji budżetowych w systemie zarządzania procesem tworzenia budżetu i jego realizacji. Zamawiający od razu wchodził (wręcz żądał) w szczegóły, czyli naście rodzajów każdego z ogromnej liczby typów wydatków. Jeszcze bym dobrze nie ruszył z miejsca a już został bym zgnieciony liczbą tych szczegółów.  Do tego dorzucano mi pełną szczegółowość struktury organizacyjnej  (także przekłada się na budżet jako miejsca wydawania środków).  Dodam, że struktura organizacyjna zmieniła się w ciągu roku trzy razy.

Co z tym zrobić? “Wyrzucić” te szczegóły na sam koniec! One są na początku zupełnie nieistotne (nie licząc zapoznania się nimi jako obecnie funkcjonującym systemem), każdy zaś kto twierdzi, że jednak są istotne już teraz, po prostu jeszcze nie zrozumiał analizowanego problemu.

Problemem są pryncypia czyli “co i po co” a nie “jak”. Owo “jak” to dopiero projektowanie.  Tak więc np. budżet, proces jego tworzenia a potem realizacji, to jakiś system “pozycji budżetowych” i zdarzeń związanych z jego realizacją. Jakaś logika tej całości (dalej jako reguły biznesowe i decyzyjne). To jak zostanie oznaczona (jakim symbolem itp.) to efekt tego co chcemy osiągnąć. Każdy kto chwyci się od razu za te szczegóły (jakieś one są, mamy je już więc dlaczego się za nie nie zabrać), zaczyna od końca i w zasadzie zarzucił analizę i odciął sobie (klientowi) możliwość zbudowania optymalnego (nowego) rozwiązania (zapewne innego niż obecne) na rzecz obecnego.

Należy na początku pracować na abstrakcji, uogólnieniu pozwalającym skupić się na kilkunastu pryncypiach zamiast na tysiącach szczegółów. To pierwsze jest relatywnie łatwe, to drugie w zasadzie niemożliwe.

Modele

Jak wspomniano powyżej, typów modeli (notacji) mamy więcej niż jeden. Każdy model (rodzaj modelu) ma swój dedykowany system pojęć, po ubraniu go w ikony mamy notację (język obrazkowy), czyli język opisany semantyką (znaczenia pojęć) i syntaktyką (ich wzajemne, dopuszczalne relacje). Zestaw pojęć powinien być dobrany stosowanie do rozwiązywanego problemu (wybór właściwej do etapu pracy notacji).

Jak wskazano wyżej, mamy cztery kluczowe systemy pojęciowe:

1. UML czyli obiektowy paradygmat opisu i projektowania,
2. Ontologia (biznesowa, systemowa), którą obecnie reprezentują Model Motywacji Biznesowej (w między czasie także dorobił się ikon), SBVR i systemy pojęciowe opisywania architektury korporacyjnej, struktury organizacji,
3. Procesy biznesowe,
4. Reguły biznesowe.

Wspólny środek ma już swoje “zarzewie”. W 2010 roku wydano ostatnią specyfikację Modelu Motywacji Biznesowej (ang. BMM). Można przyjąć, że ten system pojęciowy (teraz także notacja) to element biznesowej ontologii. Pojawił się w niej dodatek F zatytułowany Powiązane specyfikacje modelowania w OMG. I co my tu mamy?

Ano mamy stwierdzenie, że ta kompatybilność jest potrzebna. Napisano, że BMM współdzieli pewne pojęcia z takimi systemami pojęciowymi jak:

1. BPMN (w BMM pojawia się pojęcie proces biznesowy)
2. SBVR (BMM także operuje pojęciem Reguła Biznesowa)
3. OSM (Organization Structure Metamodel, BMM używa pojęcia “komórka organizacyjna”).

Co ciekawe pojęcia te mają w OMG wspólne definicje (te same pojęcia lub pojęcia dające się mapować 1:1). Utrzyma jest zgodność roli w procesie biznesowym i roli jako elementu struktury organizacyjnej w tych systemach (OSM, BPMN, BMM).

W specyfikacji BMM v.1.1 znajdziemy taki oto diagram:

 Notacje, które “wpadły” w ręce OMG maja właśnie tę bardzo pożądaną i przyjemną cechę: są kompatybilne. Wspominałem swego czasu o notacji ArchiMate (obecnie należy do The Open Group podobnie jak i TOGAF). Niestety nie ma tu tej kompatybilności, mimo że TOGAF nie jest samowystarczalnym modelem (wymaga stosowania innych notacji poza ArchiMate), w efekcie nie widzę możliwości “prostego” zastosowania ram TOGAF”a jako  bazowej architektury korporacyjnej, bo kolejne etapy uszczegóławiania modeli (a od tego nie ma ucieczki w projektach) albo będą miały kłopoty z jednoznacznością albo będą wymagały jakiegoś dedykowanego systemu tłumaczenia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostatniej wersji dubluje – nie wiem czy w 100% i po co – pojęcia modelu motywacji biznesowej.

Nie wymieniłem tu notacji UML bo ta służy do obiektowego modelowania (paradygmat obiektowy) systemów. Nie widzę sensu “wpychania” jej w dziedzinę ontologii zarządzania. Paradygmat obiektowy to inne spojrzenie, systemowe, opisujące “współdziałające obiekty”, jednak to wtórny model, bo te obiekty systemowe “reprezentują” komórki organizacyjne, strategie, reguły biznesowe, dokumenty itp. Modele obiektowe są doskonałe jako wstęp do projektowania oprogramowania implementowanego z pomocą obiektowo zorientowanych narzędzi.  Są kompletnie nieprzydatne jako biznesowy system pojęciowy. Owszem, nie raz tu wspominany DDD (sposób modelowania dziedziny systemu) to pewne takie połączenie, ale to raczej most niż ekwiwalent. Patrząc na ten problem z perspektywy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyższe modele (BMM, BPMN), UML ma zastosowanie dla części PIM (wstępny model implementacji w postaci oprogramowania) i tu jest dopiero miejsce na DDD.

Tak więc bat na szczegóły jest: to prosta zasada “od ogółu do szczegółu”, na każdym etapie mamy stosowną notację (prosty system pojęć). Należy uogólniać i modelować, i potem stopniowo uszczegóławiać modele aż do momentu dojścia do implementacji danego systemu.

Powyżej obraz z naniesionymi etapami [[MDA]] (więcej o Model Driven Architecture oraz Meta Object Facility – powyższy rysunek – na stronach OMG). Core Semantic to szczyt  (M3) powyższego. Wymienione wyżej notacje to warstwa M2 (UML dodatkowo obejmuje także M1).

Konkluzja jest taka: bazy danych zawierające szczegółowość systemu, projektujemy na końcu. Szczegóły elementów budżetu (przytaczany przykład) opracowujemy dopiero jako pomysł na implementację, mamy to jednak dwa poziomy implementacji:

1. rozwiązanie problemu efektywnego zarządzania budżetem w nowej formie np. system znakowania pozycji budżetowych,
2. implementacja tego systemu jako oprogramowania wspomagającego ten proces w organizacji.

To wszystko powinno być jednak poprzedzone analizą. Analiza obecnej sytuacji nie polega jednak na jej 100% odwzorowaniu w dokumentach analitycznych, a jedynie na poznaniu w celu zrozumienia celu biznesowego, opracowanie jego modelu, i potem dopiero rozwiązywanie problemu: jak to osiągnąć.

Na koniec pewna uwaga :). Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia “opinia prawna” oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).