W związku z planowaną nowelizacją ustawy o informatyzacji zastanawiam się właśnie nad przyszłym kształem rozporządzenia o minimalnych wymaganiach dla systemów teleinformatycznych. Obecna forma wydaje mi się posiadać szereg wad, które w dużym stopniu ograniczają jej sens.
- Czemu ma służyć określenie "minimalnych wymagań" w postaci np. określenia wersji formatu PDF na 1.4? Nie jest realnym problemem użycie przez jakiś urząd dokumentu w starszej wersji PDF 1.3 - bo to przeczyta każda przeglądarka PDF. Problemem jest użycie zbyt nowej wersji formatu PDF. Nieczytelny dla wielu użytkowników (bo zbyt nowy) format będzie przecież zgodny z rozporządzeniem - bo skoro można "minimalnie 1.4" to znaczy, że można 1.4 i wyższe. Innymi słowy - kompatybilność wsteczna jest powszechna, a prawdziwy problem to kompatybilność z nowszymi wersjami.
- Rozporządzenie zawiera szereg informacji redundantnych i zwyczajnie niepotrzebnych. Np. punkt 4.2 wymienia format TAR wśród formatów kompresji danych, którym przecież nie jest - i jakby dla usprawiedliwienia tej lokalizacji dodatkowo precyzuje, że "zwykle jest używany z GZIP". Takie informacje mogą się znajdować się w książce z serii "recipes for Unix" a nie w rozporządzeniu. Rozporządzenie miejscami przypomina wyliczankę znanych formatów w poszczególnych branżach IT, przez co zaciera się jego sens. Dodatkowo informacje są podawane niespójne - przy jednych podaje się wersje, a przy innych nie. Np. wspomniany wyżej TAR występuje przecież w różniących się wersjach POSIX i GNU.
- Rozporządzenie zdefiniowane jako "minimalne wymagania" w żaden sposób nie dotyka problemów realnie występujących w polskiej administracji jak na przykład publikowanie dokumentów niby w formacie PDF, ale np. zabezpieczonych przed kopiowaniem (to po co się publikuje np. ustawę skoro nie można kopiować fragmentów do komentowania) albo w postaci zeskanowanej bitmapy embedowanej w PDF.
- Rozporządzenie w ogóle nie dotyka bardziej złożonych problemów jak na przykład specyficzny wariant danego formatu, mający w danym przypadku konkretną przydatność. W niektórych przypadkach pożądane byłoby na przykład użycie PDF/A (ISO 19500:2005) zamiast ogólnego PDF 1.4. Ten sam problem dotyczy użycia odpowiedniego profilu XAdES - np. kiedy można użyć XAdES-BES, a kiedy trzeba XAdES-A. W ogóle kwestia długoterminowego przechowywania dokumentów elektronicznych jest słabo uregulowana (choć wspomniana w innych rozporządzeniach).
- Kogo właściwie dotyczy rozporządzenie? Czy tylko komunikacji A2C czy też może systemów wewnątrz administracji, czy może A2A? Jest to punkt kluczowy z punktu widzenia choćby interoperacyjności.
- Na jakie inne akty prawne wpływa to rozporządzenie? Jakie są możliwości jego aktualizacji i uzupełniania?
- Jak regulowana jest kwestia własności formatów oraz implementacji stworzonych dla administracji publicznej?
Ad. 1) Czy rozporządzenie nie powinno określać maksymalnych (zamiast minimalnych) wersji formatów dopuszczalnych w danym momencie z uwzględnieniem jego rozpowszechnienia wśród klientów? Lista taka powinna mieć charakter kroczący, aktualizowany co najmniej co 2-3 lata. Co więcej, w przypadku definiowania standardów minimum zwykle określa się też standard zalecany.
Ad 2) Rozporządzenie powinno być okrojone do minimum, które będzie rozwiązywać konkretne i realnie występujące problemy. Czy umieszczanie takich formatów jak TAR, GZIP czy RAR w rozporządzeniu jest uzasadnione jakimikolwiek realnymi problemami z tymi formatami lub istotną potrzebą ich "legalizacji"? Wydaje mi się, że obligatoryjna część rozporządzenia powinna być ograniczona do minimum i zawierać wyłącznie formaty kluczowe dla interoperacyjności.
Ad 3) Tym bardziej celowe wydaje się określenie zestawów "format X dla zastosowania Y" zamiast prostej enumeracji formatów "do wszystkiego". Być może skan bitmapy w PDF lub PDF zabezpieczony przed kopiowaniem ma sens w jakimś specyficznym zastosowaniu, dlatego wymaganie tylko najprostszej wersji każdego z formatów wydaje się niecelowe. Ale już np. do publikacji dokumentów rozumianych jako informacja publiczna w rozumieniu ustawy o dostępnie do informacji publicznej taki wymóg powinien być określony. Pozwoli to zdyscyplinować autorów BIP, którzy z lenistwa wrzucają na stronę świstek krzywo zeskanowany na marnej jakości kombajnie biurowym i niby że to jest PDF.
Ad 4) Formaty podpisu elektronicznego w polskiej administracji to temat sam w sobie. Wynika to w dużej mierze z braku koncepcji, do czego te formaty mają służyć skoro nikt podpisu nie używa. Krystalizuje się obecnie kilka rozwiązań - jak np. e-Deklaracje czy ZUS - które pozwalają wskazać konkretne wymagania wobec konkretnych zastosowań (patrz Ad 3). Może w tej sytuacji w ogóle nie regulować tego na poziomie rozporządzenia ("ma używać standardu LTANS"), tylko na poziomie ustawy ("ma zapewnić jakąś ochronę długoterminową")? Unikniemy w ten sposób błędu przeregulowania, który popełniono w przypadku e-faktury.
Ad 5) Kwestia interoperacyjności ma dwa aspekty. Po pierwsze, komunikacja A2C i C2A powinna być uregulowana ściśle. Rozporządzenie musi regulować precyzyjnie kwestię formatu dokumentu przyjmowanego przez urząd lub przezeń publikowanego (Ad 1, 2, 3) oraz publicznej dostępności specyfikacji w przypadku interfejsów XML-RPC, web services itd. Z drugiej strony w przypadku formatów stosowanych wewnątrz instytucji ich ścisła zgodność z rozporządzeniem nie powinna ograniczać efektywności pracy - np. stosowanie rozszerzeń PDF czy jakichś prywatnych formatów raczej tutaj obywatelowi nie przeszkadza. Sprawa ma jednak drugi aspekt, jakim jest informatyczne uzależnienie urzędów od jednej firmy, która w ten czy inny sposób wepchnęła swoje rozwiązanie do urzędu i przy każdym kolejnym przetargu jest jedynym oferentem. Problem ten ma też trzeci aspekt, jakim jest ryzyko utraty dostępu do danych zapisanych w prywatnych formatach po wielu latach lub np. wycofaniu się firmy z rynku. Należałoby tutaj zatem wyróżnić kwestię "przetwarzania" (prywatny format plików bazy danych, niech będzie) i "przechowywania" (format backupów z tejże bazy, powinien spełniać definicję formatu otwartego). System stosujący format prywatny powinien mieć możliwość eksportu do formatu owartego.
Ad 6) Kształt rozporządzenia jest krytyczny dla innych ustaw oraz dla formy komunikacji między urzędami. Proszę pamiętać, że w najbliższym czasie musi powstać np. rozporządzenie do ustawy o publikacji aktów prawnych. Źle skonstruowana ustawa o informatyzacji znowu wymusi stworzenie absurdalnie nieużywalnej konstrukcji. Praktyka w takich sytuacjach wskazuje, że administracja w obliczu złego prawa ciężko wzdycha, zaciska zęby i przystępuje do jego konsekwentnej, dosłownej realizacji - tak "zarżnięto" przecież faktury elektroniczne. Zdecydowanie należy unikać przyjmowania hipotetycznych modeli pewnych przyszłych rozwiązań dzisiaj i zamrażania ich w rozporządzeniu. Przyjęcie złych założeń np. co do technicznego kształtu pl-ID i późniejsze dostosowywanie projektu do istniejących regulacji na 100% go położy. Zamiast tego to rozporządzenie należy aktualizować wraz ze wzrostem naszej wiedzy o tym, czego tak naprawdę potrzebujemy (a dzisiaj tego do końca nie wiemy).
Ad 7) W chwili obecnej w kwestia własności formatów i implementacji jest regulowana tak, jak się uda wynegocjować w każdym kontrakcie oddzielnie. Niekiedy są to ustalenia niekorzystne dla urzędów, które traktowane są jak prywatne pastwiska. W szczególnie drastycznych przypadkach firma pisząc dla danego urzędu (i tylko dla niego) wyspecjalizowany system nie przekazywały mu praw do niego, a jedynie udzielały licencji na jego używanie, zapewniając sobie dożywotnie uzależnienie od swoich usług w warunkach wysoce niekonkurencyjnych. W innych przypadkach grupa N identycznych urzędów zamawiała w oddzielnych zleceniach N identycznych opracowań np. opisów swoich procesów biznesowych czy analiz jakiegoś przepisu. Po opłaceniu i przeczytaniu lądowały one w szufladach, a kolejny urząd rozwiązujący ten sam problem od nowa ogłaszał przetarg itd.
Krokiem w dobrą stronę wydawały się być scentralizowane zamówienia publiczne, ale biorąc pod uwagę że (jak się wydaje) porzucono ten pomysł w 2005 roku wygląda na to, że jest on równie pożądany przez tzw. "rynek" jak dwunastoletni już mityczny Rejestr Usług Medycznych (1996-2008). Myślę, że warto wrócić do tej koncepcji rozszerzając ją o wprowadzenie zalecenia zamawiania systemów "na miarę" i mających szansę na wykorzystanie w więcej niż jednej instalacji na licencji podobnej do amerykańskiego modelu Government Purpose Rights License, czyli zakupu oprogramowania wraz z klauzulą gwarantującą dowolnej liczbie urzędów publicznych do wykorzystywania i modyfikowania zakupionego produktu, w tym także ogłaszania otwartych przetargów na modyfikację czy serwis (w których oryginalny producent też mógłby startować). W przypadku opracowań, analiz i interpretacji prawnych zamawianych przez urzędy powinien istnieć obowiązek udostępniania ich innym urzędom (w praktyce wystarczyłby przeszukiwalny rejestr zawierający tytuł, słowa kluczowe i kto to ma).