Osobiście zastanawiam się nad “rynkowym” pojęciem “chmurki”, bo to nie takie “nowe rozwiązanie”. Dla mnie owa chmura (oportunista jednak jestem) to znane od dawna, komponentowe, obiektowe systemy, projektowane obiektowymi metodami zorientowanymi na tak zwany kontrakt (obiekt lub komponent świadczy określone usługi wystawiając stosowny, udokumentowany interfejs).

Cloud computing, to moim zdaniem kolejny rynkowy buzzword. Metodą tą, świadczenie usług zdalnego przetwarzania poprzez udostępnione  interfejsy, od lat pracuje poprzez sieć wiele rodzajów oprogramowania OpenSource,  a także komercyjnego. Przeciętny CMS (Content Management System, ang. System zarządzania treścią, są to programy używane do zarządzania zaawansowanymi serwisami WWW) czy blog (odmiana CMS) potrafi użyć, automatycznie zainstalować (użyć) plug-in (wtyczka rozszerzająca możliwości) do zrealizowania nowej funkcjonalności, lokalnie lub zdalne (np. popularne od lat systemy tworzenia statystyk ruchu dla stron WWW). Z punktu widzenia samej aplikacji nie ma znaczenia czy kod realizujący daną funkcjonalność jest uruchamiany lokalnie czy poprzez sieć (to cecha systemów o obiektowej konstrukcji).

Cloud computing (źr. WIKI)

Uogólniając (diagram powyżej, źr. WIKI), poszczególne wymagane funkcjonalności realizowane przez oprogramowanie mogą być zlecane innym pakietom oprogramowania, jeżeli te tylko udostępniają stosowny interfejs. Nic nie stoi więc na przeszkodzie by np. pakiet SaleForce wysyłał dane ze sprzedaży do zaksięgowania do pakietu Microsoft DynamixXL i pobierał dane do wyliczenia prowizji dla sprzedawców. Takich połączeń można zbudować więcej jeśli tylko te pakiety oprogramowana będą otwarte na taką współpracę (interfejsy). Taki sposób pracy jest wykorzystywany od lat w wielu rozwiązaniach opensource.

Wygląda więc na to, że cloud computing to kolejny przykład komercyjnej adaptacji pomysłów środowisk opensource’owych, które jako społeczności skazane są na pracę rozproszoną i taka architektura niejako musiała powstać.

Moim zdaniem każdy, chcący liczyć się na rynku dostawca ERP, w zasadzie musi się z tym pogodzić lub wypadnie z rynku. Najpierw rynek zmusił dostawców ERP do udostępnianie interfejsów integracyjnych, tak zwanych API (ang. application progamming interfejs) , choć nadal są oportuniści wśród dostawców tych systemów. Teraz pora pogodzić się z tym, że powstają (będą) komponenty rozszerzające funkcjonalności podstawowych wersji ERP a koszt udostępnienia API (licencjonowanie) będzie spadał. Możliwości udostępniane przez te API od pewnego czasu pozwalają już na budowanie “chmur”.

Osobiście widzę to tak, że w przyszłości będą na rynku systemy z podstawowymi modułami wymaganymi przepisami zbudowanymi wokół podstawowego modułu finansowego (chodzi o księgowanie kontowe). Do tego będą opcjonalne “plug-iny” typu magazyn, produkcja, kontaktmanager itp. i tu będzie na rynku konkurencja. Wykształci się rynek firm specjalizujących się we wdrażaniu konkretnych ERP i konkretnych “plug-in’ów”. Jest bardzo prawdopodobne, że interfejsy API ulegną pewnej standaryzacji i wiele komponentów będzie współpracowało z wieloma systemi ERP. Uważam, że producent ERP, który nie otworzy się na świat z dobrze udokumentowanym API z czasem rynkowo umrze.

Jeżeli miał bym coś polecić tym, którzy patrzą na cloud computing jak na potencjalne narzędzie uzyskania przewagi konkurencyjnej, to sugeruję po zanalizowaniu potrzeb i wyspecyfikowaniu wymagań, dokonanie oceny  które wymagane funkcjonalności są biznesowo ryzykowne, ocenę na ile można je zdobyć na rynku w postaci usług innych aplikacji. W zasadzie jest to model SaaS (Software as a Service) ale tu mamy do czynienia z dedykowanymi usługami a nie kompletnym, zdalnie używanym oprogramowaniem.

W poprzedniej epoce firmy wiązały się na wiele lat z jednym dostawcą systemów IT, rozprzestrzeniając wybrane systemy w całej organizacji, czego efektem było często powstanie trudno zarządzalnej, sztywnej infrastruktury, w niewielkim stopniu podatnej na zmiany. Analitycy Gartnera są zdania, że rozpoczęła się epoka projektów, które trzeba będzie rozpoczynać bez znajomości wszystkich wymagań użytkownika, aby nie spóźnić się na rynek z nowym produktem i wykorzystać sposobną chwilę, która może się nie powtórzyć. Przed nami epoka systemów, które budowane są z myślą o ich ustawicznych modyfikacjach w odpowiedzi na zmieniającą się sytuację rynkową.” (źr. Gartner/ERPStandart)

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).