ERP, CRM, Inventory, problem.
https://dataedo.com/cartoon
Wprowadzenie To pytanie zadaje sobie każdy kto planuje tę inwestycję. Czy to łatwy wybór? Nie. Na początek ważny fakt: wdrożenia monolitów: Co jest powodem? Kluczowym jest architektura: relacyjne bazy danych tych systemów mają kilka tysięcy powiązanych tabel, zapytania SQL do tych tabel to setki linii kodu na każde zapytanie, a zapytań tych są setki, kod tych aplikacji jest jeszcze bardziej złożony (mowa o milionach linii kodu). Razem wygląda tak jak poniżej: Struktura monolitycznego ERP Efekt? Kastomizacja tak złożonego kodu to praktycznie pewna porażka, a niestety oferują to w zasadzie wszystkie…
Ponieważ projekty informatyczne są traktowane jako projekty technologiczne i najczęściej zlecane dostawcom technologii. To największy błąd, jaki można popełnić. W tym miejscu chciałbym zwrócić uwagę, że wymagania dzielą się na funkcjonalne i niefunkcjonalne. Wymagania niefunkcjonalne nigdy nie stanowiły problemu, ale wymagania funkcjonalne zawsze są problemem. Dlaczego więc zarządzanie projektami powierza się dostawcom technologii? Architektura korporacyjna – stary model SOA Poniższy schemat (Street, K. (2006). Budowanie architektury zorientowanej na usługi z wykorzystaniem BPM i MDA. 2(1), 8.) ilustruje kluczowe warstwy (poziomy) opisu organizacyjnego: procesy biznesowe usługi biznesowe (wymagane przez biznes) komponenty…
Zależnie od szacunków (czyli od tego jak zdefiniowano sukces) 60 - 80% projektów IT to nieudane projekty. Pod pojęciem projektu IT rozumiemy tu systemy dla firm: szeroko pojęte systemy biznesowe. Na świecie każdego dnia inicjowanych są setki tysięcy projektów IT dla firm, śladowe ilości nowych gier i w zasadzie żaden nowy system operacyjny (co najwyżej jego drobne rozszerzenia i aktualizacje). Dlatego nie ma sensu by w projektach biznesowych stosować wzorce i metody sprawdzone w tworzeniu gier czy środowisk technologicznych. Dlatego zlecanie projektów biznesowych od razu deweloperom ma bardzo nikłe szanse…
Wprowadzenie W roku 2024 pisałem: Jak widać czasami łatwo pomylić pojęcia model i mechanizm, można jednak powiedzieć, że model to schemat obrazujący coś, zaś mechanizm to wyjaśnienie zjawiska (tego jak coś powstaje jak działa). Mechanizm można zobrazować w postaci modelu. Jeżeli dążymy by model był idealizacją, to wtedy właśnie:"Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm." (Craver & Tabery, 2019) Patrz: Mechanizm działania vs model systemu vs diagram – Jarosław Żeliński IT-Consulting A co z komputerami…
Wprowadzenie W kwietniu 2024 roku opisywałem API Artykuł powyższy polecam osobom zainteresowanym stroną techniczną projektowania integracji i API. Dzisiaj odpowiem na problemy jakie zgłaszają prawnicy, czyli co jest przedmiotem umowy gdy przedmiotem tym jest mityczne API. (https://it-consulting.pl/2024/04/05/api-to-cos-innego-nie/) Wtedy problemem była próba traktowania oryginalnego API systemu ERP jak dedykowanej aplikacji, czy odrębnego kodu (licencja na API). Problemem jest często także poprawne nazewnictwo tego "o czym mowa", są to nieporozumienia (lub celowe działanie) wywoływane ukrywaniem architektury przez dostawcę oprogramowania. W między czasie trafiła się dzisiaj ciekawa, krótka dyskusja o API na "Anonimowy…
Wprowadzenie Aplikacje Jira i Confluence firmy Atlassian są bardzo popularne nie tylko w działach IT. Obie wspierają między innymi prace analityczne i projektowe na poziomie zadań (Jira) i treści (Confluence). Producent pakietu CASE Visual Paradigm, od wersji 17.3 wspiera integrację swojego pakietu z tymi aplikacjami, w efekcie w tych środowiskach możliwa stała się pełna integracja zespołu projektowego wykonawczego z analitykami i projektantami. Płynna integracja z Atlassian Confluence Zastosowanie: Agile Development: Udostępnianie zaktualizowanych przepływów pracy i diagramów UML w dokumentacji sprintu. Zarządzanie produktem: Osadzanie modeli procesów na stronach specyfikacji produktu. Architektura…
Wprowadzenie Jedną z największych pomyłek inżynierii oprogramowania jest dziedziczenie, czyli odtwarzanie w kodzie taksonomii modeli pojęciowych. Nie mniejszą pomyłką jest teza, że OO to łączenie funkcji i danych w obiekty (to jest antywzorzec projektowy, patrz np. DDD czy BCE). Obiektowy paradygmat to wymiana komunikatów między obiektami. Komputer nie przetwarza ani ludzi ani przedmiotów, więc odtwarzanie w architekturze kodu tego, że np. koń to rodzaj ssaka nie ma żadnego sensu, za to znakomicie komplikuje architekturę kodu. Utrwalanie tego w setkach powiązanych relacyjnie tabel dodatkowo komplikuje wszystko (kolejne setki linii kodu SQL).…
(źr.: https://www.redhat.com/en/topics/microservices/what-are-microservices)
Wprowadzenie Często spotykaną definicją mikro-serwisów jest W inżynierii oprogramowania architektura mikro-serwisów to wzorzec architektoniczny, który organizuje aplikację w zbiór luźno powiązanych, drobnoziarnistych usług, które komunikują się za pośrednictwem lekkich protokołów. Wzorzec ten charakteryzuje się możliwością niezależnego opracowywania i wdrażania usług, poprawiając modułowość, skalowalność i zdolność adaptacji. Wprowadza on jednak dodatkową złożoność, szczególnie w zarządzaniu systemami rozproszonymi i komunikacją między usługami, czyniąc początkową implementację trudniejszą w porównaniu do architektury monolitycznej. (https://en.wikipedia.org/wiki/Microservices) To samo źródło dalej: Nie istnieje jedna, powszechnie uzgodniona definicja mikro-serwisów. Ogólnie jednak charakteryzują się one skupieniem na modułowości, a…
Wprowadzenie W marcu 2021 w artykule Struktury formularzy jako forma wyrażania wymagań skupiłem się na detalach treści formularzy ekranowych, jako elementach specyfikowania przypadków użycia. Artykuł ten sprowokował pytania o związki między formularzami, ich przepływy oraz niekończące się pytania o cel stosowania związków extend i include używane często niepoprawnie w celu pokazania "przepływu ekranów". Dlatego napisałem post będący rodzajem kontynuacji tego tekstu. W toku analizy biznesowej, a potem projektowania oprogramowania, powstają różne produkty: modele procesów biznesowych, modele architektury systemów, scenariusze integracji, definicje interfejsów, i inne. Większość ich jest niezrozumiała dla przeciętnego…
Wprowadzenie W branży IT dość często mylone są pojęcia dotyczące techniki i technologii. Dobrym więc ruchem było uporządkowanie tego. Na stronie Rady Języka przy Prezydium Polskiej Akademii Nauk ukazała się ciekawa publikacja (jako, że to definicje, które omówię, cytuję w całości) : Definicje podstawowych pojęć związanych z techniką i technologią Komunikat Zespołu Terminologii Informatycznej RJP Nr 2/2021 z 16 czerwca 2021 roku Definicje podstawowych pojęć: {technika|technologia}{informacyjna|przetwarzania informacji|informatyczna|cyfrowa} Wychodząc od zasady, że częścią pojęcia „technika” jest „technologia”, a z kolei w definicji „technologii” należy się odwołać do użytych technik (tzw. definicja rekurencyjna), przedstawiamy zestaw tych definicji.…
Pewna krótka rozmowa Czytelnik: Dzień dobry : ) Co sądzi Pan o tym, żeby publikować swoje codzienne wpisy także po angielsku/niemiecku ? Myślę, że w polskim Internecie ma już Pan duże zasięgi bo dosyć często wyświetlają mi się ciekawostki od Pana, szkoda by było, żeby ten potencjał zmarnował się tylko na klientów z Polski. Co sądzi Pan o tym, żeby publikować we wpisach typy projektów/produktów, gdzie: agile będzie lepszy od super-analityka-projektanta agile będzie gorszy Jarosław Żeliński: Kilka wyjaśnień: agile jest formalnie definiowane jako praca zespołowa koderów i użytkowników, to podejście…
Wprowadzenie Bardzo wiele emocji budzą kwestie styku aplikacji i jej środowiska: mój wpis na LinkedIn "Czy logowanie jest przypadkiem użycia" wzbudził burzliwą dyskusję i wiele kontrowersji. Ten artykuł to opis modelu aplikacji i jej środowiska. Kluczowe pojęcia Pojęcie aplikacja jest definiowane (SJP) jako "komputerowy program użytkowy". Biorąc pod uwagę fakt, że słownikowo "użytkownik" to osoba (użytkownik - osoba lub instytucja użytkująca coś, SJP), aplikacja to "program użytkowy dla człowieka". W specyfikacji notacji UML czytamy: Przypadki Użycia są środkiem do uchwycenia wymagań systemów, tj. tego, co systemy mają robić. Kluczowymi pojęciamiw…
