SAP jest w trakcie poważnych zmian technologicznych, które mają umożliwić mu stawienie czoła wyzwaniom przyszłości. Zmianom technologicznym będzie towarzyszyć zmiana sposobu licencjonowania, choć nie od razu.

SAP nie zamierza bezczynnie czekać, aż Oracle zintegruje własne aplikacje z tymi, które przejął od PeopleSoft i JD Edwards. Zadanie Oracle nie należy wprawdzie do łatwych, bo oprócz integracji funkcjonalnej firma musi poradzić sobie z integracją technologiczną, niemniej, również SAP ma w dziedzinie technologii wiele do zrobienia.

Firma musi dokończyć rozwój platformy integracyjnej NetWeaver, by ułatwić komunikację z systemami innych producentów, wzbogacić ją o warstwę zarządzania procesami biznesowymi, przede wszystkim zaś dokonać zasadniczej dekompozycji środowiska, by ułatwić klientom aktualizację poszczególnych elementów funkcjonalnych bez burzenia porządku w pozostałych aplikacjach.

Ambicje SAP-a idą tak naprawdę jeszcze dalej. Firma chce konkurować z innymi producentami poprzez głębszą integrację z aplikacjami Microsoft Office (komponenty Medocino, o których pisaliśmy w CW 19/2005), a także wspólnie z partnerami rozwijać rozwiązania sprzętowe dedykowane do obsługi jego aplikacji biznesowych.

Zerwać z upgrade'ami

Upgrade to wciąż jeden ze słabych punktów SAP-a, ale - na szczęście dla niego - to również problem wielu jego konkurentów. Dostatecznie trudny proces zmiany wersji aplikacji tworzonych w technologii ABAP został w ostatnich latach dodatkowo utrudniony przez fakt, że nowe moduły aplikacyjne tworzone są głównie w Javie, zaś całe środowisko współpracuje często z serwerem baz danych Microsoft SQL Server, dla którego podstawową technologią jest .Net. Dostawcy aplikacji współpracujących z systemami MySAP reprezentują jeszcze szersze spektrum technologii, dlatego powstanie platformy integracyjnej NetWeaver było dla SAP-a koniecznością.

Sama technologia komunikacyjna - nawet jeśli wsparta interfejsami API pozwalającymi na bezpośrednie odwoływanie się do obiektów biznesowych systemów MySAP - to wciąż jedynie obietnica długich projektów integracyjnych, a nie efektów biznesowych. SAP rozumie to doskonale, dlatego na technologicznej podbudowie NetWeaver zdefiniował architekturę Enterprise Services Architecture (ESA), odpowiadającą "ideologicznie" temu, co IBM nazywa Enterprise Service Bus.

Na razie ustami swojego prezesa SAP zapowiedział, że do końca br. wszystkie aplikacje MySAP będą mogły komunikować się za pośrednictwem NetWeaver. Do końca 2007 r. aplikacje SAP mają zacząć działać zgodnie z ESA, a więc przedstawiać się sobie wzajemnie jako usługi i komunikować się ze sobą za pośrednictwem komunikatów SOAP.

Jeśli SAP dopnie swego, rozwiąże problem integracji aplikacji, a jednocześnie problem zmiany wersji oprogramowania i problem zmiany technologii programistycznej. Poszczególne aplikacje-usługi będzie można modyfikować, rozbudowywać i dzielić na mniejsze komponenty bez zmiany ich zewnętrznej reprezentacji i interfejsów. Oddzielenie aplikacji od ich zewnętrznej reprezentacji pozwoli SAP-owi uwolnić się od kwestii "ABAP czy Java". Dzięki Web Services będzie to równie dobrze .Net, Cobol czy popularny w aplikacjach WWW Python.

Inteligencja w sieci

Architektura ESA została dobrze przyjęta przez środowisko dostawców IT - przede wszystkim dlatego, że dostosowanie do niej rozwiązań daje szanse na zbyt wśród rzeszy klientów SAP liczących ok. 25 tys. dużych i średnich firm. Licencje na zastosowanie ESA zakupili od SAP-a m.in. Computer Associates, Mercury (d. Mercury Interactive) oraz (na razie oddzielne) Symantec i Veritas Software. Ich zainteresowanie na wczesnym etapie jest oczywiste - aplikacje tworzone zgodnie z nową architekturą trzeba będzie testować (Mercury), zarządzać nimi (CA), a także zabezpieczać je i ich środowisko (Symantec/Veritas).

Co ciekawe, licencje na wykorzystanie ESA zakupiły od SAP-a także: Cisco EMC, Intel i Network Appliance, które chcą zaoferować swoim klientom rozwiązania sprzętowe potrafiące aktywnie współpracować z warstwą aplikacyjną. Takie rozwiązania oferuje już np. Fujitsu-Siemens Computers - dedykowana dla MySAP Business Suite samoczynnie skalująca się platforma sprzętowa oparta na serwerach kasetowych zwana FlexFrame. SAP-owi również zależy, by takich rozwiązań było więcej.

Zainteresowanie architekturą ESA ze strony Cisco nie jest przypadkowe. Wraz z przekształceniem monolitycznych aplikacji w luźno powiązane usługi rośnie rola bezpiecznej i efektywnej komunikacji między nimi, a to dla Cisco tereny znajome. Ponadto Cisco przymierza się do wejścia na rynek routerów i akceleratorów XML oraz rozwiązań zwanych zaporami aplikacyjnymi. Firma pracuje nad własnym rozwiązaniem w tej dziedzinie o kodowej nazwie Aeon, co jednak nie wyklucza przejęcia jednej z firm specjalizujących się w tej dziedzinie. Pisaliśmy o tym szerzej w CW nr 15/2005.

EMC i Network Appliance zamierzają wykorzystać współpracę z SAP do zaoferowania rozwiązań, które wplotą zarządzanie cyklem życia informacji w procesy biznesowe - zwłaszcza w kontekście zgodności z wymogami ustawy Sarbanes-Oxley, ale można sobie łatwo wyobrazić, że nie tylko. W dobie, gdy informatyka staje się przedmiotem analizy procesowej, jest opisywana i standaryzowana, połączenie wysiłków wyjdzie wszystkim na dobre.

EMC ma z pewnością także inne interesy z SAP-em. Polem współpracy na pewno jest zarządzanie danymi transakcyjnymi (oferowane przez EMC oprogramowanie do wykonywania kopii zapasowych i bieżących kopii migawkowych na różne potrzeby, m.in. analizy danych i raportowania), a także zarządzanie dokumentami (należąca do EMC firma Documentum). Nie można wykluczyć, że EMC i SAP zacieśnią współpracę w dziedzinie wirtualizacji zasobów (VMware). Wirtualizacja wygląda także na przedmiot zainteresowania Intela. Być może jednak Intel jest zainteresowany rozwijaniem nowej niszy, która mogłaby być zdefiniowana jako rynek platform dedykowanych do określonych zastosowań aplikacyjnych.

Kierunek na procesy

Rozwijając i licencjonując partnerom architekturę ESA, SAP nie pozostawia wątpliwości, że na tym nie poprzestanie. Kolejnym etapem rozwoju jego platformy ma być umożliwienie partnerom i klientom odwoływanie się nie tylko do obiektów biznesowych (których już obecnie firma zdefiniowała tysiące), lecz do całych procesów biznesowych. Zewnętrzne aplikacje CRM będą więc mogły wykorzystywać działające w ramach MySAP procesy obsługi zamówień czy planowania produkcji do realizacji własnych, złożonych funkcji, np. w algorytmach wyliczających przewidywany czas oczekiwania na realizację zamówienia itp.

Realizacja takiej śmiałej wizji, którą SAP nazywa Business Process Platform, wymaga wszechstronnego przygotowania technologicznego i narzędziowego. SAP zamierza oprzeć się na otwartych narzędziach zgodnych z Eclipse, ale nie zamierza rezygnować ze wsparcia ze strony narzędziowego dorobku Microsoftu czy narzędzi IBM WebSphere Studio. Wątpliwe jednak, by SAP zrezygnował z rozwijania własnej platformy do uruchamiania reguł biznesowych zgodnych ze specyfikacją BPL4WS.

Platformy do zarządzania reguł będą już wkrótce punktami kontroli aplikacji i SAP nie może sobie pozwolić na uzależnienie od BizTalk Server, WebSphere Process Choreographer czy rozwiązań BEA Systems, co nie znaczy, że nie będzie z nimi współpracować. Najważniejszy argument za rozwojem własnej platformy to jednak fakt, że Oracle dysponuje własnym motorem reguł przejętym wiosną ub.r. wraz z firmą Collaxa.