27 lipca Ministerstwo Gospodarki opublikowało koncepcję systemu InDygo (pełny tekst w PDF). W jego skład wejdzie Centralna Informacja o Działalności Gospodarczej (CIoDG), która zgodnie z Ustawą o swobodzie działalności gospodarczej powinna zostać uruchomiona od 1 stycznia 2007 r. Koncepcja przewiduje także przygotowanie i nieodpłatne przekazanie Urzędom Gmin oprogramowania kompleksowo obsługującego proces ewidencjonowania działalności gospodarczej oraz przesyłania wymaganych informacji pomiędzy poszczególnymi urzędami oraz CIoDG.
Na liście rwo-members pojawiły się obawy, że może to oznaczać powstanie kolejnego płatnika. Na szczęście lektura koncepcji nie potwierdza tych obaw.
Oto fragmenty jej wstępu:
„system zostanie zrealizowany w architekturze dwustopniowej (tj. system centralny i systemy lokalne w gminach) z zastosowaniem otwartych standardów. Przewiduje się istnienie centralnej bazy danych oraz lokalnych kopii w gminach (…)
stworzony zostanie zarówno system centralny, jak i oprogramowanie przewidziane do instalacji w gminach. Jednakże ze względu na już istniejące rozwiązania informatyczne obecne w gminach oraz ich autonomiczność przewiduje się opracowanie otwartego protokołu komunikacyjnego. Umożliwi to użycie różnorodnych rozwiązań na poziomie gmin”.
Trudno się z tymi propozycjami nie zgodzić, zwłaszcza że są one rozwinięciem założeń, na których został oparty wcześniej zrealizowany nadzorowany przez ten sam kierowany przez dyrektora Zbigniewa Olejniczaka departament system rozliczenia pomocy społecznej: gminy mają do wyboru skorzystać z centralnie opracowanego modułu obsługi konkretnej aplikacji (a więc wykonać nałożony na nie przez Państwo wymóg bez ponoszenia dodatkowych kosztów) lub z odpowiedniego modułu oprogramowania używanego do kompleksowej obsługi gminy. Moduł taki musi być zgodny z opublikowanych standardem wymiany danych, przy czym zgodność musi być potwierdzona odpowiednim certyfikatem. Głównym elementem procesu certyfikacji jest wynik praktycznej próby przetworzenia testowych danych, wśród których są przykłady typowych błędów i trudnych do interpretacji sytuacji. Praktyka pokazała, że wymóg uzyskania certyfikatu nie jest poważną barierą utrudniającą autorom oprogramowania wdrożenie ich rozwiązań, a nawet wręcz przeciwnie: znacząco ułatwia im testowanie go. Równocześnie prawie dwuletnie doświadczenie pokazuje, że dane dostarczone przez gminy używające własnego, certyfikowanego oprogramowania nie zawierają więcej błędów lub nieścisłości niż centralnie rozprowadzana aplikacja.
Bardzo podobne (choć na razie bardzo wstępne) są doświadczenia z wdrażania systemu informacji oświatowej, gdzie również dzięki wymogom ustawowym wprowadzonym z inicjatywy RWO opublikowany został kompletny format wymiany danych.
W założeniach InDyGo czytamy między innymi:
„3. Pełny dostęp do danych w Internecie – zgodnie z zapisami ustawy o swobodzie działalności gospodarczej informacje zawarte w ewidencji są jawne i dostępne dla każdego. W związku z tym architektura systemu przewiduje internetową wyszukiwarkę umożliwiającą odnajdowanie informacji o zarejestrowanych przedsiębiorcach. (…)
5. Lekka architektura – system zostanie zbudowany w lekkiej architekturze internetowej, z zastosowaniem cienkiego klienta (przeglądarki internetowej), a więc bez tworzenia specjalnej aplikacji klienckiej. (…)
7. Budowa komponentowa – system zostanie zbudowany z komponentów obsługujących poszczególne obszary funkcjonalne. Sposób implementacji umożliwi wymianę i dodawanie komponentów bez modyfikacji pozostałych części systemu.
8. Architektura oparta o standardy – w celu obniżenia kosztów systemu i podniesienia jego trwałości wymogiem będzie zbudowanie go w oparciu o otwarte standardy przemysłowe bez stosowania rozwiązań specyficznych dla produktów konkretnych firm wszędzie tam, gdzie jest to możliwe. System lokalny zostanie zaprojektowany w sposób umożliwiający zastosowanie rozwiązań open source. Ma to zapewnić zarówno obniżenie kosztów, jak i uniezależnienie administracji publicznej od konkretnych dostawców i rozwiązań.”
W szczegółowym opisie specyfikacji czytamy między innymi:
„Opracowany protokół musi zostać udokumentowany i przyjęty przed rozpoczęciem wdrożenia. Dokumentacja protokołu powinna być dostępna z wyprzedzeniem dla innych dostawców, którzy będą przygotowywać oprogramowanie dla systemów lokalnych względnie dostosowywać już istniejące do współpracy z systemem.
3.2.13. Rekomendacje technologiczne, standardy Aby możliwa była realizacja założeń projektu konieczne jest przestrzeganie następujących założeń:
- Oparcie komunikacji pomiędzy systemami lokalnymi a centralnym o otwarte i udokumentowane standardy.
- Komponentowa architektura, udokumentowany sposób komunikacji pomiędzy komponentami, oparty o otwarte standardy.
- Komunikacja z innymi systemami tam gdzie to możliwe, oparta o otwarte i udokumentowane standardy, np. XML.
- Wykorzystanie standardów przemysłowych przy budowie systemów lokalnych, zwłaszcza w zakresie systemu lokalnego, a więc:
- interfejs w HTML,
- SQL-owa relacyjna baza danych, w miarę możliwości (mniejsze ośrodki) baza open source (Postgres, MySQL),
- aplikacja w J2EE (Java) posadowiona na serwerze aplikacyjnym, w miarę możliwości (mniejsze ośrodki) open source (np. JBoss, Zope),
- brak zależności od konkretnego systemu operacyjnego, środowiska deweloperskiego lub zestawu płatnych bibliotek, itp., który uzależniałby administrację publiczną od konkretnego dostawcy tych elementów”
W specyfikacji konkretnych wymagań znalazłem kilka sformułowań, które wymagają dokładniejszych wyjaśnień, na przykład wymóg kwalifikowanego podpisu elektronicznego przy elektronicznym zgłaszaniu zmian w rejestrze, ale ta sprawa wymaga zmiany ustawy o podpisie elektronicznym.
Archiwalny news dodany przez użytkownika: Vlado.
Kliknij tutaj by zobaczyć archiwalne komentarze.