POPC Wsparcie

Wykorzystanie API (Application Programming Interface) w jednostkach publicznych nie jest dzisiaj powszechne. Warto jednak podkreślić, że podmioty publiczne coraz częściej się nim interesują, ponieważ ta technologia dotyczy projektów realizowanych w ramach POPC (Program Operacyjny Polska Cyfrowa) 2014-2020. Każdy projekt, którego jednym z produktów jest aplikacja, musi udostępniać API. Dzięki niemu można udostępnić dane publiczne gromadzone w systemie. Takie podejście do projektów nie pozwala „rozwinąć” potencjału API, choć jest ważnym krokiem na przód.

W przeciwieństwie do rynku usług publicznych na rynku komercyjnym „siła” jest wykorzystywana powszechnie. Giganci branży IT korzystają z interfejsów API we wszystkich możliwych obszarach. Technologia wymiany danych między systemami sprawdza się nie tylko w relacji firma – partner, ale też w organizacji. Często zdarza się, że właśnie wykorzystanie API w organizacji znacząco optymalizuje procesy wewnętrzne. Przykładem, gdzie API ma kluczowe znaczenie dla funkcjonowania firmy, głównie w relacjach z klientami, są firmy logistyczne. Dzisiaj trudno sobie wyobrazić, że duży sklep internetowy nie wykorzystuje API firmy kurierskiej do transportu produktów do klientów. To właśnie dzięki API firm kurierskich zdecydowana większość firm handlowych może automatycznie wysyłać towary.

Natomiast jednostki, które realizują zadania publiczne, coraz częściej prowadzą politykę otwartego urzędu. Udostępniają w przestrzeni publicznej zgromadzone w rejestrach publicznych dane. Już nie tylko jako pliki .pdf bez warstwy tekstowej, ale przede wszystkim jako źródła danych. Można je wykorzystać w innych systemach informatycznych. Takie działania są bardzo cenne i powinny być podstawowym wymogiem wobec każdego urzędu. Oczywiście taki sposób wykorzystania API to tylko jeden z możliwych scenariuszy.

Dlaczego jednostki publiczne nie korzystają z API?

Wykorzystanie API oznacza nowe możliwości. Osoby mające wpływ na informatyzację podmiotu publicznego często wdrażają nowe rozwiązania, które obejmują coraz więcej procesów w organizacji. Nowe rozwiązania bazują na „zintegrowanym” oprogramowaniu, które de facto jest jednym dużym systemem, składającym się wielu funkcjonalności. Wtedy dane między modułami są wymieniane bezpośrednio poprzez tabele bazy danych. O ile systemy zintegrowane mogą w sposób realny poprawić, tzn. zoptymalizować procesy w organizacji, o tyle ich dalszy rozwój i utrzymanie stają się coraz trudniejsze. To wynika przede wszystkim z konieczności stałej współpracy z wykonawcą systemu, nawet mimo nabycia praw autorskich do kodów źródłowych systemu. Oczywiście prawa autorskie do kodów pozwalają uzyskać lepszą cenę w kolejnym postępowaniu na utrzymanie rozwiązania, jednak realne wykorzystanie kodów przez osoby niebędące ich twórcami jest bardzo trudne. Dlatego zdarza się, że firma, która wygrała przetarg, stara się przejąć od konkurencji osoby, które ten kod źródłowy tworzyły. To oczywiście powoduje wzrost ceny nowej oferty.

System zintegrowany ma kłopot z rozwojem swoich poszczególnych części. Często system oferowany przez podmioty konkurencyjne a dotyczący jednego z obszarów funkcjonalnych systemu zintegrowanego, np. kadry i płace, ma dużo więcej udogodnień dla użytkownika niż te dostępne w systemie zintegrowanym. Wynika to z różnicy czasu, na jaki producent oprogramowania może zaangażować swój zespół programistów w dany obszar merytoryczny. Zazwyczaj temu poświęcony element oferuje większą funkcjonalność niż element, który jest częścią większego rozwiązania.

Optymalizacja kosztów utrzymania i rozwój systemów zintegrowanych

W tej sprawie z pomocą przychodzi API. To właśnie powszechne wykorzystanie tej technologii w organizacji pozwoli zastosować rozwiązania przeznaczone dla danego obszaru merytorycznego i zachować uniwersalny model wymiany danych między poszczególnymi systemami dziedzinowymi. W efekcie takiej kombinacji: specjalizowane systemy dziedzinowe + wymiana danych poprzez API, a najlepiej szynę danych, otrzymujemy jeden zintegrowany system obejmujący wszystkie procesy w całej organizacji. W takim modelu wymiana poszczególnych komponentów, w miarę upływu czasu czy np. na skutek upadku producenta danego oprogramowania, jest stosunkowa łatwa. Wystarczy podmienić system dziedzinowy na innego producenta i zachować możliwość integracji z innymi systemami przez API. To dla systemu zintegrowanego w tradycyjnym znaczeniu mogłoby zakończyć się paraliżem organizacji, a przynajmniej bardzo kosztownym procesem wymiany całego oprogramowania.

Zastosowanie opisanego modelu, w którym wykorzystuje się powszechnie API w organizacji, niesie ze sobą jedną bardzo istotną zmianę funkcjonowaniu danej jednostki. Musi bowiem powstać w organizacji zespół, który będzie potrafił skutecznie zarządzać interfejsami API. Nie chodzi tu o zarządzanie w rozumieniu technicznym, lecz o umiejętność koordynowania przepływu danych między systemami i wyznaczenie dla każdego strumienia danych systemu referencyjnego. Członkowie zespołu tworzą model danych gromadzonych w organizacji i skutecznie sterują przepływem danych między częściami całego systemu. Zadanie to jest zupełnie nową i niezrozumiałą jeszcze kompetencją, jaka musi pojawić się w jednostkach publicznych. Taki sposób realizacji zadań jest tym trudniejszy do wdrożenia, bo w urzędach funkcjonuje model silosowy realizacji zadań. Opisany model architektury danych wymaga zmiany tego podejścia, co zapewne będzie procesem długotrwałym. Jednak coraz częstsze wdrażanie systemów zintegrowanych w tradycyjnym znaczeniu a potem konieczność ich utrzymania, a w końcu wymiany doprowadzi do zmiany sposobu przetwarzania danych w podmiotach publicznych.

Rozwój systemów informatycznych w jednostkach publicznych prowadzi do coraz szerszego wykorzystywania API. To wynika z konieczności spełnienia kryteriów oceny projektów dofinansowywanych ze środków Unii Europejskiej, a przede wszystkim z potrzeby skutecznej możliwości zarządzania danymi w organizacji.

 

Autor: Wojciech Ciesielski