Jak wyjść z długu technologicznego jakim jest centralny monolityczny system

Na temat tego jakim uciążliwym długiem technologicznym jest monolityczny system napisano wiele, dzisiaj kolejne dwie ciekawe pozycje literatury: CMMI Compliant Modernization Framework to Transform Legacy Systems oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices . Pierwsza publikacja opisuje metodę zaplanowania wyjścia z długu technologicznego z perspektywy analizy biznesowej, druga opisuje możliwą realizację techniczną z perspektywy architektury aplikacji i ewolucyjnej migracji z architektury monolitycznej do komponentowej (mikro-serwisy). Czym jest monolit? Jest to system, którego architektura stanowi jeden niepodzielny blok realizujący funkcje biznesowe. Kluczową cechą i zarazem wadą,…

Czytaj dalejJak wyjść z długu technologicznego jakim jest centralny monolityczny system

Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu informatycznego. 

Obecnie klu­czo­wym pyta­niem jest: Jak zin­te­gro­wać, a nie: Czy zintegrować. 

Pogodzenie się z tym, że świat sys­te­mó ERP już nigdy nie będzie tak pro­sty jak w cza­sach main­fra­me­’ów, czy­li jed­nej cen­tral­nej apli­ka­cji, jest nieuniknione. 

Czym jest obec­nie inte­gra­cja? To wymia­na danych a nie ich współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych w cza­sach obec­nych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia sys­tem poin­te­gro­wa­ny” jako kry­ty­kę budo­wy sys­te­mu ERP z kom­po­nen­tów i inte­gra­cji jako wymia­ny danych. Autor tego okre­śle­nia naj­praw­do­po­dob­niej nadal żyje w świe­cie mainframe. 

(wię­cej…)

Czytaj dalejIntegracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Czy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?

O integracji i unikaniu kastomizacji monolitów poprzez wdrażanie dziedzinowych podsystemów napisałem tu wiele. Tym razem kilka komentarzy do krótkiego tekstu pewnego dostawcy monolitu ERP. Tekst krótki więc cytowanie stanowi niemalże jego połowę ale cóż, prawo cytowania treści bezpośrednio komentowanych... Artykuł Choć wyspecjalizowane pod konkretny obszar systemy oferują szerokie możliwości i najłatwiej je dopasować do potrzeb organizacji, może okazać się, że wraz z rozwojem firmy przestaną być efektywne. (źr.: 6 przesłanek, które mogą wskazywać, że powinieneś wdrożyć kompleksowe oprogramowanie) Pierwsze zdanie to prawda, a drugie (zaczynając sie od "może") sugeruje, że…

Czytaj dalejCzy faktycznie powinieneś wdrożyć kompleksowe oprogramowanie?
Read more about the article Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP
11392158 - the great east japan earthquake

Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Krótki wstęp

Od cza­su do cza­su są takie momen­ty, że świat pod­su­wa mi goto­we tek­sty do publi­ka­cji. Każdy kto mnie zna i czy­ta wie, że od lat odra­dzam wdra­ża­nie wiel­kich mono­li­tów ERP, uza­sad­nie­nie tego z moich ust naj­czę­ściej jest jed­nak odbie­ra­ne jako moje spe­ku­la­cje (mimo, że zawsze uza­sad­niam swo­je zda­nie a przy­kła­dów nie bra­ku­je). A o tym sądzą dyrek­to­rzy firm?

(wię­cej…)

Czytaj dalejDyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP
SOA
Street, K. (2006). Building a Service Oriented Architecture with BPM and MDA. 2(1), 8.

Modelowanie w projektach integracyjnych

Projekty integracyjne w środowisku złożonych (kilkadziesiąt aplikacji) systemów należą do bardzo trudnych z uwagi na ich złożoność.  Z pomocą przychodzi nam SOA jako model pojęciowy i ESB jako wzorzec architektury. Referat, wygłoszony na konferencji GigaCon,  opisuje proces analizy  i modelowania w toku specyfikowania wymagań na ESB i interfejsy. Poniżej struktura architektury SOA na bazie standardów OMG:   Kluczowe pojęcia: - procesy biznesowe, elementarne aktywności, która wraz z wejściem i wyjściem stanowią elementarny proces biznesowy, - usługa biznesowa (także aplikacyjna) to przypadek użycia danej aplikacji (aplikacja świadczy usługi, każda usługa ma…

Czytaj dalejModelowanie w projektach integracyjnych

Zintegrowany ERP: postęp czy cofanie?

Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże "zabetonowanie" architektury biznesowej firmy.

Czytaj dalejZintegrowany ERP: postęp czy cofanie?

Skomplikowana sieć aplikacji to kula u nogi działów IT

Tak na prawdę integracja taka polega nie na samym zainstalowaniu ESB i "podłączeniu" komponentów, to samo z siebie nic nie wnosi i nie jest łatwe. Integracja z użyciem ESB, to po pierwsze stworzenie (lub użycie jeżeli istnieje) dla każdego komponentu odpowiedniego adaptera i API, po drugie zaprojektowanie schematu komunikacji.

Czytaj dalejSkomplikowana sieć aplikacji to kula u nogi działów IT

CHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług

Autonomiczne, duże systemy ERP? Nie wróżę im kariery, w obecnej postaci mega-aplikacje umrą, odwlekanie tej śmierci z pomocą perswazyjnych reklam i kampanii dużych korporacji i ich sprzedawców, to tylko sztuczne przedłużanie życia inwestycji w duże ERP, przez producentów tych rozwiązań, dawanie sobie czasu na (mam nadzieję) ich refaktoring. Mamy np. takie kolosy jak Google czy Amazon, które pokazują, że chmurowe, wysoce skalowalne architektury zasobowe mają sens. Systemy ERP oparte na relacyjnych bazach danych i ich wewnętrzna integracja poprzez współdzielenie danych, nie mają nawet szansy z tego skorzystać.

Czytaj dalejCHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług

Wymagania pozafunkcjonalne – integracja

Integracja to jeden z trudniejszych problemów. Wymaga bowiem nie tylko specyfikowania (i potem ich implementowania) interfejsów, ale także analizy i opracowania bezpiecznej architektury całego systemu (tu znowu architektura korporacyjna). Wiele firm ma, nie dwie ale kilka, kilkanaście a niektóre nawet setki aplikacji. Jeżeli będę ze sobą "pospawane" wywołaniami SQL/ODBC, to ruszenie "tego" praktycznie zawsze kończy się krachem (czytaj ogromne koszty przywrócenia funkcjonowania całości). Brak przemyślanej architektury, integracja ad-hoc "każdy z każdym", to prosta droga do kłopotów i ogromnych kosztów utrzymania całości. Stosowanie API (ich tworzenie) nieco tylko podnosi koszty wdrożenia, za to chroni przed bardzo dużymi, nieplanowanymi, wydatkami w przyszłości.

Czytaj dalejWymagania pozafunkcjonalne – integracja

RE: Duży monolityczny ERP czy integracja

Pojawiła się polemika do mojego artykułu  Duży monolityczny ERP czy integracja (fragment, gorąco polecam cały wpis): Witam Kolegę Blogera i na powitanie mam małą polemikę. Otóż nie mogę się zgodzić na tak szeroko postawione pytanie "Duży ERP, czy integracja" gdyż na nie odpowiedziała już Historia. Od ERP nie ma odwrotu! (RE: Duży ERP czy integracja - ERP -view.pl - System ERP, CRM, ERP, Business Intelligence, MRP).?*? Jako, że zostałem wywołany do tablicy :), odpisuję. Zakładam, że powyższą lekturę już Państwo mają za sobą, jeżeli jednak nie, cytuje treści, które omawiam. Na początek proponuję uzgodnić jedną rzecz: definicję…

Czytaj dalejRE: Duży monolityczny ERP czy integracja

Duży monolityczny ERP czy integracja

Tym razem krótko. Praktycznie za każdym razem moje rozmowy z potencjalnymi klientami dotykają problemu: jeden zintegrowany system ERP czy kilka dziedzinowych rozwiązań. Ja zawsze powtarzam to samo: im większy monolityczny system tym większym ograniczeniem i kosztem staje się dla firmy, tym większe uzależnienie od jednego dostwcy. Na rynku ścierają się stale dwie grupy opinii: "duży ERP jest lepszy bo od jednego dostawcy i od razu zintegrowany", kontra teza "duży ERP monolityczny wymaga wielu prac dostosowawczych i bardzo trudno zmienić w nim jedno nie ingerując w resztę". [...] "lepszym rozwiązaniem będzie wdrożenie systemów dziedzinowych i ich zintegrowanie"...

Czytaj dalejDuży monolityczny ERP czy integracja

Udziałowcy projektu czyli który diagram UML …

Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu. UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań. Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Czytaj dalejUdziałowcy projektu czyli który diagram UML …

Koniec treści

Nie ma więcej stron do załadowania