Dane niestrukturalne stanowią ponad 80% składowanych danych, to oznacza, że model relacyjny pozwala opisać i przetwarzać tylko ułamek posiadanej informacji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)

Wstęp

W podsumowaniu niedawnego artykułu o NoSQL w chmurze, napisałem:

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmurze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Artykuł sie właśnie ukazał. We wstępie napisałem:

Dokumenty często zawierają dużą ilość różnych danych tworzących wspólnie wiele kontekstowych zbiorów danych (agregatów). Zastosowanie modelu relacyjnego do organizacji takich danych prowadzi do wygenerowania rozbudowanego systemu powiązanych relacyjnie tabel, przy czym usunięcie redundancji często powoduje utratę kontekstu treści poszczególnych pól w tabelach. Rodzi to konieczność stosowania wysoce złożonych zapytań SQL, aby dokumenty te mogły być zapisywane w tej bazie danych i z niej pobierane. W ten sposób sama baza danych zawiera wyłącznie dane pozbawione kontekstu obecnego w tabelach, a nie dokumenty.

Wielu autorów zwracało uwagę na problem złożoności i utraty jednolitego kontekstu modelu relacyjnego (Ślęzak i in., 2018). Autorzy ci sugerowali, że konteksty powinny być separowane w dużych relacyjnych modelach danych. Jednak zalecenie separacji kontekstów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zachowaniu modelu relacyjnego, nie pomaga w całkowitym rozwiązaniu problemu (Awang et al., 2012, 2012, 2012).

Zmiana kontekstu często zmienia znaczenie danych (Danesi, 2004). Podejmowane próby zachowania znaczenia danych często prowadzą do tworzenia rozbudowanych relacyjnych modeli danych, generując tym samym dodatkowe koszty. Dlatego też wykorzystanie jednego relacyjnego modelu danych do zapisu zawartości wielu różnych dokumentów może uczynić z takiego systemu ogromny i niepodzielny monolit, który jest kosztowny zarówno w rozwoju, jak i w utrzymaniu. (Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases)

Biorąc pod uwagę to czym są bazy danych zwane NoSQL, uważam, że należałoby raczej nazywać je “bazami nierelacyjnymi”. Krótkie zestawienie tu: Bazy NoSQL Nowoczesne Rozwiązania do Przechowywania Danych (autor: dr inż. Michał Malinowski). Poniżej kilka wyjasnień.

Rodzaje baz danych NoSQL na rynku

Praktyka pokazuje, że bazy te to odpowiedź na standardowe obecnie wymagania wobec systemów informacyjnych, jakimi są zmienność struktur danych, ich ograniczona strukturalizacja lub nawet jej całkowity brak.

Akronim NoSQL został po raz pierwszy użyty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lekkiej, opensource “relacyjnej” bazy danych, która nie używała SQL. Nazwa ta pojawiła się ponownie w 2009 roku, kiedy Eric Evans i Johan Oskarsson użyli jej do opisania nierelacyjnych baz danych. Relacyjne bazy danych są często określane jako systemy SQL. Termin NoSQL może oznaczać zarówno “Nierelacyjna SQL” lub bardziej popularne tłumaczenie “Nie tylko SQL” (Not only SQL), aby podkreślić fakt, że niektóre systemy mogą obsługiwać języki zapytań podobne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)

Jeden z moim zdaniem ciekawszych artykułów o NoSQL napisał Fowler 10 lat temu [zotpressInText item=”{5085975:7KE6AUNH}”].

Bazy danych ‘key-value’.

Bazy te są najprostszym typem bazy NoSQL. Każdy element (wiersz) w takiej bazie to para klucz i wartość (dane przechowywane), tu zawartość (dane przechowywane) to zawsze “jakiś plik” (podobnie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobrana wyłącznie poprzez odwołanie się do jej identyfikatora (klucza) [zotpressInText item=”{5085975:TLXPTGGP},{5085975:QM5PRS75},{5085975:6Q43W9BI}”]. Bazy te są doskonałe do przechowywania dużych ilości różnorodnych danych, gdzie nie trzeba przetwarzać treści tych danych w samej bazie (np. wyszukiwanie zawartości na podstawie jej określonych cech). Służą one wyłącznie do zachowywania i odzyskiwania plików. Praktycznie jest to płaski system plików.

Dokumentowe bazy danych.

To odmiana bazy key-value. Przechowuje dane w postaci określonej strukturalnej treści: dokumentów (np. JSON czy XML). Struktury te mają swoje definicje, a ich typów może być dowolna liczba. Jedna baza może więc zawierać dokumenty o dowolnie wybranej, określonej strukturze. Dostępne na rynku bazy tego typu maja także bardzo dobre i szybkie motory zapytań, są coraz częściej stosowane jako bazy danych ogólnego przeznaczenia.

Bazy zmieno-kolumnowe

Przechowują dane w postaci agregatów o zmiennych “liściach”. Bazy tego typu zapewniają dużą elastyczność w stosunku do relacyjnych baz danych, ponieważ nie jest wymagane, aby każdy wiersz agregat posiadał tyle samo i te same elementy (kolumny) [zotpressInText item=”{5085975:I9BXAFH4}”]. Bazy tego typu są powszechnie stosowane do przechowywania danych np. danych profilowych użytkowników. Są często opisywane w poniższy sposób:

Jak widać, bazy te przechowują agregaty. Nazwanie agregatu “wierszem” jest niefortunne bo to jednak nie są płaskie tabele, jednak pojęcia wierszy i kolumn zrzucam tu jednak na karb stereotypu zaczerpniętego z modelu relacyjnego.

Grafowe bazy danych.

Przechowują dane w postaci węzłów i krawędzi (asocjacje między węzłami). Węzły zazwyczaj przechowują informacje o obiektach (ludzie, miejsca, przedmioty) krawędzie zaś przechowują informacje o możliwych związkach między węzłami [zotpressInText item=”{5085975:3ESX9EZA}”]. Grafowe bazy danych doskonale sprawdzają się w przypadkach gdy trzeba zapisywać i śledzić związki między obiektami i analizować je, np. sieci społecznościowe czy wykrywanie oszustw. Tak są najczęściej opisywane grafowe bazy danych, a przedstawiane są np. tak:

Uważam, że powyższe to trywialna i naiwna metoda przedstawiania baz tego typu. Istotą systemu przetwarzania informacji jest tu (w takim modelu) jest przechowywanie informacji o obiektach i o faktach je łączących takich jak zdarzenia dotyczące pary obiektów [zotpressInText item=”{5085975:8KSJ8ZGX}”]. Mogą to być typowe fakty, np. Samochód miał kolizje w Mieście, gdzie Samochód i Miasto to węzły, a kolizja to zdarzenie. Ważne jest to, że Samochód i Miasto można opisać określonym cech, sama kolizje także, ważne jest to, że faktów łączących dwa obiekty może być wiele (w czasie).

Związki między obiektami opisywane są też metodą RDF (Resource Description Framework) jako zdania: Subject – Predicate – Object [zotpressInText item=”{5085975:YAPIFWVW}”].

O każdym obiekcie będzie jeden rekord w bazie danych, o każdym fakcie też, ale różnych faktów, których cechami są te obiekty może być wiele (cechą stłuczki jest między innymi miejsce stłuczki i samochód, który miał tę stłuczkę). Cechami obiektów są nazwa, data powstania i ewentualna data usunięcia (zniszczenia), także cechy definiujące takie jak np. kolor, typ czy wydawane dźwięki. Cechami fakty są czas zaistnienia oraz obiekty (ich nazwy), których określony fakt dotyczy. Ważne jest to, że położenie obiektu nie jest jego cechą definiującą. Graf jest definiowany jako nazwane związki między obiektami, są nimi właśnie fakty (a szerzej: predykaty). Warto też zaznaczyć, że w kontekście np. zdarzeń gospodarczych, faktem jest faktura opisująca transakcje do jakiej doszło. Jednak w archiwum dokumentów faktura jest obiektem archiwalnym [zotpressInText item=”{5085975:9KMR85JV}”].

Tak więc bardziej sformalizowana struktura danych w bazie grafowej mogła by wyglądać tak:

Diagram powyższy jest kolorowany dla poprawy czytelności. W tej postaci widać obiekty i łączące je fakty: w bazach grafowych są to formalnie tak zwane związki semantyczne (znaczeniowe), ale jest to jednak duże uproszczenie. Systemy zapisu informacji w postaci trójek: pojęcie-predykat-pojęcie mają szersze uzasadnienie (planuję publikację z wynikami szerszych badań). Metamodel systemu zapisu informacji o obiektach i związkach między nimi wygląda tak:

Warto zauważyć, że zarówno Obiekt jak i Związek semantyczny mogą być przechowywane w bazie dokumentowej lub kolumnowej…

Podsumowanie

To co dzisiaj nazywamy bazami danych NoSQL to tylko naturalne modele informacyjne. Kiedy odkryte? Nie wiem, ale wiem, że w tym wszystkim najbardziej nienaturalny jest model relacyjny. Dlaczego? Bo nie występuje w naturze i sprawia same problemy. Celowo zaprezentowałem sformalizowane diagramy UML dla każdego typu, by pokazać, że NoSQL to tylko i aż modele informacyjne spotykane w rzeczywistości życia człowieka. Konstrukcje jak te wyżej opisane, to tak na prawdę modele informacji wynikające z dziedziny problemu, nie jest tak że są używane z powodu “wynalezienia” baz NoSQL, jest dokładnie odwrotnie.

Obecne bazy NoSQL rozumiane jako “motory baz danych”, to implementacje informacyjnych wzorców projektowych. Diagramy UML powyżej to metamodele tych wzorców.

Na temat baz danych i baz NoSQL polecam kompleksowe opracowanie Joe Celko: Complete guide to NoSQL: what every SQL professional needs to know about nonrelational databases [zotpressInText item=”{5085975:SHIRBPAZ}”].

Polecam też poniższe wystąpienie gdzie Martin Fowler wyjaśnia to na przykładach:

Podsumowanie 2

Pojawiają się tezy że to się nie nadaje do ERP, że nikt tak nie robi… Otóż:

Systemy ERP budowane w oparciu o centralne bazy danych RDBMS ewoluujące do chmury są niejako skazane na bazy NoSQL (znakomita większość chmurowych repozytoriów chmurowych to bazy NoSQL).

Podstawowym problemem systemów zbudowanych w oparciu o bazy RDBMS/SQL jest to, że nie ma w nich dokumentów, a jedynie dane rozłożone w tabelach. Uzyskanie dokumentu (np. faktury) wymaga każdorazowo dynamicznego zebrania danych z wielu tabel, ich złączenia i sformatowania, czyli użycia języka SQL. Dlatego ewolucja nowoczesnych systemów ERP idzie w kierunku systemów, w których funkcje kalkulacyjne oraz dokumenty są rozdzielone, a dokumenty są przechowywane w postaci zmaterializowanej:

Przypominam, że systemy ERP inne o podobnej architekturze, nie przechowują dokumentów, bo dynamicznie generowane treści (raporty SQL, i podobne generowane “w locie” na API) to w świetle prawa nie są dokumenty, i słusznie bo nie istnieją w czasie.

Za trwały nośnik można uznać m.in. dokument papierowy, kartę pamięci, pendrive, wiadomość mailową lub załączony do niej plik, np. w formacie pdf. Samo hiperłącze przekierowujące na stronę internetową nie spełnia wymogów trwałego nośnika, jeżeli tego rodzaju strona internetowa nie spełnia cech trwałego nośnika. (https://uokik.gov.pl/zwrot-i-rekompensata-od-mpay-i-revolut-bank-uab)

Podsumowanie 3

Od dłuższego czasu stosuje w projektach struktury informacyjne nazywane NoSQL. Sa to praktycznie wszystkie opisane wyżej struktury. Projekt dla agencji fotograficznej BE&W (archiwum zdjęć), projekt dla Biura Polonii Kancelarii Senatu (obsługa wniosków o dofinansowanie o zmiennej strukturze), projekt dla Żandarmerii Wojskowej (zarządzanie sprawami dochodzeniowo-śledczymi w całej Polsce), projekt dla KGHM (standaryzacja systemu utrzymania ruchu, zarządzanie infrastrukturą produkcyjną).

Na przykładzie MongoBD

Więcej już niedługo… Zachęcam do zadawania pytań o NoSQL pod tym wpisem.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Swego czasu wpadł mi oczy “nius”:

Tesla Motors CEO Elon Musk decided that the company would build its own business software to run the company. CIO Jay Vijayan and his team built it in just four months. (How Tesla’s Elon Musk Approaches IT – The CIO Report – WSJ).

Nie znam szczegółów, ale domyślam się, że zrezygnowali z “pełnego zintegrowanego pakietu ERP” i to chyba z tego krótkiego tekstu widać.

Od dłuższego czasu nurtuje mnie czym kierują się firmy (ludzie) zawierające umowy na zakup pełnych i zintegrowanych pakietów ERP mimo, że statystyki pokazują, że to z reguły nie ma żadnego sensu.  Praktycznie wszystkie te wdrożenia są po zakończeniu znacznie droższe niż pierwotne oferty, trwają dłużej niż obiecano, nie mała część kończy się fiaskiem i nawet kompletną rezygnacją i odinstalowaniem (bywam w tych firmach i widzę od środka różnicę pomiędzy tym co piszą w gazetach dostawcy w swoich referencjach a tym co faktycznie miało miejsce).

Nie raz o tym tu pisałem więc nie będę się powtarzał.  Popatrzmy na poniższe statystyki:

W Polsce średni koszt wdrożenia projektu na kilkadziesiąt stanowisk (40-80 licencji) wynosi 200-300 tys. dolarów (prawie milion złotych), a projektu dla małej firmy (20-30 licencji) 100-140 tys. dolarów (nieco ponad 400 tys. zł) . Proporcje pomiędzy kosztami sprzętu i oprogramowania utrzymują się na poziomie pół na pół. Najdroższe są usługi konsultingowe, ich koszt sięga 50 proc. kosztów wdrożenia, choć zdarzają się klienci, u których koszty obsługi przez konsultantów nie przekraczają 5 proc. Wówczas klient praktycznie dokonuje wdrożenia własnymi siłami, ze strony dostawcy korzystając głównie z usług szkoleniowych. (Zintegrowane wspomaganie zarządzania przedsiębiorstwem: Przyszłość systemów ERP – Bankier.pl).

Tu mamy koszt ok. 400 tys. zł, czyli jakieś 200 tys. na analizę, projektowanie i wykonanie, to jest możliwe i nie jest to mało. Ostatni taki projekt jaki mam w portfolio trwał tylko pół roku. Różnica jest taka, że za te pieniądze klient nie robił praktycznie żadnych kompromisów (kompromis kastomizacji przy wdrażaniu gotowych dużych pakietów), czas od rozpoczęcia do wdrożenia tylko pół roku! To przykład takiego samego budżetu ale projekt nie był trywialny.

Swego czasu robiłem wyliczenie progowych kosztów opłacalności wytworzenia dedykowanej aplikacji dziedzinowej i wyszło mi, że za 75 tys. (podobno poza Warszawą 50 tys.) już taka może powstać (przy założeniu rzetelnego projektowania a potem dopiero implementacji, wtedy wychodzi za pierwszym razem, mam takie w portfolio). Przy obecnej technologii (frameworki dziedzinowe czyli tak zwane gotowe szkielety)  od dawna już nie piszemy długo i żmudnie kosztownego oprogramowania “od zera” (czym straszą dostawcy gotowego). Dedykowany projekt do dobór właściwych elementów szkieletu, ich konfiguracja, rozwiązywanie wielu problemów poza funkcjonalnych (technicznych), prace programistyczne “wykończeniowe” i serce systemu czyli model jego dziedziny (ok. 3% całości kodu), który faktycznie powstaje “od zera”. Do tego dochodzi coraz większa otwartość na integrację gotowego, dostępnego na rynku oprogramowania realizującego standardowe usługi, takie jak zarządzanie finansami czy magazynami. To się kupuje gotowe i łączy.

Piszę to na początku roku, traktując jako wróżbę, to okres na prognozy więc i ja prognozuję :). Myślę, że postępy w inżynierii oprogramowania, powolne odchodzenie od modelu relacyjnego danych (to wymusza bardzo sztywną integrację) i kolejne projekty pokazujące, że zintegrowany ERP to nie koniecznie “monolityczny” ERP, doprowadzą do “upadku” hegemonii “wielkich dostawców ERP”. Okazuje sie, że można taniej uzyskać takie same, a nie raz lepsze, efekty. Są już pierwsze efekty: dostawcy dużych ERP oferują dość rozbudowane i wygodne interfejsy integracyjne, sami zawierają sojusze z dostawcami osobnych komponentów (lub ich kupują :)). Osobiście nie widzę sensu, by każda zmiana sytuacji biznesowej musiała wymagać wymiany lub modyfikacji całego pakietu ERP, skoro można pojedyncze komponenty.

Koniec roku się zbliża, czas na podsumowania i prognozy :), pierwsze publikacje już są. Co się pisze o ERP:

Monolityczne rozwiązania wspierające zarządzanie to przeszłość. Dziś liczą się: wszechstronność, otwartość na zmiany, prostota obsługi, możliwości integracyjne. Wybór najlepszego systemu ERP staje się coraz trudniejszy. (za Biznes wychodzi z objęć systemu – Computerworld).

Jak osiągnąć “wszechstronność i otwartość na zmiany”? Na początek może małe review moich wcześniejszych tekstów na ten temat:

Przewiduję powolne odchodzenie od idei systemów zintegrowanych. Dotychczasowa ich zaleta czyli pełna integracja przestaje być zaletą a staje się garbem. System zintegrowany można już ?skleić? ze specjalizowanych aplikacji, komponentów. […] Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu “wykroić” koszt wsparcia pojedynczego procesu. (Marzec 2007, Czy to już nadchodzący koniec zintegrowanych ERP?)

Jeżeli dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że ?z kompletu? przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ? ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża). (Listopad 2009 Nigdy więcej ERP w jednym kawałku!).

Jak zacząć? Najpierw analiza tego co i jak robimy. Potem podział tego na obszary standardowe, które obsłużymy narzędziem uniwersalnym i pozostałe, których z reguły jest bardzo mało ale są bardzo ważne dla nas. te drugie obsłużmy po swojemu ale nie pakujmy się w niszowe lub przestarzałe technologie. Nie dawajmy także wiary w to, że kupno tego co ma (powielenie tego co robi) nasz konkurent uczyni nas bardziej konkurencyjnymi bo praktyka pokazuje coś zupełnie odwrotnego. (sierpień 2010, Wymagania na oprogramowanie ERP wspomagające zarządzanie: dwie kupki).

Nowe systemy zintegrowane ERP będą pewnymi zestawami gotowych funkcjonalności, zbudowanymi w oparciu o szkielety oprogramowania zaś integracja będzie bazowała nie na współdzieleniu danych, a na wymianie ich pomiędzy modułami i zewnętrznymi systemami na równych prawach. Rozwój systemu w takim przypadku polega na tworzeniu nowych modułów tym środowisku a nie na modyfikacji już istniejących. (Styczeń 2011, Frameworks Introduction ? czyli jak się psuje dobre ERP).¹

Bo niezależnie od tego jak ?uniwersalny? jest system ERP zawsze będzie gorszy od kilku dobrze dobranych ale niezależnych komponentów. Gorszy nie dlatego, że ?brzydszy? ale dlatego, że będzie kulą u nogi firmy, która powinna jednak reagować na zmiany na rynku w ciągu tygodni a nie lat? Po drugie modyfikacja jakiegokolwiek oprogramowania zawsze wymaga testowania całości, tak więc im mniejsze kawałki mamy tym szybciej i taniej wprowadza się do nich zmiany bo ich oddanie do użytku po modyfikacji jest łatwiejsze i szybsze zarazem. Pamiętajmy pewną starą reklamę: ?Banki od wszystkiego są do niczego??. (Kwiecień 2011, Czego najbardziej brakuje systemom klasy ERP?).

Od lat mówi się o SOA, jako o metodzie budowy i integracji systemów (tu już mamy integrację a nie tylko zdalne użycie). Jednak pojawia się tu potrzeba tworzenia pośredniczącego, kosztownego,  elementu architektury (ESB) co skutecznie ograniczyło zastosowanie tej metody (a raczej technologii) integracji systemów. Cloud Computing to zupełnie inne podejście. To komponentowa architektura znana od lat. (Październik 2011, Cloud Computing to architektura systemu).²

Pojawia się teza:

“ERP jest dziś narzędziem do gromadzenia i składowania wszelkich informacji potrzebnych do podejmowania decyzji w biznesie. Jako takie jest dziś ważniejsze niż kiedykolwiek wcześniej” – podkreśla Nidal Haddad.³ (za  Biznes wychodzi z objęć systemu – Computerworld).

Jeżeli faktycznie tak dostawcy postrzegają systemy ERP (co zresztą wydaje się być właściwe) to nie dziwi fakt, że np. zarządzanie dokumentami, wspomaganie przepływu pracy (workflow) czy wspomaganie podejmowania decyzji (systemy raportowe, business inteligence) to coraz częściej jednak odrębne, integrowane podsystemy. Widać ten trend już na rynku. Np. jeden z liderów rynku ERP, firma SAP, kupił produkt (firmę) Business Object włączając go do swojej oferty jako narzędzie BI,⁴  do zarządzania dokumentami i ich przepływem SAP poleca dedykowany do tego celu system OpenText. ⁵SAP nie jest tu jedynym dostawcą ERP. Podobną strategię zaczynają prezentować i inni liderzy rynku ERP. Tak więc już nie jeden ERP II… O czym to świadczy? O “rozpadzie” idei systemu zintegrowanego:

Uniwersalność oprogramowania wspierającego zarządzanie powoduje, że zacierają się historyczne podziały branżowe. “Wcześniej myślano o systemach klasy ERP jako o narzędziach dających przewagę konkurencyjną. Dzisiaj rozwiązania tego typu stały się bardziej powszechne. Standaryzacja poprzez ERP nie daje przewagi nad konkurencją” – podkreśla Tomasz Bejm, Technology Consulting Leader w firmie PrcewaterhouseCoopers.³.

I jak widać nie ja jeden tak uważam, powielanie rozwiązań nie daje przewagi a wręcz ją zabija.  wspominałem o tym już w 2007 roku (cytat na początku tekstu).

Pora na Cloud Computing:

Analitycy są zgodni, że szczególną rolę w zakresie rozwoju oprogramowania biznesowego odgrywać będzie technologia Cloud Computing. W miarę rozwoju technologii internetowych spodziewać się można wzrostu użyteczności oprogramowania biznesowego oferowanego w modelu usługowym.³ .

Jednak tu należy się pewne wyjaśnienie. Cloud Computing (CC) to nie zwykły outsourcing oprogramowania w postaci znanej od ponad 10 lat jako ASP czy ostatnie SaaS (osobiście nie widzę różnicy poza technologią).  CC to rozbudowane, oferowane na rynku, gotowe do użycia komponenty. Moim zdaniem podawanie jako przykładu CC rozwiązań, których używa się jak innych aplikacji jest błędem. CC to coś do poszerza możliwości posiadanego oprogramowania ale w tle:

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?⁶.

Podsumowanie

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego “super systemu” ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci “gotowej” tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nazwę je “zapóźnione”, nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane [[API, Application Programming Interface]]) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing).  Przyszłość to komponenty…

(J.Ż. 2011)

Rok 2018

Polskie firmy odchodzą od wdrażania systemów monolitycznych. W czasach cyfrowej transformacji i dynamicznych zmian na rynku trwające ponad rok wdrożenia monolitycznych systemów ERP nie zapewniają dostatecznej elastyczności. Długotrwałe, często kastomizowane rozwiązania praktycznie uniemożliwiają wprowadzanie nowych funkcji czy zmianę logiki systemu w trakcie wdrożenia. Oznacza to duże ryzyko utraty jego zasadności przed zakończeniem prac, a jeszcze większe, zanim zakupiony sprzęt czy licencje zostaną zamortyzowane. Monolityczne systemy wiążą przedsiębiorstwo z określonym dostawcą, co w średniej i długiej perspektywie czasowej utrudnia wprowadzanie zmian i zwiększa koszty. ⁷

Przypisy

Wczoraj miała miejsce, zapowiadana na blogu, konferencja na temat Cloud Computing (CC). Nie będę tu powtarzał całego referatu, więc zyskali Ci którzy byli na konferencji :). Tu napisze kilka słów o CC w kontekście tego co było głównym przesłaniem mojego referatu:

Cloud Computing to praktyka realizacji komponentowej architektury systemu a nie kolejna odsłona dzierżawy oprogramowania

O CC często mówi się jako o cudzych aplikacjach dostępnych w sieci. Mówi się o Saleforce, Zoho i innych podobnych, ale to są systemy dostępne zdalnie i licencjonowane (nie ma tu znaczenia to, czy licencje są płatne czy nie).  To jest stare i znane [[ASP]] czy [[SaaS]].

Od lat mówi się o SOA, jako o metodzie budowy i integracji systemów (tu już mamy integrację a nie tylko zdalne użycie). Jednak pojawia się tu potrzeba tworzenia pośredniczącego, kosztownego,  elementu architektury ([[ESB]]) co skutecznie ograniczyło zastosowanie tej metody (a raczej technologii) integracji systemów.

(more…)

Problem dostosowywania (tak zwanej kastomizacji) gotowego oprogramowania nie od dziś jest dyskutowany. Jak wspomniałem w artykule o psuciu systemów ERP, firmy wdrażające najczęściej preferują dostosowywanie (tak zwana [[kastomizacja]]),  producenci tego oprogramowania dla odmiany, odradzają tę ścieżkę. Popatrzmy co na to Martin Fowler, znany w branży IT doświadczony projektant i developer, człowiek znany z tego że napisał naprawdę dużo biznesowego kodu:

A common question in IT departments is whether to provide a capability by building custom software or by buying a package. For longer than I’ve been programming the debate has raged about how to make that choice. My base position on this is founded on the UtilityVsStrategicDichotomy. Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works. (źr. PackageCustomization).

Fowler pyta o to, o co wielu wielu informatyków: czy dostarczenie firmie kolejnych nowych możliwości, powinno się realizować poprzez napisanie (tworząc dedykowane) potrzebne nowe oprogramowanie, czy poprzez zakup gotowego oprogramowania. Ogólnie opinia, zalecane podejście przez Fowlera to: jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów  pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie. Co ciekawe, podobnie jak ja, zaleca w przypadku gotowego oprogramowania dostosowanie się do niego a nie dostosowywanie oprogramowania do siebie.

Z mojej strony dodam, że to kolejna opinia bardzo doświadczonej osoby, z której wynika, że system ERP raczej należy traktować jako federację zintegrowanych programów dziedzinowych, a nie jako jeden zintegrowany pakiet oprogramowania. Ten ostatni zawsze w jakimś obszarze będzie kula u nogi.