Dostawcy aplikacji nadal nie godzą się na współudział w kosztach integracji. Natomiast coraz częściej decydują się na to dostawcy usług. W ten sposób mogą oni nie tylko zapewnić sobie wzrost przychodów z usług doradczych, ale także zwiększyć przychody generowane przez sprzedaż oprogramowania. Przykładem może być program pod nazwą Virtual Development oferowany przez Computer Sciences Corporation (CSC) dla firm z branży ubezpieczeniowej. Klienci firmy otrzymują kopię kodu źródłowego oprogramowania, mogą go więc dowolnie modyfikować. Oczywiście, przy pomocy konsultantów CSC. Ponadto firma godzi się na włączenie wszystkich zmian do kolejnej wersji oprogramowania, zmniejszając tym samym obciążenia, które w tradycyjnym modelu spadałyby na klienta. Użytkownik nie musi więc dokonywać kastomizacji aplikacji, za każdym razem kiedy decyduje się dokonać upgrade'u oprogramowania. Z drugiej strony, wprowadzając zmiany w kolejnych wersjach, CSC tworzy pakiet, który ma szansę stać się branżowym standardem (lub puszką Pandory, jeśli nie będzie właściwie zarządzany). Niemniej klienci nie są nadmiernie zależni od CSC, ponieważ dzięki posiadaniu kodu źródłowego mogą zacząć korzystać z usług innego dostawcy.

Posiadając ogromną przewagę na polu usług i outsourcingu, IBM mógłby popisać się hat trickiem, gdyby zdecydował się przejąć producenta oprogramowania, takiego jak Siebel Systems czy Oracle. Pozwoliłoby to Big Blue na oferowanie pakietów składających się z aplikacji, gwarantowanych usług integracyjnych i aktualizacyjnych. Osobną kwestią pozostaje problem wyrażenia zgody na taką transakcję przez urzędy antymonopolowe.

Jeśli jednak faktycznie by do tego doszło, dostawcy "czystego" oprogramowania - np. Microsoft czy SAP - znaleźliby się w bardzo trudnej sytuacji.

Koniec innowacji

Jak wyglądałaby branża, gdyby w 2009 r. IBM przejął Siebel Systems, a rok później część Oracle'a zajmującą się aplikacjami (po tym jak ruch open source zniszczył rynek baz danych)? Jak wyglądałaby branża, gdyby nieco wcześniej HP przejął EDS, próbując dotrzymać kroku IBM?

Oczywiście, byłaby to tylko konsolidacja na dużą skalę. Nie rozwiązałoby to problemu integracji. Oznaczałoby to, że producenci oprogramowania i dostawcy usług nie działają już na oddzielnych rynkach. Wyraźna linia podziału pomiędzy oprogramowaniem a usługami uległaby zatarciu. Jednak czy dostawcy usług, którzy mają w swojej ofercie dużą liczbę aplikacji, dostrzegliby korzyści płynące z posiadania uniwersalnego zestawu technologii integracyjnych? Prawdopodobnie nie.

Nierozwiązane problemy dotyczące integracji i złożoności systemów IT będą napędzać konsolidację. Więksi będą pożerać małych w nadziei na stworzenie oferty, która będzie odpowiedzią na wszystkie problemy informatyczne przedsiębiorstwa. Hiperkonsolidacja najprawdopodobniej nie położy kresu nadmiernej złożoności IT, jednak pozwoli ukryć ją w cieniu wielkich dinozaurów.

Odbije się to z pewnością na innowacyjności. Kiedy szef działu informatyki zdecyduje się związać z dostawcą usług, który dodatkowo oferuje stabilne aplikacje, mniejszym firmom będzie znacznie trudniej umówić się choćby na spotkanie. Spektakularna klapa dotcomów nauczyła ich, że inwestowanie w dobre pomysły ze słabymi wynikami finansowymi prowadzi do sporych kłopotów. Podobnie inwestorzy stali się bardziej ostrożni w pompowaniu pieniędzy w przedsięwzięcia, które zawierają słowo "technologia" w biznesplanie. Wydaje się, że w 2010 r. garstka firm informatycznych będzie kontrolować ponad 70% budżetów IT największych przedsiębiorstw na świecie.

Mali dostawcy będą mieli szansę na kontrakty wyłącznie w małych przedsiębiorstwach. Niemniej tam właśnie będzie można dostrzec innowacje. Mali dostawcy będą zadowoleni, że udaje im się uszczknąć kawałek rynku, którym nie interesują się duzi. Będą wypożyczać swoje oprogramowanie za pośrednictwem Internetu za niewielkie, miesięczne opłaty. Ani dostawca, ani klient nie będą musieli nadmiernie głowić się nad integracją.

Strach się bać

Hiperkonsolidacja nie niesie wiele dobrego dla szefów działów informatyki. Zredukowanie liczby strategicznych decyzji, jakie będą podejmować, ograniczy ich rolę w organizacji. Zmniejszenie liczby dostawców odbierze przynajmniej część władzy i strategicznej kontroli, którą posiadają obecnie.

Rosnąca rola outsourcingu będzie oznaczać panowanie modelu, w którym wiedza strategiczna i planowanie dotyczące wykorzystywanych technologii będą się znajdować na zewnątrz organizacji.

Dyrektorzy wykonawczy i finansowi zaczną zastanawiać się, czy przypadkiem nie są w stanie samodzielnie spotkać się z kilkoma wielkimi dostawcami, zamiast wykorzystywać w tym celu pośrednika - szefa działu IT. Argumenty o utrzymywaniu związków z wieloma dostawcami, żeby uniknąć całkowitej zależności od jednego, przestaną skutkować.

Brak uniwersalnej technologii integracyjnej, która pozwoliłaby na realną konkurencję na rynku oprogramowania, sprawia, że nie ma większej różnicy, czy płaci się stopniowo rosnące opłaty kilku dostawcom, czy oddaje się wszystko jednemu.

W takich warunkach jedyną bronią szefa działu informatyki w walce o niższe ceny i warunki kontraktów zostanie tylko open source. Z tego punktu widzenia konieczne jest przeznaczanie niewielkich porcji budżetu na pilotowe projekty open source wewnątrz organizacji. Choćby tylko po to, żeby zbudować skuteczne narzędzie negocjacyjne. Ponadto niskobudżetowe projekty z pewnością nie spotkają się z krytyką dyrektorów finansowych i wykonawczych. Nadchodzi koniec czasów, w których szef działu informatyki nie ma zielonego pojęcia, ile kodu open source jest wykorzystywane w jego organizacji.

(Na podstawie miesięcznika CIO opr. raj)