Przyszłość to podejście zorientowane na usługi

 Na pytania redakcji MSI Polska odpowiada Rob Levy, wiceprezes i dyrektor ds. technicznych BEA Systems

Jaką strategię będzie realizować BEA Systems w najbliższych latach w Europie?

– BEA Systems to firma o zasięgu globalnym, zatem na wszystkich rynkach, na których jesteśmy obecni, realizujemy podobną strategię w zakresie sprzedaży, rozwijania współpracy z partnerami czy usług doradczych. Dbamy o lokalizację naszych produktów i dostosowanie ich do wymagań poszczególnych rynków.

Rynki europejskie mają swoją specyfikę i określone potrzeby, dlatego BEA Systems musi dostosowywać strategię współpracy z partnerami i integratorami. Na przykład niektórzy francuscy klienci cenią współpracę z globalnymi firmami doradczymi, jak Accenture, natomiast przedsiębiorstwa z innych krajów często wolą korzystać z usług lokalnych integratorów, powiązanych w swego rodzaju ekosystemie z lokalnymi dostawcami. Zamierzamy zatem rozwijać współpracę z lokalnymi partnerami i, choć sami świadczymy usługi konsultingowe, nie chcemy być globalnym integratorem.

Jaką politykę stosuje BEA Systems, przejmując inne firmy i rozwiązania?

– Przede wszystkim stale opracowujemy plany dotyczące rozwoju nie tyle produktów, co technologii. Dzięki pracy naszych rynkowych specjalistów wiemy, czego mogą w przyszłości oczekiwać klienci, a zatem na czym powinniśmy skupić nasze wysiłki. Następnie oceniamy, czy określone rozwiązania możemy opracować we własnym zakresie, tworząc lub modyfikując aktualną ofertę, czy też warto przyspieszyć rozwój poprzez przejęcia innych firm.

Wówczas trzeba wziąć pod uwagę dwa czynniki: po pierwsze, czy rozwiązanie, którym dysponuje inny podmiot rzeczywiście przybliży nas do założonych celów rozwojowych, a po drugie, czy cudze rozwiązanie będzie można zintegrować z naszymi. Nietrudno kupić kilka nowych technologii, problemem jest zintegrowanie ich ze swoją ofertą, a także zaadaptowanie we własnej firmie nowych pracowników i odmiennej kultury pracy.

Co skłoniło firmę do wejścia na polski rynek?

– BEA Systems pojawia się wszędzie tam, gdzie istnieje popyt na jej rozwiązania. Pod tym względem polski rynek nie różni się wcale od francuskiego czy amerykańskiego. Skoro polskie firmy potrzebują rozwiązań wykorzystujących architekturę SOA (Service- Oriented Architecture), dzięki którym działalność można prowadzić sprawniej i efektywniej, to naturalnie chcemy być obecni w Polsce.

Natomiast dostrzegam pewną tendencję dotyczącą globalnego rynku rozwiązań opartych na architekturze SOA. Tempo wzrostu ich popularności nie zależy w zasadzie od położenia geograficznego, jak w przypadku telefonii GSM, ale od charakteru konkretnych sektorów gospodarki, przy czym najszybciej rynek ten rozwija się w branży finansowej i telekomunikacyjnej.

Cechą charakterystyczną tego rodzaju rozwiązania jest możliwość zastosowania go w firmie dowolnej wielkości, także takiej, której działalność wykracza poza granice narodowe. Dzięki naszym produktom firmy na całym świecie mogą liczyć na elastyczne dostosowanie informatyki do potrzeb biznesu.

Które rozwiązania cieszą się w Polsce największą popularnością?

– Kiedy BEA Systems wprowadziło na rynek rozwiązania objęte nazwą AquaLogic, ogłosiło także zaadaptowanie w globalnej ofercie modelu SOA. Trzy oparte na tym modelu produkty mają w Polsce wielu użytkowników. Popularny jest zarówno system transakcyjny BEA Tuxedo, umożliwiający łączenie klientów aplikacji z serwerami, WebLogic Server, dzięki któremu programiści tworzą aplikacje w środowisku Java, jak i rozwiązanie AquaLogic optymalizujące procesy biznesowe pod kątem architektury SOA. 

Jaką strategię BEA Systems proponuje firmom w zakresie rozwiązań opartych na architekturze SOA?

– W sektorze produkcyjnym często spotyka się przedsiębiorstwa, których systemy informatyczne wdrożono wiele lat temu. Są to zazwyczaj ogromne projekty, których opracowanie i implementacja była tak poważnym przedsięwzięciem, że po uruchomieniu nikt nie ma ochoty na modernizację.

Problemem w wielu takich przedsiębiorstwach jest podejście polegające na traktowaniu systemu IT jako całości. „Jeżeli mamy coś wymieniać, to od razu cały system”. Takie podejście sprawdzało się w przypadku systemów ERP, CRM i przyczyniło się do sukcesów takich gigantów, jak Oracle czy SAP. Niektórzy klienci woleli kupić gotowy pakiet aplikacji i zainstalować go w miejsce starego systemu.

Istnieje jednak spora liczba firm, które np. z powodu specyfiki swoich branż nie mogą wykonać takiego posunięcia. Im właśnie architektura SOA umożliwia podejście komponentowe. Polega ono na tym, że zamiast wymieniać całą aplikację, wystarczy wyodrębnić z niej określone funkcje, dokładnie je zdefiniować i enkapsulować [czyli obudować – przyp. red.] w formie usług (tzw. Web services). Następnie programiści projektujący warstwę Web services wykorzystają zdefiniowane usługi, które będą realizować te same funkcje co dotychczasowa aplikacja. W efekcie kolejne składniki starej aplikacji przestaną być używane, ponieważ zastąpią je nowe. Może się też zdarzyć, że zamiast tworzyć usługę, firma zleci realizację określonych funkcji zewnętrznym podmiotom w ramach outsourcingu lub kupi gotowe rozwiązanie. W ten sposób postępuje się np. z systemami CRM i ERP na całym świecie.

Z biegiem czasu większa część kodu dotychczasowej aplikacji przestanie być używana, np. będzie się wykorzystywać zaledwie 20% jej kodu. W tej sytuacji dyrektor ds. IT może podjąć decyzję o gruntownej, jednorazowej wymianie dotychczasowego systemu, ponieważ nie będzie to już rewolucja w sensie fi nansowym.

Rosnąca popularność modelu SOA na rynku globalnym wynika właśnie z przyjęcia opisanego podejścia. Coraz więcej firm w ten sposób „dekomponuje” swoje systemy informatyczne, optymalizując przy tym procesy biznesowe.

W jakich według pana obszarach SOA jest najbardziej popularne?

– Gdyby to ode mnie zależało, w branżowym terminie Service- Oriented Architecture zamieniłbym słowo architecture na approach. Mówilibyśmy wówczas wprost o podejściu zorientowanym na usługi, nie o samej architekturze, która jest określeniem technicznym i z tego powodu nie odzwierciedla faktu, że SOA odnosi się także do sposobu zarządzania przedsiębiorstwem i jego organizacji.

Właśnie w obszarze styku z odbiorcami obserwujemy największy wzrost popularności rozwiązań SOA. Wynika to prawdopodobnie z faktu, że na powodzenie implementacji tej techniki wpływają takie czynniki, jak konieczność szybkiego dostosowywania aplikacji oraz duża ilość informacji zwrotnych, jakich programiści potrzebują od użytkowników.

Jaką strategię przyjęła firma BEA Systems w odniesieniu do BPM?

– Istnieje kilka koncepcji BPM. Po pierwsze, Business Process Modelling oznacza projektowanie czy modelowanie procesów biznesowych. Szefowie firmy muszą jasno określić, jakie działania ma ona realizować, a następnie dzięki BPM mogą zdefiniować odpowiednie procesy. W innym rozumieniu BPM ogranicza się do roli mechanizmu zarządzającego procesami – Business Process Management.

W marcu 2006 r. przejęliśmy m.in. firmę Fuego i obecnie jej produkty wchodzą w skład szybko rozrastającej się serii BEA AquaLogic. Fuego dysponowała ogromną wiedzą w zakresie obu wymienionych tradycyjnych koncepcji BPM. W naszym podejściu bierzemy pod uwagę także sposób współdziałania projektantów architektury informatycznej z organizacją biznesową nie tylko podczas modelowania czy realizowania procesów biznesowych, ale i wtedy, gdy wprowadza się modyfi kacje.

Na warsztacie mamy więc takie koncepcje, jak Web 2.0 czy współpraca użytkowników w ramach sieci. Do tradycyjnych rozwiązań BPM dodajemy zatem, oprócz funkcji budowania portali i łączenia ich z procesami biznesowymi, swego rodzaju przestrzeń roboczą dla programistów i projektantów. Ma ona służyć wymianie koncepcji informatycznych, aby można było dostosować rozwiązania do potrzeb biznesu, np. pod kątem wymagań SLA (dla informatyków tak samo ważnych jak dla menedżerów wskaźniki KPI). Jeśli zatem decydent z poziomu biznesu postanawia zmienić istniejący model procesów biznesowych, wówczas do głosu dochodzą architekci z poziomu informatyki i tworzą nowe rozwiązania. W naszym podejściu nie chodzi zatem o samo narzędzie do modelowania procesów, ale o możliwość jego modyfi kowania w swoistym cyklu informatyczno- biznesowym.

Nasza koncepcja skupia się nie tyle na rozwiązaniach dla poszczególnych sektorów gospodarki, ile na integracji modelowanych procesów z użyciem jednej metody czy jednego repozytorium metadanych, które będą obsługiwać wszystkie procesy.  

Jak ocenia pan przyszłość outsourcingu?

– Z punktu widzenia outsourcingu architektura SOA jest o tyle szczególna, że teoretycznie projektanci nie muszą wiedzieć, gdzie są realizowane jakieś usługi. Mogą pochodzić z działającej aplikacji, ze świeżo napisanej aplikacji lub z aplikacji opracowanej przez zewnętrzny podmiot. Stąd już prosta droga do outsourcingu czy do wytworzenia się grupy firm – providerów usług.

Wydaje mi się, że w przyszłości projektant systemu będzie mógł wybierać między aplikacjami z kilku źródeł: z repozytorium znajdującego się w obrębie firmy lub z udostępnionego firmie repozytorium należącego do zewnętrznego podmiotu. Warto zauważyć propozycje takich providerów, jak Amazon. com, Google czy Yahoo, zamierzających odpłatnie udostępniać innym firmom usługi, które do tej pory wykorzystywano tylko w obrębie własnych systemów IT. Pojawią się zapewne także niszowi dostawcy usług, np. w zakresie produkcji czy finansów, którzy będą działali podobnie jak providerzy aplikacji, udostępniając konkretne usługi.

Dzięki takiej dywersyfikacji dyrektorzy działów IT będą mogli dobierać usługi, bazując na bardzo konkurencyjnej ofercie rynku i kierując się zarówno wymogami SLA, jak i ceną. Ujawniają się tu zalety architektury SOA, czyli wysoki stopień integracji usług, które wcale nie muszą znajdować się w jednym miejscu. Zamiana konkretnej usługi realizowanej wewnątrz firmy na usługę udostępnianą przez zewnętrzny podmiot sprowadza się do przekształcenia modelu BPM.

BEA Systems ma w ofercie również rozwiązania RFID…

– Technologię RFID rozpatrywałbym w dwóch ujęciach. W pierwszym z nich RFID to technika zarządzania danymi m.in. za pośrednictwem chipów i czytników. Za zadanie postawiliśmy sobie obsługiwanie zdarzeń RFID w środowisku Java. Dzięki jego popularności nasi klienci, do których zaliczają się czytelnicy MSI Polska, mogą tworzyć własne aplikacje z wykorzystaniem systemów RFID i przede wszystkim w sposób bardziej opłacalny integrować je z innymi systemami informatycznymi przedsiębiorstwa.

W drugim ujęciu technologię RFID traktuję jako przykład systemu czytników na granicy między dostawcą a odbiorcą, między firmą a klientem. Z taką sytuacją mamy do czynienia np. w przypadku elektrowni, które instalują czytniki energii u odbiorców, czy też ośrodków medycznych, które dają pacjentom aparaty do pomiaru tętna i umożliwiają zdalne skierowanie do szpitala w razie wystąpienia dolegliwości. Są to zatem systemy czytników, które przesyłają informacje o zdarzeniach do systemów zaplecza. Dane te są następnie przetwarzane w środowisku Java tak samo jak dane z dowolnych innych systemów czujników.

Jaką przyszłość wróży pan informatykom?

– Niewątpliwie zmienia się nasze podejście do sposobu tworzenia rozwiązań IT. Na przykład użytkownicy często nie kontaktują się już z działem obsługi klienta firm software’owych, ale bezpośrednio z programistami, którzy na bieżąco pracują nad konkretnymi rozwiązaniami. Do tej pory zazwyczaj dostawca oprogramowania badał potrzeby klienta, opracowywał aplikację i przekazywał ją klientowi. Sądzę, że w ciągu najbliższych pięciu lat takie podejście zaniknie.

Na jakiej podstawie tworzy się plany marketingowe w Amazon.com? Badając postawy kupujących. To od ich zachowań zależy, jakie towary będą sprzedawane. Na podobnej zasadzie funkcjonuje koncepcja Web 2.0 i jej specyficzne podejście do komunikacji między użytkownikami. Moim zdaniem w ciągu trzech – pięciu lat w podobny sposób zmieni się podejście do sposobu tworzenia aplikacji. Użytkownicy będą stale zaangażowani w proces opracowywania oprogramowania, czyli zamiast pisać i udostępniać użytkownikom gotowe aplikacje, będziemy stale wspierani przez użytkowników w ciągłym procesie tworzenia oprogramowania. Innymi słowy, w wyniku połączenia idei Web 2.0 z architekturą SOA otrzymamy koncepcję, którą mógłbym określić jako Enterprise 2.0.

Autor: Elżbieta Jaworska, MSI Polska