“Jeśli myślisz, że dobra architektura jest droga, spróbuj złej”

Wstęp

W roku 2008 pisałem (Forbs):

W wie­lu fir­mach decy­zja o wdro­że­niu sys­te­mu infor­ma­tycz­ne­go bar­dzo czę­sto nie jest poprze­dzo­na żad­ny­mi przy­go­to­wa­nia­mi w rodza­ju oce­ny struk­tu­ry orga­ni­za­cji, jej zdol­no­ści do zmian czy też upo­rząd­ko­wa­niem obie­gu infor­ma­cji. Częstym grze­chem jest pró­ba ?wtło­cze­nia? w sys­tem infor­ma­tycz­ny ?sta­re­go? porząd­ku. Drugi grzech to brak opi­sa­ne­go sys­te­mu infor­ma­cyj­ne­go. W efek­cie nastę­pu­je zde­rze­nie rygo­rów papie­ro­we­go obie­gu infor­ma­cji z obie­giem danych w sys­te­mie infor­ma­tycz­nym. Rezygnacja z wie­lu czyn­no­ści (np. sta­wia­nie pie­czą­tek i pod­pi­sów) lub zamia­ny ich na inne sta­je się klu­czo­wym, bro­nio­nym jak nie­pod­le­gło­ści przez wie­lu kie­row­ni­ków obsza­rem. Dzieje się tak w sytu­acji gdy postrze­ga­ją oni swo­ją wła­dzę i kie­row­ni­czą rolę wła­śnie w tych gadże­tach jaki­mi są pie­cząt­ki. Dlaczego tak się dzieje?

System informacyjny to nie informatyka, kto o tym zapomina – przegrywa – FORBES w Marcu 2008 roku, numer 3/2008 na stronie 117

Oprogramowanie wspomagające zarządzanie firmą stanowi sobą podsystem w systemie jakim jest organizacja, o czym pisałem niedawno:

Z per­spek­ty­wy orga­ni­za­cji i ryn­ku, opro­gra­mo­wa­nie wbu­do­wa­ne to jest to opro­gra­mo­wa­nie, któ­re­go uży­wa się wewnątrz fir­my ale któ­re­go nie widzą, nie mają z nim kon­tak­tu, klien­ci tej firmy.

(https://it-consulting.pl/2023/02/27/organizacja-jako-mechanizm-czyli-slon-w-pokoju/)

Organizacje to system informacyjny i system informatyczny jako jego podsystem. Mamy więc dwie odrębne architektury z perspektywy oprogramowania:

1. architektura informacji, czyli realizacja wymagań funkcjonalnych (komu, do czego i jakie informacje są potrzebne),
2. architektura techniczna środowiska, czyli gdzie są przetwarzane dane, oraz wymagania pozafunkcjonalne (jak sprawny, niezawodny i bezpieczny ma być ten system).

Są to skrajnie odrębne obszary inżynierii, a mimo to stale widzę w projektach tylko jednego “architekta”, z reguły jest to drugi, pierwszego nie ma (patrz także: SYSTEM INFORMACYJNY A SYSTEM INFORMATYCZNY). Niestety typowa porażka projektów IT to “system pracuje szybko i niezawodnie ale w zasadzie nadal do niczego nam nie służy”.

Ten tekst to próba wskazania kolejnej przyczyny niskiej skuteczności projektów w obszarze inżynierii oprogramowania. Hipotezą jest teza mówiąca, że: przyczyną (jedną z) jest bezpośrednie angażowanie kompetencji technologicznych do rozwiązywania problemów nie-technologicznych, jakimi są przepływ i przetwarzanie informacji w organizacji, mylnie utożsamiane z przetwarzaniem danych.

Troszkę teorii

Fundamentem tego tekstu jest tak zwany Trójkąt Ullmana opisujący związek między rzeczą, pojęciem (nazwą) reprezentującą tę rzecz, oraz definicją tego pojęcia .

Kluczem jest tu rozróżnienie pojęć: dane, informacja, przedmiot . Istotą problemu jest człowiek i jego myśl: trójkąt Ullmana opisuje te trzy pojęcia i związki między nimi.

Powyżej (po lewej) oryginalny Trójkąt Ullmana oraz (po prawej) ilustracja pokazująca miejsce człowieka w tym trójkącie. Trójkąt ten opisuje mechanizm komunikacji między ludźmi, czyli to czym jest, i jak jest, przekazywana informacja. Pokazano to poniżej:

1. człowiek zobaczył rzecz (pomarańcza), “wie” co zobaczył (potrafi to wyrazić w języku jakim włada),
2. zapisał (opisał) to co zobaczył czyli utrwalił opis,
3. inny człowiek (lub on sam po jakimś czasie) odczytał zapis.

Komunikacja polega na przekazywaniu informacji między ludźmi: między nadawcą a odbiorcą. Język (słowa wypowiadane lub pismo jako ich reprezentacja) umożliwia ten przekaz. Komunikatem może by jedno słowo (pojęcie) tak jak na powyższym schemacie. Jednak jako ludzie stosujemy bardziej wyrafinowana formę komunikawania o czymś: są to zdania, np.:

Widziałem pomarańczę.

Jest to komunikat, mówiący o tym, że nadawca widział pomarańcze. Jako ludzie władający określonym językiem, rozumiemy co znaczy słowo ‘pomarańcza’ i słowo ‘widziałem’. W powyższym zdaniu słowo ‘pomarańcza’ jest pojęciem wskazującym na przedmiot (lub kolor pomarańczowy), zaś słowo ‘widziałem’ oznacza ‘zobaczono’ (albo ‘została zobaczona’). Słowo ‘zobaczono’ jest predykatem czyli związkiem zdaniotwórczym. Predykat jest wymagany do zrozumienia o jaki fakt chodzi, bo samo wypowiedziane słowo ‘pomarańcza’ nie niesie informacji. Ale zdanie “Widziałem pomarańczę” informuje nas o tym do czego doszło.

Zdania (komunikaty) można wyrazić w postaci utrwalonej czyli w postaci dokumentu. Dokumentem jest zdanie “Widziałem pomarańczę”, możliwe do utrwalenia na jakimkolwiek nośniku (także elektronicznym), czyli możliwe do zapisania, a do tego są niezbędne znaki czyli np. pismo lub ikony. Więcej o zdaniach i ontologii w artykule: Ontologia – zastosowanie w inżynierii oprogramowania.

Maszyna nie rozumie zdań, które rozumie człowiek, ale maszyna może przetwarzać dane (znaki). Dlatego dla potrzeb przetwarzania danych (a nie informacji, bo to potrafi tylko rozumny człowiek) stosujemy inna formę: formularze. Zdanie “Widziałem pomarańczę” można zapisać tak:

Zdanie “Widziałem pomarańczę” można rozwinąć: “Ja, Jarek Żeliński, 1 kwietnia 2023 roku, w sklepie ABC, widziałem pomarańczę”. Można to zapisać w postaci możliwej do przetwarzania maszynowego:

Jeżeli potrafimy opisać reguły przetwarzania danych, czyli mechanizm wytworzenia nowych treści na podstawie już istniejących, to znaczy, że potrafimy na podstawie zadania o tym co zamówiono wygenerować zdanie o tym co sprzedano. Albo: na podstawie Zamówienia potrafimy wygenerować Fakturę.

Dlatego ma sens by w kodzie aplikacji pojawiła się klasa Faktura, ale nie ma sensu by w tym kodzie pojawiła się klasa Sprzedawca.

Architektura systemu

Każdy system to jego architektura i reakcje na bodźce. Architektura to skutek wielu lat doświadczeń w postaci dobrych praktyk i wzorców projektowych. Zaprojektowanie wysokiej jakości architektury nie jest problemem dla osoby znającej i rozumiejącej te wzorce. Powiązanie wymagań, usług aplikacji i jej architektury zbudowanej na wzorcach można ogólnie przedstawić jak poniżej:

Pozostaje rzecz najtrudniejsza: zrozumieć czym są informacje i zorganizować dane oraz ich przetwarzanie oraz zdekomponować problem (patrz referat: Can Great Programmers Be Taught? – John Ousterhout). W dalszej części omówiono informacje i przetwarzanie danych. Kwestię dekompozycji i projektowania przetwarzania danych opisałem niedawno w artykule o procesie ICONIX.

System informacyjny vs. informatyczny

Przypomnijmy definicję: pojęcie system, który jest najczęściej definiowane jako:

zespół wzajemnie sprzężonych elementów, spełniający określoną funkcję i traktowany jako wyodrębniony z otoczenia w określonym celu

Tym razem chcę zwrócić uwagę na to, że systemowe metody analizy i optymalizacji organizacji nie różnią sie od metod analizy i projektowania systemów informacyjnych i informatycznych. Jednak jest istotna dziedzinowa różnica między systemem informacyjnym a informatycznym :

• system informacyjny to system, którego elementami są informacja i człowiek,
• system informatyczny to system, którego elementami są dane oraz urządzenia wykorzystane do ich przesyłania, prezentacji i przetwarzania.

Jeżeli określony element systemu potraktujemy jako jego podrzędny system (pod-system), pojawia się pojęcie: system systemów. Innymi słowy system może mieć podsystemy, może też więc być elementem systemu nadrzędnego (system nadrzędny jest tu otoczeniem bazowego systemu) . W języku angielskim jest to ‘information systems’ vs ‘information technology’ .

Model systemu

Model systemu jest często obrazowany jak poniżej:

Na schemacie tym:

• ‘Requirements’ to oczekiwane zewnętrzne cechy systemu gdy jest to projekt systemu, lub wyjaśniane zachowania gdy jest to analiza systemu istniejącego (badanego),
• ‘Structure’ to architektura elementów systemu,
• ‘Behavior’ to wzajemne oddziaływania elementów systemu i scenariusze reakcji systemu na bodźce z zewnątrz (z otoczenia),
• wszystkie trzy są ze sobą powiązane pojęciowo.

Jeżeli zgodzimy się z tezą, że ‘system informatyczny’ przetwarza informacje a nie odwrotnie, to znaczy że ‘system informacyjny’ jest nadrzędny dla tego systemu. Innymi słowy, ‘system informatyczny’ jest co do zasady podsystemem ‘systemu informacyjnego’.

Organizacja jako system

Informacje to domena ludzi, którzy intepretują dane, te zaś są utrwalane i przenoszone jako dokumenty. Dokument to określona i nazwana treść mająca określona strukturę . Dokument z perspektywy systemu informacyjnego, to komunikat z perspektywy systemu informatycznego .

Modele procesów biznesowych budujemy na bazie tezy i definicji mówiącej, że proces to aktywność zwieńczona jej produktem. Z perspektywy modeli analitycznych w notacji BPMN, wyjścia aktywności to dokumenty (DataObject) .

Komputery i oprogramowanie to technika i technologia, które modelujemy z użyciem notacji UML . Tu operujemy pojęciami komponentów i danych, które te komponenty przetwarzają, przesyłają i prezentują ludziom.

Oba te obszary łączą się: ‘system informacyjny’ jest wspierany ‘systemem informatycznym’ (drugi jest elementem pierwszego). Jak? Poniżej jeden w wielu przykładów definiowania tak zwanej Architektury zorientowanej na usługi (ang. SOA, Service-oriented Architecture):

Najwyżej jest warstwa procesów biznesowych (Business Processes). Tu operujemy pojęciami: aktywność, dokument, rola/osoba. Jest to poziom systemu informacyjnego. Jeżeli chcemy zdefiniować wymagania na system informatyczny (lub opisać istniejący), tworzymy listę punktów, w których ‘system informatyczny’ wspiera ‘system informacyjny’.

Mówimy, że ‘system informatyczny’ świadczy usługi ‘systemowi informacyjnemu’. Business Services to abstrakcyjna warstwa specyfikowania tych usług (zależnie od kontekstu: istniejących lub wymaganych).

‘System informatyczny’ to łącznie komponenty aplikacyjne (Components) oraz infrastruktura w jakiej one funkcjonują (Operational Resources). Jest to warstwa infrastruktury technicznej.

Mechanizm czyli logika działania systemu

Generalnie pojęcie mechanizm to wyjaśnienie powstawania obserwowanych faktów. Opis mechanizmu można wyrazić wzorami matematycznymi, schematami blokowymi, algorytmami, procedurami, określonymi zasadami, zwanymi tu regułami biznesowymi .

Mechanizm ten to dane uporządkowane w struktury jakimi są dokumenty oraz zasady przepływu tych dokumentów i przekształcania jednych w drugie. Przepływ pracy oraz tworzenie i przepływ dokumentów modelujemy jako jak procesy biznesowe (BPMN). Struktury tych dokumentów modelujemy jako agregaty (UML, XML). Reguły biznesowe to zasady określające te przepływy oraz poprawność treści dokumentów. Wykonawcami są ludzie wspieranie narzędziami (oprogramowanie czyli system informatyczny).

Z powyższego wywodu nasuwają sie wnioski:

1. ‘system informacyjny’ i ‘system informatyczny’ to dwa odrębne obszary dziedzinowe,
2. ich analizy i projektowanie to także dwie odrębne dziedziny,
3. skoro ‘system informatyczny’ to część nadrzędnego systemu jakim jest ‘system informacyjny’ to wszelkie działania dotyczące ‘systemu informatycznego’ powinny być poprzedzone analizą ‘systemy informacyjnego’,
4. skoro ‘system informacyjny’ to także mechanizm jego działania, to dostawca (wykonawca) ‘systemu informatycznego’ powinien wykonać implementacje tego mechanizmu (po jego udokumentowaniu) a nie projektować go, bo ‘system informacyjny’ istnieje, należy go przeanalizować, zrozumieć i opisać.

Analiza i projektowanie systemów informacyjnych to element analizy systemowej organizacji. Wynikiem tej analizy jest logika tworzenia i przetwarzania informacji w organizacji, te informacje są zapisywane i przetwarzane w systemach informatycznych jako dane. Dlatego najpierw należy wykonać analizę systemu informacyjnego organizacji, jej produktem powinien być opis (model) mechanizmu przetwarzania informacji w organizacji. Dopiero drugim krokiem może wybór i wdrożenie (zlecenie wykonania) oprogramowania, czyli zlecenie implementacje określonej części systemu informacyjnego. Praktyka pokazuje, że każda droga na skróty (pominięcie etapu analizy systemu informacyjnego) kończy się źle.

Opisany na początku sześcian to zarówno model całej organizacji, jak i model każdego jej podsystemu. Można sobie wyobrazić, że taki sześcian zawiera w sobie wiele mniejszych, każdy opisujący określony podsystem w organizacji.

Wymiana danych a wymiana informacji – współpraca organizacji

Na tym tle warto także podsumować kwestie współpracy organizacji czyli wymiany informacji i wymiany danych. Jeżeli uznamy, że organizacja to ludzie i wspierające ich narzędzia, to współpraca organizacja odbywa się w dwóch domenach: informacyjnej i informatycznej:

Z powyższego nasuwa się kluczowy wniosek:

projektowanie współpracy firm wymaga najpierw analizy i udokumentowania modelu informacyjnego: jakie i o czym informacje są wymieniane, a potem dopiero można projektować system informatyczny wspierający tę współpracę w postaci wymiany danych.

Jako ludzie rozumiemy to co czytamy i na podstawie tego podejmujemy decyzje. Jednak komputer “nie rozumie” danych, dlatego przeniesienie jakiejkolwiek części ‘przetwarzania informacji’ do ‘systemu informatycznego’ wymaga opisania jej w postaci struktur danych i reguł ich przetwarzania. Najefektywniejszą metodą jest sprowadzenie informacji do postaci skończonej liczby dokumentów oraz zbudowanie listy reguł opisujacych związki między nimi .

Architektura systemu jest łatwa do zaprojektowania jak ktoś zna i rozumie architektoniczne wzorce projektowe i dobre praktyki (ale te aktualne, a nie te z przed 40 lat, na bazie których powstały między innymi obecne monolity ERP).

Low-code i No-code

Powszechnie uważa się, że

No code jest fascynującym kierunkiem, który znacząco przyspiesza rozwój aplikacji i wprowadza rewolucyjne zmiany w branży IT. To niesamowite, jakie możliwości otwierają się dla osób biznesowych i programistów, umożliwiając im wspólne tworzenie aplikacji z mniejszym nakładem czasu i kodowania.

(wypowiedź na LinkedIn)

Zgadzam się w tym, jednak problemem nie jest kodowanie, problemem jest zrozumienie tego jakie informacje, o czym i dlaczego są (mają być) przetwarzane, jak je zapisać jako dane w systemie i jak przetwarzać. Narzędzia low-code i no-code znacząco przyśpieszają implementacją, ale nie zastępują analizy i projektowania.

Podsumowanie

Z powyższego nasuwają się także proste i oczywiste wnioski:

1. nie ma żadnego sensu projektowanie ‘systemu informatycznego’ bez pełnego zrozumienia (czyli także udokumentowania) ‘systemu informacyjnego’
2. nie ma żadnego sensu umieszczanie elementów ‘systemu informatycznego’ na modelach ‘systemu informacyjnego’ (np. symbole reprezentujące oprogramowanie na modelach BPMN)
3. związki między elementami ‘systemu informacyjnego’ i elementami ‘systemu informatycznego’ opisujemy z pomocą macierzy śladowania
4. opracowanie wymagań na ‘system informatyczny’ polega na zidentyfikowaniu ‘potrzeb biznesowych’ i opracowaniu na ich podstawie logiki działania i architektury ‘systemu informatycznego’ (MBSE, MDD), a nie na zbieraniu mitycznych “wymagań użytkowników”, którzy de facto nie mają pojęcia o “systemach informatycznych’, za to doskonale wiedzą czy i kiedy potrzebują pomocy w realizowanych procesach biznesowych
5. Poprawnie zaprojektowane oprogramowanie nie tyle “pozwala na przestrzeganie zasad”, co “nie pozwala na ich łamanie”, dlatego wysokiej jakości oprogramowanie jest projektowanie wg. zasad: privacy by design, law by design, rules by design.
6. Dlatego właśnie metody oparte na projektowaniu ‘systemu informatycznego’ na bazie wywiadów (warsztatów) z przyszłymi użytkownikami są z góry skazane na niepowodzenie (bo nawet jak coś sensownego w końcu powstanie, to odbędzie się to ogromnych nakładem pracy metodą prób i błędów)

Jedno wiemy od lat: jedną z najbardziej szkodliwych tez w IT jest ta, mówiąca, że dokument to raport z bazy danych. Po raz kolejny wyszło to z cała mocą w toku prac nad KSeF. Ciekawą i obszerną prace na podobny temat opublikował Danesi .

Dodatek: Wymagania na oprogramowanie

Czym są i jak określić wymagania na oprogramowanie? Popatrzmy na schemat:

Pracownicy organizacji, mając określone umiejętności i uprawnienia, przetwarzają informacje, które są utrwalane w ‘systemie informatycznym’. Jak już wiemy, przetwarza on dane. Wobec tego wymaganiem na ten system jest opis: danych, reguł przetwarzania oraz jego wewnętrzna architektura. Może to być monolit jak większość oprogramowania ERP na rynku, a może to być system zbudowany z niezależnych komponentów, tak by było możliwe jego częściowe wdrażanie i modyfikowanie. Dlatego opracowanie wymagań wymaga:

1. analizy i modelu ‘systemu informacyjnego’ w postaci modeli procesów biznesowych (kto i co robi oraz kiedy), jest to model CIM ‘systemu informacyjnego’.
2. analiza potrzeb (komu i jakie usługi będzie świadczył ‘system informatyczny’), jest to model przypadków użycia ‘systemu informatycznego’,
3. modelu architektury ‘systemu informatycznego’ w dziedzinie przetwarzania danych, jest to model PIM ‘systemu informatycznego’.

Oznacza to także, że do wykonania analizy ‘systemu informacyjnego’ i zaprojektowania ‘systemu informatycznego’, nie potrzebujemy niczego poza dostępem do tych informacji i danych, a to znaczy, że analityk-projektant jest w stanie dokonać tego w 100% zdalnie. Wystarczy, że będzie umiejętnie i metodycznie żądał materiałów źródłowych.

Źrodła