Kolejne projekty IT zaliczają kolejne wpadki i wśród przyczyn prawie zawsze pojawia się utrata panowania nad złożonością projektu. Jednym z kluczowych elementów analizy, także systemowej, jest redukowanie złożoności. Robi się to budując modele i metamodele analizowanej rzeczywistości, a na wstępnych etapach projektowania abstrahuje się od szczegółów. Jak? Operując właśnie modelami i metamodelami. Od dawna noszę się z zamiarem napisania czegoś o zarządzaniu złożonością i spójnością dokumentów. W końcu “nawinął” się dokument, na którym moim zdaniem warto “poćwiczyć”. Jest to ciekawy dokument zatytułowany:

Metareguły i zasady budowy cyfrowych usług publicznych

We wstępie poznajemy cel i (chyba) misję projektu:

?Obywatel jest angażowany w najmniejszym możliwym stopniu w proces świadczenia usług publicznych, zaś usługi rozumiane są jako proces zaspokajania potrzeb obywateli.? 

Często zamiast nowoczesnej usługi cyfrowej efektem prac jest ?zelektronizowana? procedura, która tym różni się od tradycyjnego sposobu załatwiania sprawy, że wniosek wypełniany jest przy pomocy komputera. Stosuje się różne standardy budowy usług cyfrowych, jak i ich rozwoju, co wpływa bezpośrednio na różnice w jakości, dostępności i użyteczności tych usług. Aby uniknąć takich negatywnych efektów, w wielu miejscach na świecie wdrożono wytyczne do budowy i utrzymania usług cyfrowych, gwarantujące ustandaryzowane podejście niezależnie od podmiotu wdrażającego usługę. Głównym beneficjentem takiego podejścia jest użytkownik końcowy.
Postawienie użytkownika?klienta administracji i jego potrzeb w centrum oznacza, że technologie informacyjne i komunikacyjne pomagają administracji w załatwieniu SPRAWY KLIENTA, a nie załatwieniu SPRAWY PRZEZ KLIENTA. Podejście to zakłada, że obywatel jest angażowany w najmniejszym możliwym stopniu w proces świadczenia usług publicznych, zaś usługi rozumiane są jako proces zaspokajania potrzeb obywateli. (Źródło: Metareguły i zasady budowy cyfrowych usług publicznych | Ministerstwo Cyfryzacji, plik  metareguly_i_zasady_budowy_uslug_cyfrowych_ready)

Postanowiłem na przykładzie tego opracowania pokazać na czym polega redukowanie szczegółów w analizie. Dokument ten jest trudny do oceny i zrozumienia w przypadku czytania go wprost,  z uwagi na to, że nie zawiera żadnych uogólnień, a mało który czytelnik  jest w stanie zbudować sobie w myśli taki “prosty” model całości. W tytule pojawia dość trudne nie tylko dla laika, pojęcie “metareguły”. Czym one są? Najpierw kilka słow na temat tego czym są pojęcia z przedrostkiem meta-.

Meta- czyli co…

Zacznijmy od znaczenia przedrostka “meta-” (sł. j. polskiego PWN):

meta- ?pierwszy człon wyrazów złożonych wskazujący na wyższy stopień, następstwo lub zmienność czegoś?

W ramach OMG funkcjonuje specyfikacja “Meta-Object Facility“. Zawiera ona między innymi takie o to wyjaśnienie:

7.3 How Many Meta Layers?
One of the sources of confusion in the OMG suite of standards is the perceived rigidness of a ?Four layered metamodel architecture? that is referred to in various OMG specifications. Note that key modeling concepts are Classifier and Instance or Class and Object, and the ability to navigate from an instance to its metaobject (its classifier). This fundamental concept can be used to handle any number of layers (sometimes referred to as metalevels).

Wytłuściłem kluczowe elementy tego opisu. Podstawowymi pojęciami są “klasyfikator i instancja” lub znane z UML “klasa i obiekt” oraz “możliwość nawigacji (śladowanie) od instancji do jej metaobiektu” (czyli klasyfikatora tej instancji). Na stronach WIKI jest dość popularny w sieci przykład w postaci czterowarstwowego modelu:

Tych warstw nie nie zawsze jest (musi być) tyle, ale tu chodzi o zasadę. Każda sąsiadująca z sobą para warstw to (licząc od dolnej) obiekt (instancja) i jego klasyfikator (metaobiekt). Para obiekt-klasyfikator łączona jest związkiem <<instanceOf>> wskazującym na klasyfikator (czytamy: obiekt jest instancją klasyfikatora). Powyższy przykład zawiera także związki <<snapshot>> i proste asocjacje (np. classifier), które zaciemniają jego główny sens. Zawiera także moim zdaniem błąd: zależność pomiędzy rzeczywistymi bytami a ich abstrakcjami to <<Abstraction>> a nie <<instanceOf>>.

Przygotowałem więc, mam nadzieję, mniej abstrakcyjny przykład :):

Jak czytać ten diagram? Realny świat to Byty rzeczywiste, np. bierki do gry w szachy. Abstrakcja bytów rzeczywistych to zobrazowanie ich w postaci nazwanych prostokątów: diagram z tymi prostokątami to model konkretnej rzeczywistości ze zdjęcia.  Każdy taki prostokąt to abstrakcja odpowiedniej bierki, czyli pozbycie się wszelkich szczegółów (materiał z jakiego są wykonane, kształt, itp.) nie potrzebnych do analizy np. reguł gry w szachy. Aby opisać w dokumentacji gry w szachy jej zasady, i uniknąć konieczności częstego używania nazw poszczególnych bierek, tam gdzie nie ma znaczenia to jak dana bierka może się poruszać po szachownicy, korzystamy z klasyfikatora: kolejnego uogólnienia jakim jest Bierka reprezentująca wszystkie dopuszczalne figury na szachownicy. Diagram z jednym prostokątem, klasyfikatorem, to metamodel.

Biorąc pod uwagę fakt, że bardziej złożone “rzeczywistości” mogły by wymagać bardzo dużej liczby obiektów (prostokątów) na modelu, z reguły stosuje się w dalszych etapach analiz metamodele a nie abstrakcje. Te służą raczej do tworzenia i testowania metamodeli. Tak więc jeżeli wśród obiektów na modelu można wyróżnić grupy o pewnych podobnych cechach, zastępuje się je jednym klasyfikatorem. Reprezentuje on wszystkie te obiekty. W tym przypadku jeden klasyfikator Bierka zastępuje na diagramie wszystkie “konkretne bierki”. Możemy też powiedzieć, że: obiekt Pion jest instancją klasy Bierka (podobnie Wieża itd.). Konkretne rzeczywista bierka np. Goniec, na konkretnej szachownicy konkretnego zestawu do gry w szachy, jest instancją obiektu Goniec z diagramu obiektów.

Tak więc model modelu to metamodel, czyli metametamodel rzeczywistości :). Czym więc będą metareguły? Niestety nie ma definicji w tym opracowaniu. Poszukajmy.

Metareguły charakteryzują stałość lub zmienność w czasie wcześniej odkrytych wzorców czy reguł (mogą to być reguły asocjacyjne, klasyfikujące, opisujące lub inne). (źr. Barbara Łopusiewicz (red.), Zarządzanie wiedzą w systemach informacyjnych. , Wydawnictwo Akademii Ekonomicznej, Wrocław 2004, ISBN: 83-7011-722-8 (34+16) (cytat, str. 216)).

Innymi słowy metareguły to reguły (tworzenia) reguł (tak jak metamodel to model modelu). Trochę dziwi mnie, że wprowadzono pojęcie “metareguły”. Pojęcie “polityki” było by moim zdaniem bliższe prawdy: “Polityka budowy cyfrowych usług publicznych”, ale to tylko dywagacje, nie chce tworzyć wątku “ja bym to zrobił inaczej” ;). Warto jednak podsumować, że meta reguła to wzorzec budowy reguł a nie “to czego one mają dotyczyć”… stąd moje zdziwienie użyciem pojęcia “metareguły” w kontekście dziedzinowym.

Ten wpis to jednak próba  wzięcia otwartego udziału w tych konsultacjach. Celem moim jest złożenie ewentualnych uwag, zastrzeżeń i ich uzasadnienie.

Metareguły i zasady budowy cyfrowych usług publicznych

Kilka kluczowych pojęć w dokumencie:

1 Wstęp

We wstępie czytamy:

? zerwanie z dotychczasowym paradygmatem ucyfrowienia (informatyzacji) usług świadczonych dotąd drogą tradycyjną; usługa nie może być utożsamiana z formularzem, podaniem czy dokumentem, nawet elektronicznym, z możliwością przesłania przez internet (zarządzenie informacją, a nie jej nośnikiem),

Informacja to określony, nazwany zestaw danych. Zarządzanie informacją jest możliwe pod warunkiem, że zostanie utrwalona a jej struktura określona (zdefiniowana). Struktura danych stanowiących informację w postaci utrwalonej to nic innego jak formularz. Ustawodawca już jasno określił czym jest treść, nośnik a czym dokument. Innymi słowy: samo wyrażenie chęci skorzystania z Usługi wymaga wyartykułowania tego żądania i przekazania w jakiejś utrwalonej formie. Nie da się zażądać od Państwa czegoś nie mają możliwości wyrażenia tego żądania. Tak wiec nie wiem z czym chce zrywać autor dokumentu, ale usługa: musi mieć nazwę, opis tego czym jest i musi istnieć sposób zlecenia Państwu jej wykonania na rzecz obywatela chcącego skorzystać z tej usługi.

? proces świadczenia usługi odbywa się na poziomach back-office i middle-office, poziom front-office to inicjowanie usługi i uzyskiwanie korzyści (załatwienie sprawy). Proces świadczenia usługi przesuwany jest w stronę usługi typu A2A, zaś relacja A2C skupia się na potrzebach i korzyściach obywatela,

Powyższe jest więc potwierdzeniem tego co napisałem… Z perspektywy Obywatela pojęcia back-office i middle-office nie mają żadnego znaczenia (i skąd wiadomo, ze akurat dwa??). Za to ów “front-office” to nic innego jak “punkt kontaktu” a komunikacja z Obywatelem to niestety jakiś “formularz”. Proces (wy)świadczenia usługi jest (powinien być, zgodnie z treścią wstępu)  całkowicie ukryty przed Obywatelem.

? otwarcie i integracja rejestrów publicznych przy zapewnieniu bezpieczeństwa danych obywateli.

Rejestry publiczne to “wnętrze systemu”, z perspektywy Obywatela “nie istnieją” bo jaką usługą (sprawą mającą wartość dla Obywatela) jest “dostęp do rejestru”?  Jeżeli mam w kieszeni Dowód Osobisty, to czym tu jest dostęp do “Rejestru”?

2 Metareguły usług cyfrowych dla obywatela

Metareguły dotyczą sposobu funkcjonowania administracji publicznej w kontekście świadczenia usług w sferze cyfrowej. Są one kluczowe podczas budowy i świadczenia cyfrowych usług publicznych.

Traktuję to jako preambułę.

? Potrzeby i korzyści obywatela są w centrum ? na każdym etapie procesu świadczenia usługi punktem odniesienia jest potrzeba obywatela, miarą sukcesu jest korzyść uzyskana przez obywatela.

Rozumiem, że usługa to odpowiedź na potrzebę (jej zaspokojenie), produktem usługi jest “coś” z czego obywatel odnosi korzyść. Jednak korzyść obywatel nie powinna być przedmiotem zainteresowania Państwa bo z jakiego powodu? Jeżeli chcę dokument potwierdzający “coś” lub będący “decyzją administracyjną” to to, jaką korzyść ja odniosę zależy ode mnie i kontekstu. Np. wypis z katastru to produkt usługi, ale moja korzyść z jego posiadania (może chce sprzedać nieruchomość, a może się założyłem z kimś, że jest moja i chce to udowodnić). Wprowadzanie tu pojęcia “korzyść obywatela” jest moim zdaniem nadmiarowe.

? Usługi są świadczone w tle ? minimalizacja wymagań wobec klienta, ograniczenie etapów procesu administracyjnego do minimum, osobiste stawiennictwo wnioskodawcy jako wyjątek.

Jeżeli umawiamy się, że celem jest “załatwienie SPRAWY KLIENTA, a nie załatwienie SPRAWY PRZEZ KLIENTA” to powyższe jest jej łamaniem, “minimalizacja wymagań wobec klienta” powinna być raczej zastąpiona albo brakiem wymagań albo (co bardziej prawdopodobne) określonymi konkretnymi wymaganiami  (a takie są zawsze, np. tytuł prawny do nieruchomości w przypadku żądania wypisu z księgi wieczystej).

? Administracja jest podstawowym źródłem danych ? pobieranie danych z rejestrów państwowych; zakaz wymagania od obywatela informacji będących już w posiadaniu administracji, możliwych do uzyskania automatycznie drogą elektroniczną bądź wynikających z procesu świadczenia usług.

To już mamy za sobą: urząd (Państwo) nie może żądać od obywatela danych, którymi juz dysponuje.

? Dokumenty skierowane do obywatela umieszczane są w repozytorium? w sytuacji, w której obywatel nie potrzebuje (nie zwraca się o wydanie) dokumentu kończącego świadczenie usługi (postępowanie administracyjne), ma możliwość pobrania go w dowolnym momencie.

To jest już implementacja, osobiście uważam, że na poziomie metareguł (metamodeli) nie operuje się implementacją (repozytorium), sugeruję pojęcie “archiwum” i “teczka sprawy”.

? Dostęp do informacji o stanie sprawy jest możliwy na każdym etapie ? system transakcyjny obsługujący usługę daje obywatelowi możliwość sprawdzenia statusu załatwianej sprawy i szacunkowego czasu do jej zakończenia, na kluczowych etapach sprawy użytkownik otrzymuje powiadomienia;

Tu jak wyżej… skoro obywatel “ma możliwość pobrania go [dokumentu] w dowolnym momencie” to chyba mamy tu zbędne powtórzenie treści.

? Usługi łączone są w pakiety ? powiązanie usług wynikających z danej potrzeby/zdarzenia życiowego (np. narodziny dziecka, becikowe, Rodzina 500+ – użytkownik ma możliwość załatwienia ich wszystkich w jednej transakcji).

To chyba ktoś popłynął. O jakiej “transakcji mowa” (znowu implementacja na poziomie metareguł). Usługi są autonomiczne i niezależne, jeżeli ktoś uzna, ze chce skorzystać z “kilku” (pakiet) to jest to kontekst klienta a nie systemu.  Próba tworzenia nazwanych “pakietów” prowadzi do niewyobrażalnej liczby kombinacji (zakładam, że usług będzie nie kilka a znacznie więcej).

? Projektowanie uniwersalne ? responsywność, dostępność z różnych platform sprzętowych oraz dla osób niepełnosprawnych ? uwzględnienie wytycznych WCAG 2.0.

Znowu implementacja.

? Interfejs użytkownika ? zastosowanie wytycznych dotyczących wyglądu stron internetowych i aplikacji udostępniających e-usługi.

Znowu implementacja.

? Bezpieczeństwo i niezawodność ? zapewnienie bezpieczeństwa danych w warstwie technologicznej oraz pewności prawa w trakcie świadczenia usługi.

Tego nie rozumiem. Co ma Obywatel do “danych w warstwie technologicznej”, jak mam rozumieć pojęcie “pewności prawa w trakcie świadczenia usługi”?

? Otwartość na integracje ? dostarczenie API, które pozwoli wpiąć Twoją usługę do większego pakietu i/lub zintegrować ją z portalem GOV.PL

Integrację z czym skoro obywatel to “aktor” systemu? Czy chodzi o to, że państwo ma świadczyć usługi nie tylko Obywatelom ale także “zewnętrznym systemom”?  Może warto to doprecyzować?

3 Zasady budowy cyfrowych usług publicznych

Tu pojawiają się elementy dla mnie niezrozumiałe, które skomentuję.

1. Sprawdź, czego potrzebują odbiorcy (projektowanie usług)

Odbiorcy, czyli rozumiem Obywatele/Klienci (słownik pojęć by się przydał). Tak się składa, że Urzędy działają na podstawie prawa więc nie bardzo wiem co tu jeszcze z nimi ustalać?

2. Minimalizuj obciążenia po stronie użytkownika (projektowanie usług)

To bardzo ogólnie sformułowane wymagania “pozafunkcjonalne”, jednak brak kryterium pozwalającego stwierdzić czy zostało wykonane, pozostaje oświadczenie “minimalizowaliśmy”.

3. Pamiętaj, że usługa jest procesem (projektowanie usług)

Jeżeli na początku czytamy, że “załatwianiu SPRAWY KLIENTA, a nie załatwieniu SPRAWY PRZEZ KLIENTA” to tu autor zaprzecza sam sobie.

4. Pozyskuj od klientów tylko niezbędne dane (projektowanie usług)

Jeżeli wcześniej napisano, że Państwo nie może żądać od Obywatela danych które juz posiada, to ten zapis jest chyba zbędny.

5. Projektuj uniwersalne usługi dla wszystkich odbiorców (projektowanie usług)

To także chyba oczywistość?

Podsumowanie

Niestety nie było moim celem komentowanie całości, byłyby to zbliżone do powyższych komentarze. Cały dokument wygląda troszkę jak atrapa “Manifestu Agile”. Dokument jest nieprecyzyjny i nie wiem jak wyglądało by korzystanie z niego. Warto zwrócić uwagi na potrzebę uporządkowania pojęć i domeny problemu:

Takie pojęcia jak korzyść obywatela czy potrzeba obywatela są nie tylko nieprecyzyjne ale i nadmiarowe w moich oczach. System świadczący obywatelowi usługi to, z perspektywy tego obywatela, “coś” co wyda z siebie coś na żądanie, które to żądanie należy poprawnie sformułować. I nic więcej.

Powyższe to szkielet takiego systemu. Co do zasady mamy tu metausługę mającą jako instancje konkretne usługi, metaklienta mającego dwie instancje: człowieka korzystającego z GUI oraz aplikacje korzystającą z API.

Konkluzja 1.: usługę świadczy Państwo więc nie widzę innej możliwości by złożenie podania miało sie odbyć inaczej niż przez GUI.

Konkluzja 2.: rejestrami są także Archiwa, więc śledzenia stanu spraw nie powinno być kłopotem.

Konkluzja 3.: skoro proces wewnętrzny ma być ukryty przez Obywatelem, to znaczy że nie bierze on w ogóle z nim udziału, czyli te System nie jest aplikacją “workflow” z perspektywy Obywatela.

Na zakończenie

W projektach, których celem jest z jednej strony porządkowanie opisu systemów od strony wymagań na nie, a z drugiej narzucenie pewnych rygorów na ich projektowanie, wygodną metodą jest użycie modeli kontekstowych  (tu przypadki użycia) oraz tworzenie tak zwanych polityk, czyli zestawu reguł, zasad narzucających ograniczenia np. na architekturę, metody integracji  itp. Do tego korzystanie na tym etapie z metamodeli skojarzonych z tymi politykami, powinno pomóc w utrzymaniu prostoty dokumentu. Obecna postać dokumentu stanowi pewne przemieszanie tych treści. Wstęp to w zasadzie rodzaj preambuły. Kolejny rozdział nazwał bym raczej wymaganiami biznesowymi a nie “metaregułami”, z powodu opisanego wyżej. Rozdział 3. to jakaś niedoprecyzowana forma przekazania dobrych praktyk i wzorców oraz, co wskazałem, także tych mniej dobrych. Bardzo zaskoczyła mnie “algorytmizacja” projektowania, która notabene kłóci się z zasadą: usługa a nie angażowanie obywatela w proces. Ten “algorytm”  (czemu algorytm a nie proces?) angażuje obywatela w proces realizowania usługi w kilku miejscach.

c.d.n.