Platforma Integracji Aplikacji

Rekomendacja zmiany architektury

Wersja 1.2
Nr ref. IN/0410-2/05/MST/1052
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

Historia Zmian
Data Wersja Opis Autor
19.01.2005 1.0 Wersja początkowa - szkic Marek Stawny
Witold Jarzynka
5.05.2005 1.1 Zmiany po zakończeniu ewaluacji
Marek Stawny
Uzupełnienie danych,
5.05.2005 1.1.1 podsumowanie rekomendacji i Witold Jarzynka
streszczenie dla kierownictwa
Witold Jarzynka,
11.05.2005 1.2 Wersja ostateczna
Marek Stawny

Projekt PIA ©Izba Skarbowa w Szczecinie, ii

2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

Spis Treści
1. Streszczenie dla kierownictwa 4

2. Kryteria rekomendacji zmiany architektury 6

2.1 Spełnienie wymagań przez platformę 6
2.2 Kryteria oceny platformy systemowej i dodatkowych narzędzi dostarczanych przez firmy, pod
kątem zastosowania dla systemu PIA 7

3. Opcje zmiany architektury 8

3.1 Obecna architektura PIA (opcja 1) 9
3.2 Lokalny serwer J2EE w każdym US (opcja 2) 9
3.3 Platforma systemowa (opcja 3) 10

4. Przebieg ewaluacji zmiany architektury PIA 11

5. Analiza porównawcza 13

6. Rekomendacje 14

7. Załączniki 14

Projekt PIA ©Izba Skarbowa w Szczecinie, iii

2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

Rekomendacja zmiany architektury

1. Streszczenie dla kierownictwa
Wdrożenie Platformy Integracji Aplikacji (PIA), której zadaniem jest integrowanie systemów
POLTAX w urzędach skarbowych z systemami funkcjonującymi w centrali tj.: VIES oraz
SERCE, napotyka na bariery wynikające z ograniczeń zasobów oraz przyjętą architekturę
systemu, ściśle związaną z aktualnym środowiskiem urzędów skarbowych.
Wzrastające zaangażowanie Zespołu na rzecz bieżącego administrowania usługami Platformy
Integracji Aplikacji, w szczególności w 400 lokalizacjach - serwery POLTAX, wyjaśniania
sytuacji merytorycznie niepoprawnych oraz udziale w innych projektach i pracach bieżących
Izby Skarbowej, zmniejsza możliwości realizacji zadań związanych z integracją nowych funkcji
systemów lub reagowaniem na nowe wymagania/potrzeby. Dodatkową motywacją do zmiany
aktualnej architektury jest kontekst przedsięwzięcia e-Podatki, w którym usługi Platformy
Integracji stanowią jądro proponowanego rozwiązania.

Po dogłębnej analizie możliwych scenariuszy zmiany aktualnej sytuacji i przeprowadzeniu

ewaluacji możliwości zastosowania produktów wybranych firm, które dostarczają platformy
(framework), zawierające gotowe zestawy narzędzi/aplikacji/podsystemów tworzących
środowisko do integracji aplikacji (EAI), Zespół rekomenduje opcję zakupu wyspecyfikowanych
produktów firmowej platformy integracyjnej (zobacz punkt 6 – rekomendacje) z usługami asysty
technicznej i niezbędnymi szkoleniami dla administratorów i programistów oraz przeniesienie
wdrożonych usług integracji systemów VIES i POLTAX oraz SERCE na nową architekturę.

Korzyści z podjęcia takiej decyzji są następujące:

• wyeliminowanie konieczności utrzymywania i pielęgnacji stworzonych mechanizmów,

co umożliwi skupienie się na głównym celu projektu tj. integracji aplikacji POLTAX,
VIES i SERCE przy użyciu standardowych, niezawodnych i wydajnych mechanizmów
platformy systemowej dostarczanej przez firmę zewnętrzną – producenta, zwiększając
szanse na sukces w założonych terminach,

• zwiększenie pewności działania i usprawnienie administrowania usługami platformy

integracyjnej, wykorzystującego kompleksowe monitorowanie i zarządzanie całą
infrastrukturą oraz automatyzację rutynowych czynności, co umożliwia planowanie i
ocenę poziomu świadczonych usług integracji,

• większy potencjał rozwojowy architektury opartej o platformę integracyjną dostarczaną

przez firmę-producenta, głównie w zakresie przyszłych potrzeb np. przedsięwzięcie
e-Podatki, integracja z innymi systemami referencyjnymi oraz systemem bankowym,
nowe wyzwania związane z projektami Komisji Europejskiej np. VIES 2, co umożliwia
szybszy dostęp do zintegrowanej informacji zarządczej,

• Umożliwienie elastycznego dostosowywania infrastruktury platformy integracyjnej oraz

logiki jej działania do zmieniających się potrzeb w zakresie obsługi procesów

Projekt PIA ©Izba Skarbowa w Szczecinie, 4/15

2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

biznesowych, wynikających ze zmian prawnych, organizacyjnych lub uwarunkowań

zewnętrznych, przez zastosowanie modelowania procesów1 i ich realizację w
standardowym środowisku wykonawczym.

W ocenie Zespołu ryzyko niepowodzenia jest minimalne, z uwagi na możliwość przeniesienia

zaimplementowanych komponentów PIA do nowego środowiska, co zweryfikowano w procesie
ewaluacji, wysoką niezawodność oraz wydajność oferowanych produktów. Przeprowadzona
analiza potwierdziła, że rekomendowane produkty spełniają wyspecyfikowane wymagania
funkcjonalne, niezawodnościowe i wydajnościowe.

Koszty zakupu licencji na wyspecyfikowane komponenty, sprzętu oraz usług wdrożeniowych i

wsparcia technicznego szacuje się na ok. 10 mln zł [wg załącznika 6]. Przeniesienie na nową
architekturę wykona Zespół rozwijający dotychczasowy system PIA.

1
język BPEL
Projekt PIA ©Izba Skarbowa w Szczecinie, 5/15
2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

2. Kryteria rekomendacji zmiany architektury

Rozdział ten specyfikuje kryteria, pogrupowane wg rodzajów, które zostały przyjęte przez
Zespół do ewaluacji wybranych platform systemowych (platform integracyjnych EAI
oferowanych przez wiodące firmy). Szczegółowa specyfikacja wymagań, udostępniona
wszystkim uczestnikom procesu ewaluacji, została opisana w załączniku 1.

2.1 Spełnienie wymagań przez platformę

1) Wymagania podstawowe
a) Platforma musi umożliwiać automatyczne przesyłanie danych z jednej aplikacji do
wybranych aplikacji.
b) Asynchroniczna integracja
c) Transformacje struktur danych
d) Gwarancja realizacji przesłania danych
e) Określanie pory przesyłania danych
f) Zachowanie kolejności przesyłanych danych
g) Rejestrowanie historii przesyłanych danych / komunikatów
h) Przesyłanie dużych ilości danych
i) Czas przesyłania danych
j) Bezpieczeństwo przesyłanych danych
k) Automatyczna obsługa różnych scenariuszy wymiany danych między aplikacjami
l) Priorytety danych
2) Wymagania na funkcje administracyjne
a) Scentralizowane administrowanie
b) Możliwość administrowania z sieci publicznej
c) Możliwość administrowania z WAN MF
d) Konsola administratora PIA
e) Logowanie do podsystemu zarządzania
f) Rozliczalność działań administratora.
g) Sprawdzanie i informowanie o dostępności
h) Informowanie o przyczynie niepowodzenia pobrania danych z aplikacji źródłowej
i) Informowanie o przyczynie niepowodzenia propagacji danych
j) Informowanie o przyczynie niepowodzenia integracji danych w aplikacji docelowej
k) Informacje administracyjne muszą być sygnowane rzetelnym znacznikiem czasu
l) Alarmowanie administratora
m) Alarmowanie administratora kanałem rezerwowym
n) Możliwość przeglądania komunikatu, którego nie udało się zintegrować
o) Wielokrotne dostarczanie danych na żądanie administratora
p) Możliwość tworzenia raportów (w tym wydruków) o różnym przekroju informacyjnym
q) Odtwarzalność systemu po awarii
r) Archiwizacja
3) Niezawodność
a) Dostępność Systemu 96.2%
b) Wyłączenia w celu utrzymania systemu nie częściej niż 1 dzień/miesiąc
Projekt PIA ©Izba Skarbowa w Szczecinie, 6/15
2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

c) Maksymalny czas awarii Systemu

d) Maksymalny czas przestoju Systemu 12 godzin
e) Minimalny czas między awariami Systemu 24 godziny
f) Całkowita skuteczność integracji danych
g) Całkowita odtwarzalność danych oraz stanu Systemu sprzed awarii
h) Maksymalna liczba błędów oprogramowania Systemu 10e-8 błędów/żądań integracji.
4) Wydajność
a) Obsługa jednoczesnych żądań integracji o wolumenie 100KB danych/integrację
generowanych z 400 Rejestrów Lokalnych POLTAX do systemu VIES
b) Obsługa maksymalnego wolumenu 65000 żądań integracji/dzień z CRP do POLTAX
c) Średni czas integracji danych z CRP do POLTAX poniżej 60 sekund
d) Maksymalne obciążenie Systemu 400 żądań integracji/sekundę przez 5 kolejnych sekund
e) Maksymalny czas odpowiedzi Systemu na zlecenie Administratora Systemu 7 sekund

2.2 Kryteria oceny platformy systemowej i dodatkowych narzędzi dostarczanych przez firmy, pod
kątem zastosowania dla systemu PIA
1) Spełnienie wymagań funkcjonalnych PIA (wymagania podstawowe, wymagania na funkcje
administracyjne). Zawarcie pełnej wymaganej funkcjonalności PIA na platformie
systemowej, z wykorzystaniem jej mechanizmów, narzędzi i możliwości utworzenia
odpowiedniego software’u przy ich pomocy
2) Spełnienie wymagań niefunkcjonalnych PIA (wydajność, niezawodność)
3) Wykorzystanie określonych rozwiązań funkcjonujących obecnie
a) Wykorzystanie mechanizmu generującego żądania integracji
b) Wykorzystanie istniejących klas pobierających i zapisujących dane (adaptery)
4) Wdrożenie – przedstawienie strategii przejścia na nową architekturę i możliwych scenariuszy
wdrożenia (w warunkach funkcjonującej integracji POLTAX-VIES). Przewidywany czas
wdrożenia.
5) Przewidywany czas potrzebny na przeniesienie istniejącej funkcjonalności systemu PIA na
nową platformę (napisanie software’u, konfiguracja platformy i używanych narzędzi, testy)
6) Ocena wsparcia developera platformy przez dostarczone narzędzia (pracochłonność, czas
tworzenia, wydajność), np. automatyzacja tworzenia mechanizmów dostępu do relacyjnej
bazy danych, kreatory takich komponentów jak EJB, JSP, serwlety, pliki XML, generowanie
web-serwisów, routing jms.
7) Gotowe narzędzia administracyjne dostarczane wraz z platformą. Zarządzanie z jednego
miejsca platformą integracyjną w środowisku rozproszonym, zarządzanie infrastrukturą,
administracja procesem, monitorowanie. Zapewnienie funkcjonalności obecnej aplikacji
administratora, czyli m.in. monitorowanie wszystkich lokalizacji z jednej konsoli, status
aplikacji lokalnych, włączanie/wyłączanie wysyłania i odbierania, pobieranie logów, zdalny
upgrade, w centrali przeglądanie błędnych komunikatów, ponawianie integracji, statystyki.
8) Możliwość modelowania procesów biznesowych oraz generowania z takich modeli
fragmentów szkieletu kodu aplikacji, a także sposób opisu procesów biznesowych.
Modelowanie reguł biznesowych za pomocą BPEL; możliwość automatycznego przejścia
między modelami np. UML/BPEL.
9) Możliwość zamodelowania logiki integracji danych (dziś logiki zawartej w adapterach PIA)
10) Łatwość utrzymywania funkcjonującego systemu: wprowadzanie zmian w każdym z etapów
Projekt PIA ©Izba Skarbowa w Szczecinie, 7/15
2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

tworzenia systemu - od modelu biznesowego do kodu, dodawanie lub usuwanie usług

(nowych funkcji) w systemie
11) Rekomendacja architektury, zaproponowanie konfiguracji produkcyjnej; przedstawienie
szacowanych kosztów
12) Testowanie - strategia, metoda, automatyzacja, możliwość weryfikacji działania systemu w
czasie jego tworzenia (debugging), integracja narzędzi testowych z narzędziami
deweloperskimi
13) Możliwość dalszego wykorzystywania narzędzi Rational, jako środowiska analityczno-
projektowego i testowego (Rational Rose, Test Manager)
14) Operational Data Storage - wsparcie dla budowania wiedzy biznesowej na bazie procesów
integracyjnych, obsługiwanych przez platformę integracyjną.
15) Potencjał platformy dla przyszłych integracji z kolejnymi systemami (inne systemy centralne
MF, e-Podatki, wsparcie dla aplikacji klasy enterprise np. HR, ERP)
16) Bezpieczeństwo (oparte o PKI) - biblioteki krypto , podpis itp. jako potencjalne możliwości
wykorzystania do przyszłych potrzeb

3. Opcje zmiany architektury

Rozdział ten opisuje wybrane przez Zespół opcje możliwości zmiany architektury Platformy
Integracji Aplikacji, wynikające z doświadczeń z rozwoju i utrzymania aktualnej architektury
PIA. Rozważane są 3 opcje (zobacz tabela).

Tabela. Opcje zmiany architektury PIA.

Zakres zmian Wariant 1 Wariant 2 Wariant 3
Opcja 1 Pozostawienie aktualnej n.d. n.d. n.d.
architektury – ścisłe
powiązanie z serwerem
systemu POLTAX
Opcja 2 Lokalny serwer J2EE w Dodanie serwera Dodanie serwera Dodanie serwera
każdym US – luźne aplikacji aplikacji i bazy aplikacji, bazy
powiązanie z serwerem danych danych oraz
systemu POLTAX zmiana message
brokera
Opcja 3 Zakup platformy Platforma Platforma Platforma
systemowej (integracyjnej) systemowa w systemowa w systemowa w
oraz przeniesienie logiki na centrali centrali, lokalne centrali, lokalne
architekturę tej platformy serwery aplikacji serwery BPEL

Projekt PIA ©Izba Skarbowa w Szczecinie, 8/15

2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

3.1 Obecna architektura PIA (opcja 1)

Opcja taka zakłada integrację innych systemów Ministerstwa Finansów za pomocą obecnie
działającej Platformy Integracji Aplikacji. Szczegółowy opis architektury tej platformy znajduje
się w załączniku [2], punkt 1.1.

3.2 Lokalny serwer J2EE w każdym US (opcja 2)

Obecna architektura systemu PIA po stronie Urzędu Skarbowego rodzi wiele problemów i
znacznie obciąża lokalny system operacyjny i bazę danych. W przypadku integracji kolejnych
systemów poza VIES obciążenie to znacznie by wzrosło.

Jednym z rozwiązań zmiany obecnej architektury byłoby postawienie w każdym z urzędów

serwera aplikacji, na którym działałaby aplikacja lokalna PIA czy inne aplikacje stojące poza
systemem POLTAX a z nim współpracujące. Z uwagi na obecną technologię PIA (Java) serwer
taki musiałby spełniać standard J2EE, aby możliwe było łatwe przejście z obecnej aplikacji
lokalnej (J2SE) na aplikację działającą na serwerze J2EE. Serwery aplikacji spełniające ten
standard są oferowane przez wielu producentów oprogramowania a raz napisany kod może być
uruchomiony na dowolnym z nich zmieniając jedynie parametry konfiguracyjne.

Do każdego Urzędu Skarbowego musiałby być zakupiony nowy serwer lub mógłby być
wykorzystany inny np. Serwer Aplikacji Podatkowych. Konfiguracja sprzętowa centrali
pozostaje bez zmian.

1) Dodanie tylko serwera aplikacji

W takim przypadku w dalszym ciągu system PIA używałby tej samej bazy danych co system
POLTAX. System komunikatów AQ pozostaje bez zmian. Dodatkowo do bazy danych
zapisywane by były kolejki używane przez serwer aplikacji (jest to konieczne ze wzglądów
bezpieczeństwa i spójności danych). Na serwerze aplikacji umiejscowiona byłaby aplikacja
lokalna PIA napisana w technologii J2EE, oraz inne dowolne działające w tej technologii. Być
może konieczne byłoby również użycie mostu między kolejkami AQ, a kolejkami serwera
jeśli byłby on innej firmy niż Oracle.

2) Dodanie serwera aplikacji i oddzielnej bazy danych na potrzeby PIA

Wybranie takiej konfiguracji całkowicie odciążyłoby lokalny system podatkowy POLTAX. Baza
danych może być umiejscowiona na tym samym serwerze co serwer aplikacji. Jako bazę danych
można zainstalować wydajniejszą wersję np. Oracle 9i. W bazie danych przechowywane by były
obiekty systemu komunikatów jak i systemu PIA czy innych. Problemem będzie dodatkowa
administracja, oprócz administracji bazą danych POLTAX.

3) Dodanie serwera aplikacji , bazy danych i zmiana obecnego message brokera

Dodatkowo można zmienić cały system obsługi komunikatów z obecnego Oracle Advanced
Queuing na inny. Wiązałoby się to jednak z dużymi zmianami w kodzie i administracji aplikacji
Projekt PIA ©Izba Skarbowa w Szczecinie, 9/15
2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

centralnej i lokalnych PIA. Być może było by to jednak konieczne w zależności od wyboru
konkretnego serwera aplikacji.

Rekomendowanym rozwiązaniem, w ramach tej opcji, byłoby postawienie serwera aplikacji

wraz z oddzielną bazą danych obok systemu POLTAX. Serwer aplikacji powinien być
dostarczany z zestawem narzędzi administracyjnych i wsparciem technicznym. Opcja zmiany
systemu komunikatów nie jest rekomendowana w tym wariancie.

3.3 Platforma systemowa (opcja 3)

Opcja ta zakłada, że zostanie zakupiona rekomendowana platforma systemowa, która spełnia

wyspecyfikowane wymagania funkcjonalne, administracyjne, niezawodnościowe oraz
wydajnościowe, co umożliwi przeniesienie zaimplementowanej przez Zespół logiki integracji
systemów POLTAX, VIES i SERCE na nową architekturę. Głównym celem tej opcji jest
przeniesienie ciężaru prac z utrzymania zaimplementowanych w aktualnej architekturze PIA
mechanizmów, wykorzystywanych do integracji aplikacji, na analizę/modelowanie procesów
i implementację logiki przy użyciu dostarczonych „z pudełka„ mechanizmów platformy
systemowej.

Dodatkowym, bardzo ważnym argumentem jest to, że administrowanie aktualną architekturą jest
bardzo pracochłonne, co wynika m.in. z ograniczeń specjalizowanych narzędzi, stworzonych
przez Zespół na potrzeby tego projektu, oraz ograniczeń w zasobach. Przystępując do ewaluacji
wskazano na efektywność administrowania platformą systemową jako na jedno z
najważniejszych kryteriów oceny.

Do ewaluacji wybrano 4 firmy2, oferujące swoje produkty, które wspierają centralny model
integracji (hub and spoke), jako najpełniej odpowiadający strukturze procesów biznesowych w
administracji skarbowej. Ograniczenie liczby ewaluowanych produktów wynikało również z
możliwości przeprowadzenia takiej ewaluacji przez Zespół oraz z doświadczeń administracji
skarbowej w dotychczasowych kontaktach z tymi firmami (wdrożenia).

W przypadku zastosowania platformy systemowej możliwe są 3 warianty architektury. Każdy z

tych wariantów zakłada instalację na silnym serwerze w centrali platformy systemowej która
będzie integrowała i przetwarzała większość danych z różnych systemów (obecnie POLTAX,
VIES i SERCE). Warianty różnią się rozwiązaniem lokalnym przy systemie POLTAX w
urzędach skarbowych.

1) Platforma systemowa w centrali

Wariant rekomendowany przez firmy: IBM, Software AG. Lokalny styk platformy z
integrowaną aplikacją POLTAX w Urzędzie Skarbowym, jest zrealizowany za pomocą prostej
aplikacji (tzw. adaptera), która zajmowała by się tylko pobieraniem lub integrowaniem
odpowiednich danych w lokalnym systemie. Do tej funkcji można wykorzystać również obecnie
działającą Aplikację Lokalną PIA, jednakże nie jest to rozwiązanie rekomendowane ze względu

2
Firma Software AG, 6 maja 2005 wycofała się z ewaluacji. Produkt oferowany przez tą firmę nie był brany pod uwagę w
ostatecznej rekomendacji.
Projekt PIA ©Izba Skarbowa w Szczecinie, 10/15
2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

na aktualne problemy i niedogodności występujące z tą aplikacją (patrz załącznik [2])

2) Platforma systemowa w centrali, lokalny serwer aplikacji

Wariant rekomendowany przez firmę Oracle. Wariant ten jest połączeniem opcji zmiany
architektury opisanej w punkcie 3.2 wraz z przejściem centrali na platformę systemową.
Aplikacja integrująca system POLTAX byłaby aplikacją J2EE posadowiona na lokalnym
serwerze aplikacji. Występują wtedy podobne korzyści jak i problemy lokalne co opisane
wcześniej odnośnie tej opcji.

3) Platforma systemowa w centrali, lokalne serwery platformy integracyjnej wraz z BPEL/BPM

Wariant taki jest rekomendowany przez firmę BEA. Polega on na postawieniu obok serwera
POLTAX, serwera platformy systemowej, podobnego do serwera centralnego. Część
przetwarzania danych może odbywać się wtedy lokalnie, i być zamodelowana jako proces
biznesowy, co jest zaletą takiego rozwiązania, jednakże (w przypadku platform pozostałych
trzech firm) łączy się ze spadkiem wydajności i bardzo dużymi kosztami dodatkowymi.

Rekomendowanym przez zespół PIA rozwiązaniem w ramach tej opcji, a także jako rozwiązanie
docelowe dla całego systemu PIA, jest wybór platformy systemowej tylko w centrali,
przetwarzanie wymienianych przez integrowane systemy danych centralnie, natomiast lokalnie
posługiwanie się adapterami integracyjnymi, bez konieczności używania lokalnego serwera
aplikacji czy serwera platformy integracyjnej (wariant 1).

4. Przebieg ewaluacji zmiany architektury PIA

Ewaluacja dotyczyła produktów następujących firm:

• Bea Systems – prezentowanych przez partnera firmę Software Mind Sp. z o.o.,

• IBM – prezentowanych przez pracowników firmy,

• Oracle – prezentowanych przez pracowników firmy,

• Software AG – prezentowanych przez pracowników firmy.

Poza prezentacją ogólnych cech rekomendowanej architektury, 3 firmy przeprowadziły

prezentację działającej architektury, a 2 firmy dodatkowo warsztaty, dotyczące wykorzystania
narzędzi platformy i proces developmentu aplikacji wykorzystującej podobne mechanizmy co
PIA. Zakres czynności zrealizowanych w ramach ewaluacji platform systemowych pokazano w
poniższej tabeli. Czas trwania ewaluacji wyniósł 3 miesiące (luty-kwiecień br.).

Każda firma przygotowała opracowanie (załączniki 3, 4, 5, 6, 7, 8, 9), odnoszące się do

specyfikacji wymagań oraz ustalonych w czasie ewaluacji pytań uzupełniających (w formie
odrębnego dokumentu albo korespondencji e-mail’owej).

Projekt PIA ©Izba Skarbowa w Szczecinie, 11/15

2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

Tabela. Zakres czynności zrealizowanych w ramach ewaluacji platform systemowych.

BEA IBM Oracle Software
AG
Prezentacja najważniejszych cech produktu, Tak Tak Tak Tak
ze szczególnym uwzględnieniem funkcji
wymienionych jako kryteria oceny
Przeprowadzenie warsztatów pokazujących Tak Nie Tak Nie
wykorzystanie narzędzi platformy i proces
developmentu aplikacji wykorzystującej
podobne mechanizmy co PIA
Uruchomienie systemu z podobną Tak Tak Tak Nie
funkcjonalnością jaką posiada system PIA,
wykorzystującego niezbędne istniejące
mechanizmy i klasy
Przeprowadzenie testów wydajnościowych Tak Nie Nie Nie
prezentowanego systemu
Przedstawienie raportu z ewaluacji, Tak Tak Tak Tak
zawierającego stopień realizacji
przedstawionych wymagań.

Projekt PIA ©Izba Skarbowa w Szczecinie, 12/15

2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

5. Analiza porównawcza
Na podstawie opisanych kryteriów oceniono rekomendowane przez firmy rozwiązania zmiany architektury. Ocenę przeprowadzono
wyłącznie kierując się dostarczoną przez firmy dokumentacją [załączniki 3, 4, 5, 6, 7, 8, 9] oraz informacjami uzupełniającymi, po
serii pytań dodatkowych. Porównanie nie obejmowało oceny konkretnych produktów i ich wszystkich możliwości, jedynie
zastosowanie ich dla Platformy Integracji Aplikacji jako systemu z ustaloną funkcjonalnością a także wykorzystanie ich zgodnie z
modelem rozwoju systemów stosowanym w Ministerstwie Finansów. W poniższej tabeli zestawiono wyniki analizy porównawczej.

Tabela. Wyniki analizy porównawczej.

Kryterium Waga Obecna Lokalny BEA IBM Oracle Software AG
kryterium architektura serwer
PIA aplikacji
Wymagania podstawowe PIA 10 8 8 10 10 10 6
Wymagania na funkcje administracyjne 10 3 1 6 10 10 2
Wymagania na niezawodność 10 6 5 10 10 10 6
Wymagania na wydajność 7 6 6 10 10 10 6
Wykorzystanie niezbędnych istniejących 8 10 10 10 10 10 10
rozwiązań PIA
Strategia wdrożenia 5 9 9 6 6 6 7
Czas przeniesienia funkcjonalności 5 10 8 5 5 5 7
Wsparcie developera platformy 4 4 5 8 9 8 6
Gotowe narzędzia administracyjne 5 4 2 2 9 7 1
Modelowanie procesów biznesowych 3 1 1 5 9 8 2
Modelowanie logiki integracji danych 1 2 2 5 5 5 1
Utrzymywanie funkcjonującego systemu 5 4 4 7 9 9 5
Architektura i konfiguracja 5 4 6 7 10 8 4
Koszty architektury 5 9 5 4 2 1
Testowanie 6 5 5 5 8 5 5
Wykorzystanie narzędzi Rational 3 10 10 0 10 0 0
Operational Data Storage 2 0 0 3 10 10 0
Potencjał dla przyszłych integracji 10 1 5 9 10 10 6
Bezpieczeństwo 2 1 4 8 10 10 1
WYNIK 585 575 759 941 861 505

Projekt PIA ©Izba Skarbowa w Szczecinie, 2005 13/15

Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

6. Wynik ewaluacji i rekomendacje

W wyniku przeprowadzonej analizy porównawczej, oceniającej wszystkie przedstawione opcje
zmian architektury, biorąc pod uwagę stan aktualny oraz zadania, które stoją przed administracją
skarbową, a są w związku z potrzebą integracji architektury systemu informacyjnego
administracji skarbowej, Zespół rekomenduje opcję 3, wariant 1 – tj. zakup platformy
systemowej. Najwyżej oceniona została platforma firmy IBM, składająca się z komponentów,
dla platformy sprzętowej xSeries, opisanych w rozdziale 3.10 załącznika 5. Jeżeli strategia
informatyzacji ewoluowała by, w kierunku dalszej centralizacji systemu, Zespół rekomenduje
wybór ścieżki na platformie zSeries, opisanej w rozdziale 3.11 załącznika 5.

Najwyższą wagę, Zespół w swojej ocenie, przywiązywał do spełnienia wyspecyfikowanych

wymagań, potencjału platformy, rozumianego jako możliwości realizacji celu integracji
wszystkich aplikacji w ramach administracji skarbowej, tworzącej wartość dodaną – informację
zarządczą, a jednocześnie elastycznej w zakresie aktualnej i przyszłej organizacji procesów
biznesowych.

Następnie, istotne dla Zespołu jest wykorzystanie efektów wykonanej pracy, aby skrócić czas
wdrożenia oraz zminimalizować ryzyko niepowodzeń, przez wsparcie narzędziami procesu
testowania i administracji platformą. Jako ważne cechy uznano, architekturę oraz koszty jej
wdrożenia.

Mniejszą wagę przywiązano do możliwości wsparcia developerów oraz przesunięcia ciężaru

pracy w stronę modelowania procesów i automatyzacji implementacji logiki tych procesów, co
daje ewidentne korzyści, ale w dłuższej perspektywie, w zakresie dostosowywania systemu
(utrzymanie) do zmian wymagań, co ma również wpływ na całkowite koszty posiadania (TCO)
danego rozwiązania. Również mniejszą wagę przywiązano do wsparcia bezpieczeństwa systemu
przez mechanizmy oparte o usługi PKI (waga tego elementu może w przyszłości wzrastać) oraz
do współpracy z gotowymi produktami w zakresie analiz biznesowych, co również może
w przyszłości nabierać większego znaczenia.

7. Załączniki

1. Platforma Integracji Aplikacji - Specyfikacja wymagań na ewaluację platform

integracyjnych, wersja 3.0. Plik Specyfikacja wymagań.doc
2. Platforma Integracji Aplikacji – Obecna architektura, wersja 1.0.
Plik PIA – obecna architektura.doc
3. BEA Systems & Software Mind - Raport z ewaluacji platformy integracyjnej, wersja 1.2.
Plik AN-005_raport_z_ewaluacji_platformy_integracyjnej_v_finalna.doc
4. BEA Systems & Software Mind – Uzupełnienie raportu.
Plik BEA – uzupełnienie.doc
5. IBM - Studium przedprojektowe Platformy Integracji Aplikacji, wersja 2.
Plik StudiumFINALwysylka.doc
6. IBM - Studium przedprojektowe Platformy Integracji Aplikacji, wersja 1.
Projekt PIA ©Izba Skarbowa w Szczecinie, 14/15
2005
Platforma Integracji Aplikacji Wersja: 1.2
Rekomendacja zmiany architektury Data: 11.05.2005
PIA Rekomendacja zmiany architektury 1.2.doc

Plik Studium_przedprojektowe_PIA_uzupełnienie_v1_0.doc
7. Oracle - Wczesny prototyp platformy integracyjnej, wersja 1.0.
Plik MOF_POC.doc
8. Oracle - Wczesny prototyp platformy integracyjnej, wersja 1.0.
Plik Odpowiedz na dodatkowe pytania dotyczace wczesnego prototypu platformy
integracyjnej-1.doc
9. Software AG - PIA dla Izby Skarbowej w Szczecinie Opis platformy integracyjnej,
wersja 1.0.
Plik PIA_Izba_Skarbowa_Szczecin_v1.0.pdf

Projekt PIA ©Izba Skarbowa w Szczecinie, 15/15

2005