W 2011 roku, w artykule Czego najbardziej brakuje systemom klasy ERP? pisałem, że nawet, jeżeli wdrażane jest dostępne na rynku standardowe oprogramowanie, co minimalizuje ryzyko uzależnienia od jednego dostawcy, to już zgoda na jego tak zwaną kastomizację (dostosowanie do specyficznych wymagań) natychmiast powoduje efekt zwany 'vendor lock-in'. Identyczny jak w przypadku oprogramowania dedykowanego opracowanego i dostarczonego przez jego wykonawcę. Z jednej strony tak zwany 'vendor lock-in' krytykują wszyscy klienci, nabywcy systemów ERP (ogólnie oprogramowania), a z drugiej strony godzą się na to w umowach. Jak to robią? Scenariusz jest prosty…
Ten artykuł to próba przybliżenia czytelnikowi pojęcia metamodel i model. To także mała próbka tego co jest produktem nadzoru autorskiego. Nieco ponad pięć lat temu w artykule Diagram obiektów czyli bottom-up pisałem o pojęciu instancji obiektu i diagramie obiektów. Wtedy skupiłem się na jednym tylko wątku, jakim jest analiza zmierzająca do opracowania ... no właśnie, czego? Z reguły autorzy dokumentów zawierających "diagramy klas" mówią, że tworzą modele. Czy zawsze są to modele? Wprowadzenie Jednym z bardzo niedocenianych typów diagramów UML są diagram obiektów i diagram wdrożenia (który jest rodzajem diagramu…
Generalnie modele referencyjne mają i dobrą i złą sławę. Nie są to wzorce projektowe, czyli dobre praktyki w postaci uniwersalnych abstrakcyjnych meta-modeli, są to najczęściej narzucane gotowe architektury, pozostaje pytanie: kto narzuca?. Procesy referencyjne krytykowałem nie raz (Procesy referencyjne czyli kto żyw niech ucieka), referencyjny model ERP oznaczałby, że istnieje jakaś jedynie słuszna architektura systemu ERPII. I właśnie dostawcy wielu systemów ERPII (szczególnie ci duzi, których produkty mają wiele lat) promują model oparty o jedną wspólną relacyjną bazę danych, wokół której są osadzone dziedzinowe moduły, nazywają taki model modelem referencyjnym.…
Powyższy tytuł to oryginalny tytuł jednego z cytowanych poniżej artykułów. Wybrałem go, bo obrazuje pewien problem na rynku IT (ale nie tylko na tym rynku). Ten problem to właśnie tak zwane "życzeniowe myślenie". Dotyczy ono zarówno oczekiwań jak i zobowiązań, tak dostawców jak i nabywców oprogramowania. Celowo nie piszę usługodawców IT, bo znakomita większość tak zwanych "projektów IT" ma za cel tylko to, by nabywca zyskał oprogramowanie, którego użyje jako narzędzia w prowadzonej przez siebie działalności. To czy kupi gotowe i wdroży, czy zleci jego stworzenie dla siebie, czy też…
