Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Mam w ręku książkę Guide to Enterprise IT Architecture (Springer Professional Computing, autorzy Col Perks, Tony Beveridge). Co prawda wydana w 2003 roku jednak, autorzy skupili się na pryncypiach dzięki czemu uzyskali pewna "ponadczasowość". Co prawda autorzy powołują się dość często na TOGAF, ale książka jest nie o TOGAF'ie (jest tu traktowany jako przykład ram) a o tym czym jest (jak postrzegać) architekturę korporacyjną, zwracają uwagę, że chodzi o cel a nie o dokumentację. Nie jest to absolutnie żaden podręcznik, jest to książka ukierunkowana na pokazanie czym jest architektura korporacyjna, jakie…
obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy "świata" i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie - obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).
Tak więc proponuję praktykom uważającym, że strategia jest już zbędna, podziękować. Podobnie proponuję podziękować także konsultantom, którzy uważają, że strategia to szczegółowy plan na wiele lat. Nie ma sensu re-definiowanie tych pojęć na chwilowe potrzeby "mody" czy nawet demagogicznego uzasadniania sensu jakiegoś projektu. To i tak na nie zadziała w dalszym horyzoncie działań. Strategia to deklaracja na długi okres, w konsekwencji nie ma sensu by była "szczegółowa", ona ma być ogólna ale musi być "konkretna", musi pozwalać na stwierdzenie w dowolnym momencie, czy to co robimy lub planujemy zrobić (taktyka i podejmowane zadania) jest zgodne z naszą strategią czy nie. W przeciwnym wypadku mamy problem albo ze strategią, albo z planowanymi działaniami, albo z jednym i drugim :) czyli z zarządzaniem w ogóle.
W literaturze można spotkać różne "definicje" studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Wydaje się, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy. Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej, wydaje się być najwłaściwszą.
Poszukiwanie Świętego Graala realizacji celów osobistych albo projektów trwa. Od czasu do czasu pojawiają się "magiczne" metody na sukces. Jedna z regularnie odgrzewanych jest SMART i jej odmiany. Poniżej kolejna próba ożywienia tego tematu i mój komentarz. Model ZOOM mówi o tym, że każdy cel, który sobie wyznaczasz musi być: (Wyznaczaj cele w modelu ZOOM). Moim zdaniem, nie ma znaczenia jaki wymyślimy "fajny" akronim SMART, ZOOM itp...każdy cel w swoim opisie ma trzy kluczowe parametry: to co chcemy osiągnąć, stworzyć itp., to kiedy planujemy to osiągnąć, to jak stwierdzimy, że…
Oprogramowanie workflow, w tak zwanej chmurze, ma wiele zalet, jednak ma także poważną wadę: kłopotliwa integracja z lokalnymi systemami (np. ERP) wynikająca z tego, że dokumenty pokonują zawsze podwójną drogę od naszej lokalizacji do usługodawcy i z powrotem. W przypadku małych firm (mała ilość danych) z reguły nie stanowi to problemu. Dla dużych firm może to być nawet bariera nie do pokonania, dlatego tak zwana "chmura prywatna" czyli lokalna instalacja może być jedynym wyjściem.
Na koniec: zanim zawrzecie Państwo umowę na taką usługę warto się skonsultować z prawnikiem wyspecjalizowanym w tego typu usługach.
Tak więc bezpieczeństwo powinno być raczej elementem wymagań w postaci "oczekiwany efekt" a nie "jak je zapewnić". Nie rozumiem dlaczego tak wielu analityków i działy IT wzbraniają się przed uznaniem, że oprogramowanie powinno być dostępne na dowolnym urządzeniu mobilnym i że nie powinno pozwalać na..., i tu określone ograniczenia. Moim zdaniem bezpieczeństwo powinno być definiowane (wymagania) poprzez ryzyka, których chcemy uniknąć w określonym, biznesowo oczekiwanym (a nawet zastanym) środowisku, a nie poprzez narzucanie konkretnego sposobu i technologii, w szczególności przymusu korzystania z konkretnego sprzętu czy oprogramowania.
Propozycja powyższa (polecam pełny tekst) to próba ograniczenia roszczeń OZZ oraz ograniczenie typów urządzeń objętych tym parapodatkiem. Mam nadzieję, że kropla drąży kamień, i praktyki OZZ o innych "pasożytów" zostaną jeszcze bardziej ograniczone. Dlaczego? Bo miedzy innymi, co jest nie tylko nielogiczne ale jest zwykłym pasożytnictwem, obecne prawo skutkuje tym, że OZZ dostają pieniądze za to, że między innymi moje opracowania (do których nic nie mają owe OZZ), są przeze mnie i moich klientów kopiowane na papier i nośniki CD. Jakim prawem jakakolwiek OZZ pobiera pieniądze za moje dzieła?
Od dłuższego czasu nurtuje mnie czym kierują się ludzie zawierający umowy na zakup pełnych i zintegrowanych pakietów ERP mimo, że statystyki pokazują, że to z reguły nie ma żadnego sensu. Praktycznie wszystkie te wdrożenia są po zakończeniu znacznie droższe niż pierwotne oferty, trwają dłużej niż obiecano, nie mała część kończy się fiaskiem i nawet kompletną rezygnacją i odinstalowaniem (bywam w tych firmach i widzę od środka różnicę pomiędzy tym co piszą w gazetach dostawcy w swoich referencjach a tym co faktycznie miało miejsce).
"przyganiał kocioł garnkowi": w firmach "prywatnych" dokumenty giną znacznie częściej. Mało która firma, nie będące urzędem, ma dobrze zorganizowany system obiegu dokumentów. Owszem, dokumenty księgowe, a konkretnie: dowody księgowe, są z reguły dobrze zarządzane ale to efekt wymagań prawa w tym obszarze. Dobrze jest nie raz także z Umowami, ale tu także mamy wymogi prawne (Umowa jako dokument jest tak samo ważnym dowodem jak np. faktura). Pozostałe dokumenty (oferty, zapytania, pisma do klientów itp.) to w większości firm "towar uboczny".
... zanim ktoś na prawdę zacznie krytykować prawo autorskie, nie zastanowi się zanim zacznie uogólniać. To prawo chroni dzieła Mickiewicza (autorskie prawa osobiste) jak i prace naukowców, architektów, projektantów i wielu innych profesjonalistów. Chroni dorobek żyjących artystów. Owszem, ten rynek żywi wielu pasożytów, ale "atakujmy" pasożytów a nie wylewajmy dziecka z kąpielą, zrównując wielkie dzieła kultury nieżyjących autorów, z tak chętnie kradzionymi utworami muzycznymi współczesnych muzyków popkultury czy dziełami twórców gier komputerowych.
Jednym z największych błędów popełnianych w projektach związanych z modelowaniem procesów biznesowych jest zapominanie o tym, że model procesu to model organizacji a nie tylko dokument, i o tym, że pomiędzy procesami a procedurami, umiejętnościami, instrukcjami obsługi narzędzi, jest granica. To się nazywa utrata panowania nad złożonością projektu. Kolejny problem to powszechne traktowanie notacji (np. BPMN) jako biblioteki symboli, co jest kluczowym błędem: notacja to model pojęciowy - podstawowe narzędzie analizy i modelowania.
