Problematyka świadczenia e-usług publicznych z wykorzystaniem

Anna Siemek
Stowarzyszenie „Miasta w Internecie”
e-mail: [email protected]
Problematyka świadczenia e-usług publicznych z
wykorzystaniem interoperacyjnych rozwiązań na
poziomie regionalnym - prezentacja rozwiązania
TERREGOV
Streszczenie
Zapewnienie interoperacyjności definiowanej jako zdolność systemów teleinformatycznych oraz wspieranych przez nie procesów biznesowych do wymiany danych oraz do dzielenia się informacjami i wiedzą,
staje się coraz istotniejszym problemem w procesach rozwoju elektronicznej administracji. Dokumentem o priorytetowym znaczeniu dla interoperacyjności w Unii Europejskiej są Europejskie Ramy Interoperacyjności.
WaŜną rolę w rozwoju elektronicznej administracji, w tym w rozwoju e-usług publicznych, odgrywa problematyka zarządzania procesami
biznesowymi, a istotnym etapem procesu wdraŜania e-usług publicznych
jest reorganizacja procesów administracyjnych.
WdraŜanie e-usług publicznych postępuje najwolniej na szczeblu
lokalnym, jednocześnie większość interakcji obywatela i przedsiębiorcy z
administracją publiczną następuje właśnie na tym poziomie. Zintensyfikowanie procesów rozwoju elektronicznej administracji na szczeblu lokalnym moŜna osiągnąć poprzez tworzenie regionalnych centrów interoperacyjności.
Podstawowe podsystemy rozwiązania TERREGOV, które jest prezentowane w tym artykule, są zaprojektowane tak, aby móc być współdzielonymi przez wiele jednostek administracji publicznej i tym sposobem stanowić centrum zapewniające interoperacyjność heterogenicznych
systemów poszczególnych jednostek. Jednocześnie pewne podsystemy
rozwiązania TERREGOV, działające na poziomie jednostek administracji
publicznej, pozwalają w prosty sposób rozwiązać problem dostępu do
wewnętrznych systemów tych jednostek, bez konieczności pełnej integracji tych systemów z systemami zewnętrznymi.
1. Zagadnienie interoperacyjności
Wykorzystanie technologii informacyjnych i telekomunikacyjnych
[ang. Information and Telecommunication Technologies, ICT] w administracji publicznej staje się coraz powszechniejsze. Wraz z rosnącą liczbą
rozwiązań bazujących na ICT w administracji publicznej coraz większego
znaczenia nabiera zagadnienie ich interoperacyjności. Interoperacyjność
definiowana jest jako zdolność systemów teleinformatycznych oraz
wspieranych przez nie procesów biznesowych do wymiany danych oraz
do dzielenia się informacjami i wiedzą. Taka definicja interoperacyjności
wprowadzona została w Europejskich Ramach Interoperacyjności [ang.
European Interoperability Framework, EIF], których pierwsza wersja została opublikowana w listopadzie 2004 roku. Dokument ten jest bardzo
waŜny z punktu widzenia rozwoju elektronicznej administracji na poziomie ogólnoeuropejskim, gdyŜ dokonuje uporządkowania zagadnień związanych z zapewnianiem interoperacyjności, jednocześnie wskazując działania, jakie winny być podjęte dla jej osiągnięcia.
Interoperacyjność naleŜy postrzegać jako swego rodzaju warunek
wstępny, bez spełnienia którego nie sposób świadczyć usług elektronicznej administracji. Osiągnięcie interoperacyjności jest niezbędne, aby móc
świadczyć e-usługi publiczne w sposób, który dla odbiorcy czyni niewidzialnym granice poszczególnych organizacji, a takŜe krajów. Interoperacyjność pozwala organizacjom uczestniczyć w multilateralnych procesach
wymiany informacji i realizacji transakcji, przy jednoczesnym zachowaniu niezaleŜności.
W EIF wprowadzony został podział interoperacyjności na trzy grupy: techniczną, semantyczną i organizacyjną. Interoperacyjności techniczna występuje wtedy, gdy są zapewnione właściwe warunki techniczne
dla komunikowania się systemów teleinformatycznych – uzgodnione interfejsy aplikacji, protokoły i mechanizmy dla efektywnej i bezpiecznej
komunikacji, format prezentowanych informacji i wymienianych komunikatów. Interoperacyjność semantyczna występuje wtedy, gdy wymieniane przez systemy teleinformatyczne komunikaty rozumiane są semantycznie, czyli rozumiane jest ich znaczenie (relacja pomiędzy komunikatem a przedmiotem do którego się odnosi).1 Interoperacyjność organizacyjna zachodzi wówczas, gdy zostały uzgodnione procesy biznesowe
podmiotów publicznych pod kątem efektywnego działania administracji
publicznej, w szczególności świadczenia usług publicznych.
Komisja Europejska uwaŜa kwestię zapewnienia interoperacyjności
rozwiązań ICT za kluczową dla rozwoju elektronicznej administracji
[ang. eGovernment], czemu wyraz dała między innymi uruchamiając program Interoperacyjne dostarczanie europejskich usług elektronicznej ad1
Koncepcja Polskich Ram Interoperacyjności, dokument opracowany w ramach projektu naukowo-badawczego „Wirtualny Konsultant Usług Publicznych” [projekt 6 ZR 9 2005C/06668] finansowanego przez Ministerstwo Nauki i Szkolnictwa WyŜszego.
ministracji jednostkom administracji publicznej, przedsiębiorcom oraz
obywatelom2 [ang. Interoperable Delivery of European eGovernment
Services to public Administrations, Businesses and Citizens, IDABC].
Właśnie w ramach programu IDABC opracowano wytyczne w zakresie
interoperacyjności, czyli wspomniane EIF.
Na rok 2007 planowane jest opublikowanie wersji 2.0 EIF. We
wrześniu 2006 roku w ramach programu IDABC Komisja Europejska
uruchomiła studium, którego wyniki mają pomóc w przygotowaniu wersji
2.0. Dokonanie studium zostało zlecone firmie Gartner. W studium3 opublikowanym 4 czerwca 2007 roku, firma Gartner zwraca uwagę między
innymi na fakt, Ŝe wprowadzony w wersji 1.0 EIF model interoperacyjności jest niekompletny. W szczególności wskazuje na pominięcie znaczenia pojęcia procesu w warstwie interoperacyjności organizacyjnej, jako na
istotną słabość wprowadzonego modelu.
2. Reorganizacja procesów biznesowych
Pojęcie procesu biznesowego4 w kontekście świadczenia e-usług
publicznych, jest istotnym ogniwem spajającym działania niezaleŜnych
jednostek administracji publicznej, umoŜliwiającym świadczenie e-usług
przy wykorzystaniu idei tzw. jednego okienka [ang. one-stop-shop]. Zagadnienie zarządzania procesami biznesowymi odgrywa jedną z głównych ról w procesach rozwoju elektronicznej administracji. Kolejnym
waŜnym zagadnieniem dla rozwoju elektronicznej administracji, silnie
związanym z wdraŜaniem e-usług publicznych jest reorganizacja procesów administracyjnych. Reorganizacja procesów administracyjnych, ina2
http://europa.eu.int/idabc, 30.08.2007.
http://ec.europa.eu/idabc/servlets/Doc?id=29101, 30.08.2007.
4
Pod pojęciem procesu biznesowego naleŜy rozumieć takŜe proces administracyjny. Pojęcia te
będą uŜywane w tekście zamiennie.
3
czej określana mianem reinŜynierii procesów, oznacza wprowadzanie
zmian w przepływie pracy lub zmian o charakterze organizacyjnym dotyczących podmiotów uczestniczących w tych procesach administracyjnych. Reorganizacja procesów administracyjnych jest naturalnym i poŜądanym elementem procesu rozwoju e-usługi. WdraŜając e-usługę publiczną naleŜy bowiem przeanalizować odpowiadający jej proces administracyjny i starać się zamodelować go w sposób optymalny, tzn. zapewniający optymalizację korzyści z wykorzystania rozwiązań ICT w procesie świadczenia usługi5.
Urząd 1
Urząd 3
Wywołanie usługi
sieciowej a
Wywołanie usługi
sieciowej b
Wywołanie usługi
sieciowej c
Proces administracyjny
Krok B
Start
Krok C
Krok A
Krok F
Krok D
Wywołanie usługi
sieciowej e
Krok G
Stop
Krok E
Wywołanie usługi
sieciowej f
Wywołanie usługi
sieciowej g
Wywołanie usługi
sieciowej d
Urząd 2
Urząd 4
Rysunek 1. Proces biznesowy składający się z wielu kroków realizowanych poprzez wywołanie
usług sieciowych udostępnianych przez róŜne jednostki administracji publicznej
Źródło: Opracowanie własne na podstawie materiałów dostępnych pod adresem http://terregovoss.eupm.net
5
Szczegółową analizę zagadnienia reorganizacji procesów administracyjnych odnaleźć moŜna w
dokumencie Institut für Informationsmanagement GmbH, Danish Technological Institute, Reorganisation of government back-offices for better electronic public services – European good practices (back-office reorganization).
Reorganizacja procesu administracyjnego nie jest zadaniem łatwym, a trudność tego zadania rośnie wraz ze stopniem skomplikowania
procesu administracyjnego, który wyraŜa się między innymi ilością niezaleŜnych jednostek administracji publicznej uczestniczących w realizacji
procesu oraz ilością systemów wewnętrznych tych jednostek, które wymagają integracji. Tutaj ponownie pojawia się problem zapewnienia interoperacyjności systemom, które muszą być w stanie wymieniać się danymi, aby moŜna było zapewnić realizację wdraŜanej e-usługi publicznej.
Właściwym podejściem jest oczywiście uwzględnianie wymogów zapewnienia interoperacyjności na etapie projektowania i wdraŜania systemów informatycznych. W rzeczywistości administracji publicznej mamy
jednak do czynienia z duŜą ilością systemów, które nie są w stanie ze sobą współpracować, zostały bowiem stworzone przez róŜnych producentów, do róŜnych celów, w oparciu o róŜne standardy, w róŜnych okresach
czasu. Pojawia się zatem problem, jak zapewnić współpracę tych systemów i to przy optymalnym nakładzie środków: czasu, pracy, kosztów,
itd. Właśnie rozwiązania takiego problemu podjęto się w projekcie TERREGOV [ang. Impact of eGovernment on Territorial Government Services]6.
3. Istota rozwiązania TERREGOV
Celem projektu TERREGOV było wypracowanie rozwiązania, które umoŜliwiłoby świadczenie wysokiej jakości e-usług publicznych, niezaleŜnie od tego jak wiele jednostek administracji publicznej zaangaŜowanych byłoby w ten proces. Twórcy rozwiązania TERREGOV wzięli
6
Projekt współfinansowany w ramach Programu „Technologie Społeczeństwa Informacyjnego” 6.
Programu
Ramowego
Badań
i
Rozwoju
Technicznego
Unii
Europejskiej,
http://www.terregov.eupm.net.
pod uwagę, iŜ często na etapie projektowania e-usług publicznych, słusznym okazuje się integracja kilku, do tej pory niezaleŜnych, usług publicznych. Taka integracja usług prowadzi do powstania bardzo złoŜonych
procesów administracyjnych. Podejście takie jest słuszne, gdy chcemy
reorientować usługę na klienta [ang. citizen-centric service]. Świadczenie
usług zorientowanych na klienta prowadzi najczęściej do koncentracji
usług wokół sytuacji Ŝyciowych [ang. life cases], w przypadku usług dla
obywateli, lub wokół sytuacji biznesowych [ang. business episodes], w
przypadku usług dla przedsiębiorstw.
Konsorcjum projektu TERREGOV postawiło sobie następujące cele
szczegółowe:
• umoŜliwić jednostkom administracji publicznej udostępnianie swoich
usług online w taki sposób, aby mogły być one wykorzystane przez inne jednostki do stworzenia zintegrowanych [zorientowanych na klienta] usług publicznych,
• umoŜliwić jednostkom administracji publicznej orkiestrację usług udostępnianych przez wiele jednostek w jeden proces administracyjny.
Aby zrealizować tak postawione cele, w pierwszej kolejności, naleŜało rozwiązać problem związany z koniecznością zapewnienia współpracy duŜej ilości rozproszonych, zamkniętych systemów informatycznych [ang. legacy systems], będących wewnętrznymi systemami róŜnych
jednostek administracji publicznej. Biorąc pod uwagę opisane uwarunkowania, uznano, Ŝe racjonalnym rozwiązaniem będzie wykorzystanie
technologii usług sieciowych7 [ang. Web Services, WS], jako specyficznego interfejsu do wewnętrznych systemów informatycznych. Wykorzystanie technologii usług sieciowych ma tą podstawową zaletę, Ŝe nie wy7
http://www.w3.org/2002/ws, 30.08.2007.
maga pełnego otwarcia systemu informatycznego, pozostawiając w rękach danej jednostki administracji publicznej decyzję o tym, jakie usługi
chce udostępnić8. Stwierdzenie, Ŝe zdecydowano się na wykorzystanie
technologii usług sieciowych jest pewnym uproszczeniem. W praktyce
decyzja ta była naturalną konsekwencją decyzji w zakresie architektury
rozwiązania.
Uwzględniając
uwarunkowania
technologiczno-
organizacyjne środowiska, w którym ma działać rozwiązanie TERREGOV, wybrano architekturę zorientowaną na usługi [ang. Service Orientem Architecture, SOA].
Wykorzystanie technologii usług sieciowych pozwoliło na osiągnięcie pierwszego poziomu interoperacyjności, tj. interoperacyjności
technicznej. Jednak pozostał problem, jak umoŜliwić wykorzystanie udostępnionych usług sieciowych w celu kompozycji procesów administracyjnych, na które składałyby się usługi udostępniane przez wiele róŜnych
podmiotów. Aby móc wykorzystać udostępnioną usługę sieciową nie wystarczą informacje zawarte w opisie usługi, na jaki pozwala język opisu
usług sieciowych [ang. Web Service Description Language, WSDL]. Do
tego celu konieczna jest wiedza na temat znaczenia danych wejściowych i
wyjściowych usługi sieciowej, jej działania, warunków wstępnych, itp.
Całość tej informacji określa się mianem warstwy znaczeniowej usługi
sieciowej [ang. semantics of a Web Service]. W ten sposób identyfikujemy potrzebę zapewnienia interoperacyjności semantycznej. W systemach
informatycznych konstrukcje reprezentujące informacje semantyczne
określa się mianem ontologii. Ontologia [ang. ontology] to formalna reprezentacja wiedzy dotyczącej wybranego fragmentu rzeczywistości. W
8
NaleŜy takŜe pamiętać, Ŝe istnieją regulacje prawne ograniczające swobodę wymiany informacji
gromadzonych przez poszczególne jednostki administracji publicznej. Jednak uwarunkowania
prawne nie są przedmiotem tego artykułu.
projekcie TERREGOV stworzono ontologię definiującą podstawowe pojęcia z zakresu administracji publicznej. PoniewaŜ wdroŜenia pilotowe
rozwiązania TERREGOV dotyczą domeny pomocy społecznej, to równieŜ stworzona ontologia w sposób szczególny koncentruje się na tej domenie. W projekcie TERREGOV do zapisu ontologii wybrano język ontologii sieciowej9 [ang. Web Ontology Language, OWL]. Wprowadzenie
ontologii do rozwiązania TERREGOV zapewnia, Ŝe wszyscy korzystający z tego rozwiązania w ten sam sposób rozumieją pojęcia waŜne dla procesów administracyjnych, których realizacja wspierana jest przez to rozwiązanie. PilotaŜowe wdroŜenia rozwiązania TERREGOV realizowane są
w róŜnych krajach Unii Europejskiej, w związku z tym konieczne było
przygotowanie ontologii wielojęzycznej. Udowodniono tym samym, Ŝe
moŜliwe jest stworzenie wspólnej warstwy semantycznej dla systemów
ICT nie tylko róŜnych instytucji w danym kraju, ale takŜe dla systemów
funkcjonujących w róŜnych krajach, a zatem wykorzystujących róŜne
języki.
Samo opracowanie ontologii nie zapewnia jeszcze osiągnięcia interoperacyjności semantycznej. Konieczne jest stworzenie warunków do jej
wykorzystania. Przede wszystkim koniecznym było przygotowanie narzędzi, które pozwalałyby między innymi na:
• tworzenie opisów usług sieciowych z wykorzystaniem informacji semantycznej – w tym celu powstało narzędzie nazwane Semantycznym
Łącznikiem [ang. Semantic Binder, SB], które na podstawie pliku
WSDL zawierającego opis dowolnej usługi sieciowej oraz ontologii
TERREGOV pozwala w prosty sposób przygotować opis usługi sie-
9
http://www.w3.org/TR/owl-features, 30.08.2007.
ciowej w języku słuŜącym do semantycznego opisu usług10 [ang. Semantic Markup for Web Services, OWL-S],
• publikowanie semantycznej informacji o dostępnych usługach sieciowych i ich wyszukiwanie – w tym celu stworzony został Semantyczny
Rejestr [ang. Semantic Registry, SR]; tradycyjny rejestr usług sieciowych bazujący na standardzie UDDI11 [ang. Universal Description,
Discovery and Integration] rozszerzony został o elementy pozwalające
odnajdywać usługi sieciowe definiując warunki wyszukiwania na poziomie informacji semantycznej; wykorzystano między innymi Silnik
Semantyczny [ang. Semantic Engine, SE] bazujący na środowisku
programistycznym Jena12 [ang. Semantic Web Framework for Java],
który pozwala na wnioskowanie z opisów w OWL-S oraz ontologii
przy wykorzystaniu języków zapytań SPARQL13 oraz RDQL14 [ang.
Query Languages for RDF]; dodatkowo stworzony został Kompozytor
Usług Sieciowych [ang. Web Services Composer, WS C], który jest
wykorzystywany w sytuacji, gdy nie ma pojedynczej usługi sieciowej
o wejściu i wyjściu odpowiadającym zapytaniu wysłanemu do SR, WS
C próbuje wówczas wyszukać taką sekwencję usług, z których pierwsza ma wejście, a ostatnia wyjście odpowiadające zdefiniowanym w
zapytaniu.
Stworzenie uzgodnionej, wspólnej warstwy znaczeniowej pozwala
nie tylko zapewnić interoperacyjność semantyczną, ale takŜe ułatwia
osiągnięcie interoperacyjności na poziomie organizacyjnym. Drugim, z
postawionych sobie przez konsorcjum projektu TERREGOV celów było
10
http://www.w3.org/Submission/OWL-S, 30.08.2007.
http://uddi.org, 30.08.2007.
12
http://jena.sourceforge.net, 30.08.2007.
13
http://www.w3.org/TR/rdf-sparql-query, 30.08.2007.
14
http://www.w3.org/Submission/2004/SUBM-RDQL-20040109, 30.08.2007.
11
umoŜliwienie jednostkom administracji publicznej orkiestrację usług udostępnianych przez wiele podmiotów w jeden proces administracyjny. Do
zarządzania procesami biznesowymi, których poszczególne kroki odpowiadają usługom sieciowym, za najodpowiedniejszy uznano standard
BPEL15 [ang. Business Process Execution Language]. Podsystem rozwiązania TERREGOV odpowiedzialny za zarządzanie procesami biznesowymi [ang. Workflow Management Subsystem], jako swój centralny moduł wykorzystuje silnik ActiveBPEL16, a zatem rozwiązanie bazujące
właśnie na standardzie BPEL. Definiując nowy proces biznesowy, przy
wykorzystaniu wspomnianego języka, naleŜy zidentyfikować konkretne
implementacje usług sieciowych, które będą wywoływane jako kolejne
kroki definiowanego procesu.
Z róŜnych powodów identyfikacja konkretnych implementacji usług
sieciowych moŜe być jednak trudna, a czasami niemoŜliwa, na etapie
komponowania procesu biznesowego. Twórcy rozwiązania TERREGOV
postanowili rozwiązać ten problem korzystając z moŜliwości, które dało
wzbogacenie rozwiązania o warstwę semantyczną. Za konieczne uznano
umoŜliwienie definiowania procesów biznesowych bez konieczności
wskazywania na rzeczywiste implementacje usług sieciowych, a jedynie
określanie ich przez wykorzystanie informacji semantycznej. PoniewaŜ
BPEL nie daje takich moŜliwości, a ewentualna propozycja rozszerzenia
standardu byłaby rozwiązaniem długotrwałym i dodatkowo nie gwarantującym powodzenia, dlatego postanowiono skorzystać z rozwiązania pośredniego. Rozwiązanie TERREGOV daje moŜliwość zaszycia w skrypcie BPEL informacji semantycznych określających usługę sieciową, a
specjalnie do tego celu przygotowany moduł, tzw. Pośrednik Wywoływa15
16
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel, 30.08.2007.
http://www.active-endpoints.com/active-bpel-engine-overview.htm, 30.08.2007.
nia [ang. Proxy Invoker, PI], we współpracy z Semantycznym Rejestrem,
odpowiada za odnalezienie właściwej implementacji usługi sieciowej w
momencie wykonywania procesu. W sytuacji, gdy SR nie odnajdzie jednej usługi odpowiadającej przesłanemu przez PI Ŝądaniu, a w odpowiedzi
prześle informację o sekwencji usług, wówczas PI na podstawie otrzymanych informacji automatycznie stworzy skrypt BPEL i przekaŜe go do
wykonania do silnika BPEL. Opisane dynamiczne komponowanie procesów biznesowych oraz definiowanie procesów biznesowych z wykorzystaniem informacji semantycznej, to przykłady najbardziej innowacyjnych elementów rozwiązania TERREGOV.
Regionalne Centrum Interoperacyjności
Ontology Storage
Semantic Acess to Web
Services
Security
Semantic
Registry
Semantic
Binder
Security
Workflow
Management
Community of
Practice
Ontology
Management
Interoperability
Layer
Legacy System
Jednostka administracji publicznej
Rysunek 2. Ogólna architektura rozwiązania TERREGOV
Źródło: Opracowanie własne na podstawie materiałów dostępnych pod adresem http://terregovoss.eupm.net
Artykuł przedstawia tylko wybrane podsystemy i moduły rozwiązania TERREGOV, istotne z punktu widzenia poruszanej tematyki. NaleŜy
sobie jednak zdawać sprawę, iŜ opisane komponenty nie byłyby w stanie
funkcjonować bez szeregu innych komponentów, takich jak: Podsystem
Zarządzania Ontologią [ang. Ontology Management Subsystem], Podsystem Zapewnienia Bezpieczeństwa [ang. Security Subsystem] czy Warstwa Interoperacyjności funkcjonująca na poziomie jednostek administracji publicznej [ang. Intra-Agency Interoperability Layer]. WaŜnym, a pominiętym w artykule, elementem rozwiązania jest Podsystem Wsparcia
dla Wymiany Doświadczeń [ang. Community of Practice Subsystem],
którego podstawowym celem jest ułatwienie urzędnikom docierania do
potrzebnych im informacji. Pomocą dla urzędników jest takŜe Moduł
Wyboru Usług Publicznych [ang. eProcedure Choice Module], który dysponując dostępem do informacji o obywatelu oraz opisem usług publicznych17, dokonuje identyfikacji tych usług, z których obywatel ma prawo
skorzystać ze względu na swój status społeczno-finansowy18. Ogólną architekturę rozwiązania TERREGOV przedstawiono na rysunku 2.
4. Idea regionalnych centrów interoperacyjności
Powracając do problemu, chęć rozwiązania którego była aktywatorem działań podjętych przez konsorcjum projektu TERREGOV, naleŜy
zwrócić uwagę na specyfikę rozwoju elektronicznej administracji na poziomie lokalnym. Większość interakcji obywatela czy przedsiębiorcy z
administracją publiczną następuje właśnie na poziomie lokalnym, stąd
podnoszenie jakości usług świadczonych na tym poziomie wpływa najsilniej na sposób postrzegania administracji publicznej. Niestety jednocze17
Usługi publiczne są reprezentowane w systemie jako procesy biznesowe opisane z wykorzystaniem BPEL. KaŜdy skrypt BPEL moŜe zostać opisany z wykorzystaniem WSDL, a następnie opis
ten moŜna opublikować w Semantycznym Rejestrze, co oznacza, Ŝe proces biznesowy, a zatem teŜ
usługa publiczna, mogą być wyszukiwane dokładnie w ten sam sposób, w jaki wyszukiwane są
zwykłe usługi sieciowe.
18
Pamiętajmy, Ŝe domeną, w której realizowane jest pilotaŜowe wdroŜenie rozwiązania TERREGOV jest obszar pomocy społecznej.
śnie rozwój elektronicznej administracji, w tym wdraŜanie e-usług publicznych, najwolniej postępuje właśnie na szczeblu lokalnym. Dzieje się
tak, poniewaŜ świadczenie e-usług publicznych wymaga interakcji pomiędzy szeregiem jednostek administracji publicznej dysponującymi róŜnymi rozwiązaniami w zakresie ICT. Stworzenie i wdroŜenie rozwiązania, które pozwoli zapewnić interoperacyjność tych wielu systemów jest
przedsięwzięciem kosztownym. Dla administracji samorządowej szczebla
lokalnego najczęściej jest to przedsięwzięcie zbyt kosztowne, aby mogły
się podjąć jego realizacji. Biorąc pod uwagę przedstawione uwarunkowania, wyraźną staje się potrzeba wsparcia jednostek administracji publicznej szczebla lokalnego w ich dąŜeniach do rozwoju zorientowanych na
Urząd 1
INTEROPERABILITY
LAYER
INTEROPERABILITY
LAYER
klienta e-usług publicznych.
Regionalne Centrum Interoperacyjności
Semantic
Access to
Web Services
Urząd 3
Security
Workflow
Management
Urząd 4
INTEROPERABILITY
LAYER
Ontology
Management
INTEROPERABILITY
LAYER
Community
of Practice
Urząd 2
Rysunek 3. Regionalne Centrum Interoperacyjności na bazie rozwiązania TERREGOV
Źródło: Opracowanie własne na podstawie materiałów dostępnych pod adresem http://terregovoss.eupm.net
Racjonalnym rozwiązaniem opisanego problemu wydaje się być
tworzenie centrów interoperacyjności, które umoŜliwiałyby jednostkom
administracji publicznej oferowanie online usług pozwalających na wymianę danych z ich wewnętrznymi systemami informacyjnymi i jednocześnie orkiestrowanie tych cząstkowych usług w duŜe procesy biznesowe odpowiadające usługom publicznym świadczonych obywatelom i
przedsiębiorcom. Ze względu na wspomniane juŜ uwarunkowania natury
finansowej, rozwiązania takie nie mogą powstawać na szczeblach lokalnych. Najwłaściwsze wydaje się być tworzenie centrów interoperacyjności na szczeblu regionalnym. U podstaw rozwiązania, które powstało w
ramach projektu TERREGOV leŜy właśnie idea tworzenia centrów interoperacyjności. Pewne podsystemy i moduły, które składają się na rozwiązanie TERREGOV zostały stworzone do funkcjonowania na poziomie
poszczególnych jednostek administracji publicznej, np. Warstwa Interoperacyjności, która jest niezbędna, aby wewnętrzne systemy tych jednostek mogły komunikować się z pozostałymi podsystemami rozwiązania.
Te pozostałe podsystemy tworzą swego rodzaju „serce” rozwiązania
TERREGOV, które moŜe być współdzielone przez wiele jednostek administracji publicznej i tym sposobem stanowić centrum zapewniające interoperacyjność heterogenicznych systemów poszczególnych jednostek.
Ideę centrum interoperacyjności stworzonego na bazie rozwiązania TERREGOV przedstawiono na rysunku 3.
Bibliografia
Koncepcja Polskich Ram Interoperacyjności, dokument opracowany w ramach
projektu naukowo-badawczego „Wirtualny Konsultant Usług Publicznych” [pro-
jekt 6 ZR 9 2005C/06668] finansowanego przez Ministerstwo Nauki i Szkolnictwa WyŜszego.
Institut für Informationsmanagement GmbH, Danish Technological Institute,
Reorganisation of government back-offices for better electronic public services –
European good practices (back-office reorganization).
Źródła internetowe
http://europa.eu.int/idabc
http://ec.europa.eu/idabc/servlets/Doc?id=29101
http://www.terregov.eupm.net
http://terregov-oss.eupm.net
Summary
The aim of his article is to present how the TERREGOV solution
can help local governments achieve interoperability among heterogeneous
systems. The idea of Regional Interoperability Centres [RICs] and the
arguments for RICs creation are presented. The main issues important for
eGovernment development and in particularly for the citizen-centric
eGovernment services implementation, among others business process
management, are discussed. The general architecture of TERREGOV
solution together with used technical approaches are also introduced in
this article. In particular, two of three main technological R&D streams
are discussed, these are: workflow management [dynamic BPEL scripts
creation, definition of workflows using semantic information] and semantic enrichment of Web Services [discovering of Web Services on the semantic basis in run-time].