I tu dochodzimy do sedna: aby stworzyć profil notacji - co czasami bywa niezbędne dla jakości analizy - należy zbudować słownik pojęć z dziedziny analizowanego problemu. Bez takiego słownika analiza może być niewykonywalna, albo jej jakość będzie bardzo niska - czytaj użycie jej wyników będzie bardzo ryzykowne.
Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. [...] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.
Od samego początku analizy i projektowania logiki systemu należy skupić się na tym "co i po co" a nie "jak". Zajmowanie się pytaniami "jak" (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości, nadmiarowych, szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy - mając szkielet całego projektu - wiemy które mają jakiekolwiek znaczenie.
Od czego należy zacząć? Od zbudowania własnej (lub własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności - Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją (podobnie jak lekarz domowy to raczej nikt z domowników).
W kontekście poziomów modelowania polecam książkę How Works Get Done , którą właśnie kończę czytać. Bardzo dobre kompendium wiedzy o modelowaniu procesów w kontekście tytułowego "jak ta praca jest wykonywana". Nie będę tu pisał streszczenia ;). Książkę gorąco polecam, jest napisana pragmatycznie przez praktyka, który jednak zaznacza, że skuteczne modelowanie, analiza, usprawnianie procesów i firm wymaga pełnego zrozumienia działania tych firm, zrozumienia wzajemnego wpływu ludzi, zasobów, mechanizmów, celów na produkty procesów, podkreśla także znaczenie i wskazuje korzyści z formalnego podejścia to analizy i modelowania (z naciskiem na słowo modelowanie a…
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości "map procesów", które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia. [...] jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
W dużym skrócie: nie warto dublować kompetencji bo to nomen omen powielanie ich kosztów. Jeżeli firma ma wdrożone procedury kontrolingowe, to naturalnym jest przekazanie danych (produktu) modelowania i optymalizacji procesów, zamiast wzajemne konkurowanie, tym bardziej, że dane z kontrolingu zawsze - jak sądzę - zostaną uznane za bardziej wiarygodne . Bardzo dobrym "narzędziem" łączącym kontroling, modelowanie procesów i zasoby (nie tylko IT) jest architektura korporacyjna, ale to materiał na kolejny artykuł ;).
... spotykam się jednak w literaturze z tezami, że wdrożenie jakichkolwiek norm, nie tylko jakości, powinno być także poprzedzone analizą. Innymi słowy normy jakości powinny być wdrażane jako odpowiedź (rozwiązanie) na określone wymagania, a nie dla samego faktu ich wdrażania. Owszem, bywa, że wymaganiem jest np. wymóg przetargowy (oferty mogą składać tylko firmy mające określony certyfikat), jednak moda na jakość, mimo że nie przeminęła całkowicie, powoli przechodzi w racjonalne powody wdrażania norm jakości.
Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.
Na ten wpis pewnie wielu z Was czeka, tak przynajmniej sugerują listy do mnie i głosy na forach, a także potencjalni klienci. Ci, których niestety czasem krytykuję, także pewnie czekają. Pokażę na prostym przykładzie, proces od analizy przez wymagania aż do projektu dedykowanego oprogramowania. Całość będzie zgodna z fazami CIM/PIM (www.omg.org/mda). Projekt dziedziny, który powstanie będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycje (zamiast dziedziczenia) (polecam artykuł Łukasza Barana) i DDD. Opis dotyczy każdego projektu związanego z oprogramowaniem, także gotowym np. ERP, CRM, EOD itp.
Korzystałem z opisu zasad gry w szachy zamieszczonego na WIKI:
Zasady gry w szachy ? prawidła regulujące sposób rozgrywania partii szachów. Choć pochodzenie gry nie zostało dokładnie wyjaśnione, to współczesne zasady ukształtowały się w średniowieczu. Ewoluowały one do początków XIX wieku, kiedy to osiągnęły właściwie swą bieżącą postać. W zależności od miejsca zasady gry różniły się od siebie, współcześnie za przepisy gry odpowiada Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się różnić w przypadku różnych wariantów gry, np. dla szachów szybkich, błyskawicznych czy korespondencyjnych. (Zasady gry w szachy ? Wikipedia, wolna encyklopedia).
To na co chcę zwrócić tu uwagę w szczególności, to metafora:
projektując (modelując) oprogramowanie dla człowieka, modelujemy narzędzie dla tego człowieka a nie jego samego.
Swego czasu pisałem, w artykule o nazywaniu klas, że oprogramowanie z reguły zastępuje dotychczasowe narzędzie człowieka a nie człowieka jako takiego. Druga ważna rzecz: aktor jest równoprawnym elementem systemu (tu systemem jest organizacja z jej ludźmi i używanymi przez nich narzędziami). No to zaczynamy.
(więcej…)
Wpadła mi niedawno w ręce książka: How to survive in the jungle of Enterpice Architecture Frameworks (autor Jaap Schekkerman, na Amazon.com dostępny fragment w tym spis treści).Dla mnie po lekturze tej książki nasuwa się jeden wniosek: moda na TOGAF to marketing The Open Group. Są inne, moim zdaniem ani gorsze ani lepsze, "ramy" architektoniczne (książka opisuje ich wiele). Podtytuł książki mówi wiele: Creating or choosing an Enterprise Architecture Framework (Tworzenie lub wybór ram architektury korporacyjnej). W zasadzie wystarczy wziąć przytaczaną powyżej definicję AE i podjąć powyższą decyzję: stworzyć lub wybrać. Nie jest to - tworzenie - łatwe, większość więc wybiera gotowe, jednak to jedynie ramy dlatego i tak nie da się tu niczego zastosować jak recepty.
Jak widać mamy do dyspozycji BMM, który "pasuje" do omawianego problemu. Uzupełniona systemami pojęciowymi "dziedzinowymi" czyli BPMN (procesy biznesowe powiązane z zasobami) oraz UML (struktury i systemy) mam kompletny i spójny pojęciowo (dba o to organizacja OMG) zestaw narzędzi stanowiący w moich oczach odpowiedź na tytułowe pytanie.I teraz moja konkluzja: bazując na "brzytwie Ockhama" podjąłem próbę sprawdzenia czy przypadkiem odpowiedź na tytułowe pytanie sformułowane przez Andrzeja, już nie istnieje... Odnoszę wrażenie, że właśnie prace OMG, ich wynik, są chyba odpowiedzią na to pytanie. Faktem jest, że nie wprost, ale chyba analizując te systemy pojęciowe, architekturę korporacyjna oraz BMM, można uznać, że tytułowe powiązanie istnieje. Opisałem to z nieco innej strony w artykule Architektura Korporacyjna z OMG.
