POPC Wsparcie

W ostatnich latach praktycznie wszystkie jednostki administracji publicznej znacząco rozwinęły wykorzystywane systemy informatyczne. Razem z rozwojem tych systemów ewoluowała architektura aplikacji. Ewolucja zachodziła jednocześnie w różnych obszarach.

 

Interfejs aplikacji

Przez wiele lat interfejs każdego oprogramowania opierał się na dedykowanym „grubym” kliencie. Wszelkie operacje na danych odbywały się bezpośrednio na stacji roboczej użytkownika. Z biegiem czasu i rozwoju środowiska Web podstawowym interfejsem aplikacji stała się przeglądarka internetowa. To znacząco ułatwiło zarządzanie stacjami roboczymi w organizacji – teraz, jeśli korzystamy z przeglądarki internetowej, nie musimy instalować klienta danej aplikacji.
Ta zmiana w sposobie korzystania z interfejsu użytkownika mocno się już ugruntowała. A z każdym rokiem rozwój technologii Web pozwala nam optymalizować ergonomię interfejsu.
Natomiast inne zmiany architektury aplikacji nie są już takie jednoznaczne. Powstaje wiele równoległych rozwiązań, które powoli ewaluują w różnych kierunkach.

 

Zakres aplikacji

Stale ewoluuje zakres merytoryczny aplikacji, który jest obsługiwany za pomocą danego oprogramowania. Zakres zależy od decyzji kierownictwa organizacji. Decyduje ono, czy lepiej wdrożyć kilka mniejszych systemów dziedzinowych (na przykład księgowość, magazyn, podatki, opłaty, kadry, płace, windykację), czy też może jeden duży zintegrowany system, który obejmie wszystkie te obszary. Najczęściej zależy to od wielkości podmiotu publicznego i jego możliwości finansowych. Na rynku są bowiem dostępne aplikacje, które pozwalają obsługiwać poszczególne obszary. Wtedy możemy je wdrażać sukcesywnie, ponosząc jednorazowo mniejsze koszty.
Na rynku możemy też znaleźć duże systemy zintegrowane. Obejmują one od kilku do nawet kilkunastu różnych obszarów dziedzinowych funkcjonowania podmiotu publicznego. Oczywiście wdrożenie takich aplikacji wymaga znacznie większych nakładów finansowych, a także większego zespołu IT oraz zespołu wdrożeniowego w organizacji.

Oba modele informatyzowania organizacji mają swoje zalety i wady, dlatego zapewne będą funkcjonowały równolegle przez wiele lat. Modele te łączy jedna kluczowa kwestia, która jest przedmiotem tego artykułu. Jest nią wymiana danych pomiędzy poszczególnymi obszarami dziedzinowymi funkcjonowania konkretnej jednostki publicznej.

 

Przepływ danych

Niezależnie od tego, czy mamy w organizacji wiele małych, czy też dużych aplikacji, chcemy, by dane wprowadzone w jednym module mogły być wykorzystane w innych obszarach. To naturalne – gdy zatrudniamy pracownika i wypłacamy mu wynagrodzenie, to odpowiednia lista płac jest księgowana w systemie finansowo-księgowym. Naturalne jest też, że faktura zakupu środka trwałego, którą wprowadzimy do jakiegoś systemu, jest podstawą ewidencji magazynowych i wpływa pośrednio na zapisy księgi głównej. Dlatego równie naturalny musi być przepływ danych między obszarami dziedzinowymi.

 

Przepływy danych występują nie tylko wewnątrz organizacji. W ostatnich latach powstało wiele systemów referencyjnych. Powstały dlatego, że były potrzebne i porządkowały dane na poziomie krajowym. Ale też powstały dlatego, że takie programy jak Program Operacyjny Polska Cyfrowa podczas oceny wniosków o dofinansowanie badały i premiowały tworzenie zbiorów danych referencyjnych.

 

Przykładami takich zbiorów referencyjnych są:

• REGON – Krajowy Rejestr Urzędowy Podmiotów Gospodarki Narodowej,
• ŹRÓDŁO – aplikacja do obsługi Systemu Rejestrów Państwowych,
• TERYT – Krajowy Rejestr Urzędowy Podziału Terytorialnego Kraju,
• cała rodzina zbiorów w obszarze danych przestrzennych.

Zatem analizując przepływy danych pomiędzy aplikacjami, musimy mieć na uwadze zarówno przepływy między wewnętrznymi obszarami dziedzinowymi w organizacji, jak i wymianę danych z systemami zewnętrznymi. Zaplanowanie i zbudowanie architektury całego systemu IT organizacji, który zapewnia poprawne przepływy danych, jest dzisiaj dużym wyzwaniem, szczególnie dla jednostek publicznych.

 

Interfejs API

Na rynku komercyjnym jest wiele przykładów wymiany danych pomiędzy systemami. Wymiana danych odgrywa kluczową rolę i pozwala odnieść sukces na rynku.
Najlepszymi przykładami są:

• Google,
• Facebook,
• Apple,
• Twitter.

Te systemy udostępniły publicznie zadziwiające rozwiązania technologiczne, powodując transformację istniejących firm i stworzenie nowych branż. Kluczową rolę w sukcesie odegrały właśnie interfejsy API (API, ang. application programming interface, interfejs programistyczny aplikacji, interfejsy wymiany danych). Wiążą one użytkowników i ich urządzenia przetwarzające z bazowymi platformami.

Podobnym przykładem są firmy kurierskie. Podstawą ich działalności są interfejsy wymiany danych. Pozwalają one zautomatyzować zamówienia usługi kurierskiej dla dużych platform sprzedażowych. Każdy dzień bez działającego API dla firmy z branży transportowej oznacza duże i wymierne straty.

 

Taka sama potrzeba automatyzacji procesów pojawiła się i jest dostrzegana w administracji publicznej. Jednak wdrożenie skutecznego modelu wymiany danych, zarówno wewnątrz organizacji, jak i z podmiotami zewnętrznymi, nie jest łatwe do realizacji.

 

Od strony technologicznej wdrożenie modelu danych nie jest aż tak skomplikowane, jakby się mogło wydawać. W tym obszarze możemy wyróżnić dwa główne modele:

1.  Wdrożenie komercyjnego oprogramowania zwanego szyną danych
   Szyna danych to zestaw narzędzi do publikacji różnych API. Pozwala dodatkowo zarządzać przepływającymi przez nią danymi z poszczególnych API. Zarządzając przepływem danych poprzez szynę, możemy łączyć, konwertować czy też przeliczać dane, które przekazujemy z jednego interfejsu do drugiego. Takie rozwiązania komercyjne są drogie i wymagają zespołu administratorów, który potrafi zarządzać takim środowiskiem.
2. Wykorzystanie oprogramowania typu open source
   Tutaj mamy z kolei do dyspozycji zestaw różnego typu narzędzi. Najpierw musimy je samodzielnie zintegrować, by tworzyły całe i spójne rozwiązanie do wymiany danych. Zaletą tego modelu jest natomiast brak kosztów pozyskania oprogramowania.

 

Niezależnie od modelu wdrożenia narzędzi do wymiany danych pomiędzy poszczególnymi systemami IT jest jeden element, który jest wspólny dla obu rozwiązań. Chodzi tu o coś, co nazywamy „SOA Governace”. Ten element jest właśnie obecnie niedocenionym obszarem wdrożenia systemów IT w administracji publicznej, a jednocześnie jest kluczem do prawidłowego funkcjonowania całej architektury aplikacyjnej w organizacji.  

 

Co to jest SOA Governance?

SOA Governance (ang. service-oriented architecture governance, zarządzanie architekturą zorientowaną na usługi) to tak naprawdę zespół ludzi, który tworzy komitet. W jego skład wchodzą osoby na wysokim szczeblu decyzyjnym oraz architekci aplikacji. Prawidłowe funkcjonowanie takiego zespołu jest dostrzegane dopiero w dłuższym czasie. Dlatego brak takiego zespołu nie jest od razu problemem dla organizacji. Jednak z każdym rokiem staje się coraz bardziej uciążliwy – w miarę wzrostu powiązań między poszczególnymi systemami IT wewnątrz organizacji oraz z systemami zewnętrznymi.

SOA Governance podejmuje kluczowe decyzje dotyczące modelu danych, jaki będzie funkcjonował w aplikacji. To ten zespół powinien, uwzględniając decyzję, czy zostanie kupiony system zintegrowany, czy też odrębne systemy merytoryczne dla poszczególnych obszarów funkcjonalnych, zbudować model danych i zdefiniować zakresy przepływu danych między systemami. Oznacza to, że przedstawiciele zespołu powinni wiedzieć:

• gdzie są dane referencyjne z danego obszaru merytorycznego, 
• czy i jak są udostępnione,
• jak z nich skorzystać, aby nie powielać tych samych informacji gromadzonych w różnych aplikacjach w ramach organizacji. 

Tego typu analizę przeprowadza architekt systemu. Natomiast osoby decyzyjne sankcjonują odpowiednie relacje w modelu danych w organizacji.

Podstawowym narzędziem w ich pracy jest rejestr usług, który organizacja musi prowadzić.

 

Zbudowanie dobrego modelu danych w organizacji i sprawne zarządzanie przepływem danych między systemami IT pozwoli tworzyć poprawne interfejsy API. A w przyszłości – skutecznie modyfikować poszczególne elementy składające się na architekturę aplikacji w całej organizacji.

 

Budowanie modelu przepływu danych pomiędzy aplikacjami można porównać do łączenia różnych elementów za pomocą sznurka. Jeżeli poszczególne połączenia dobrze zaplanujemy, powstanie mocna sieć. Jeżeli jednak nie zaplanujemy połączeń i będą one przypadkowe, może powstać jeden duży supeł, którego w przyszłości nie damy rady rozplątać.

W kolejnym artykule przyjrzymy się bliżej zagadnieniom związanym z wyborem architektury opartej na wielu dziedzinowych aplikacjach lub kupionym systemie zintegrowanym. Zajmiemy się też architekturą samej szyny danych jako miejsca wymiany informacji między aplikacjami. Zapraszamy do jego lektury.

 

Autor: Wojciech Ciesielski

 

Artykuły powiązane: