Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
"Jeżeli nie potrafisz czegoś dobrze narysować, to znaczy że nadal tego nie rozumiesz…"
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ą,…
Artykuł ma dwie części. Pierwsza część jest adresowana do kadr zarządczych, cały artykuł (obie części) do osób zajmujących się projektowaniem rozwiązań.
Wstęp
Mamy ogólnoświatową sieć Internet, aplikacje lokalne i w chmurze, aplikacje naszych kontrahentów i aplikacje centralnych urzędów. Wszystkie one współpracują i wymieniają dane, czyli są zintegrowane. Dlatego integracja stała się cechą każdego systemu informatycznego.
Wyjątkowo na początku (poniżej) umieszczam cały ten ciekawy referat, można bo pominąć i czytać dalej, jednak jeżeli ktoś chce poznać przewidywania z roku 2016 i ma czas, polecam (teraz lub później):
The Future of Software Engineering ? Mary Poppendieck ? GOTO 2016
Obecnie kluczowym pytaniem jest: Jak zintegrować, a nie: Czy zintegrować.
Pogodzenie się z tym, że świat systemó ERP już nigdy nie będzie tak prosty jak w czasach mainframe’ów, czyli jednej centralnej aplikacji, jest nieuniknione.
Czym jest obecnie integracja? To wymiana danych a nie ich współdzielenie: dane z urzędem wymieniamy, dane z kontrahentem wymieniamy, nie współdzielimy żadnych danych z tymi podmiotami, każdy ma swoje własne, bezpieczne bazy danych, i to wszystko ładnie działa! Idea zbudowania wszystkich funkcjonalności jako zintegrowanej aplikacji na jednej współdzielonej bazie danych w czasach obecnych jest utopią. Taką samą jak hipotetyczna centralna baza danych dla wszystkich sklepów internetowych, firm kurierskich i banków, a one są jednak zintegrowane: one wymieniają dane a nie współdzielą!
ERP to (ang.) Enterprise Resource Planning czyli Planowanie Zasobów Przedsiębiorstwa. To system wykorzystywany przez firmy do zarządzania i integrowania ważnych elementów ich działalności. Ale kto powiedział, że to ma być monolit od jednego producenta?
Nadal spotykam pejoratywne określenia „system pointegrowany” jako krytykę budowy systemu ERP z komponentów i integracji jako wymiany danych. Autor tego określenia najprawdopodobniej nadal żyje w świecie mainframe.
Chociaż dostawcy systemów ERP oferują aplikacje dla przedsiębiorstw i twierdzą, że ich zintegrowany system jest najlepszym rozwiązaniem, wszystkie moduły w jednym systemie ERP rzadko kiedy są najlepsze z najlepszych.
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…
Od czasu do czasu są takie momenty, że świat podsuwa mi gotowe teksty do publikacji. Każdy kto mnie zna i czyta wie, że od lat odradzam wdrażanie wielkich monolitów ERP, uzasadnienie tego z moich ust najczęściej jest jednak odbierane jako moje spekulacje (mimo, że zawsze uzasadniam swoje zdanie a przykładów nie brakuje). A o tym sądzą dyrektorzy firm?
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…
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.
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.
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ć.
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.
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ę…
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"...
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.
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
Widzę, że przeglądasz stronę. Zapraszam do dalszej lektury, tu zapoznasz się moim dorobkiem. Jeżeli szukasz usługodawcy zapraszam na STRONĘ Z OFERTĄ. Jeżeli szukasz wiedzy, zachęcam do dalszej lektury lub na SZKOLENIA i KONSULTACJE.