Domain-Driven Design – nie metoda a styl….

Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: “Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak ta metoda i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie.” (źr. [[Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997]]).

Czytaj dalej Domain-Driven Design – nie metoda a styl….

Kto odpowiada za bezpieczeństwo danych?

Co wiec się robi? Łamiąc zasady “podpinamy” program analityczny bezpośrednio do danych (linia przerywana program analityczny Baza Danych). Na wszelki wypadek, żeby nie wieszał się, dajemy mu największe możliwe uprawnienia (dobrze gdy tylko do odczytu) i z głowy. Efekt? Po kilku latach w dużych firmach nikt nie wie kto i do czego ma dostęp.

Czytaj dalej Kto odpowiada za bezpieczeństwo danych?

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Czytaj dalej Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

SaaS? Nigdy z ERPII

Obecna praktyka pokazuje, że jednak kierunek komponentowy jest słuszny. Komponenty to między innymi: łatwa do wdrożenia architektura SOA, łatwe dzielenie systemu na obszary o dedykowanych kompetencjach (np. osobno kadry i osobno finanse, osobno sprzedaż, inne). Taki podział to tak zwane dziedzinowe obszary a te to nie raz właśnie osobne specjalizowane podsystemy oraz interfejsy pozwalające na ich współpracę.Przy takim podejściu możliwe staje się używanie w modelu SaaS np. systemu CRM i lokalnie księgowości gdyż ilość wymienianych danych jest relatywnie mała i nie stoimy w obliczu utratry integralności danych.

Czytaj dalej SaaS? Nigdy z ERPII

Schyłek epoki krawców

System IT powinien się zwrócić w okresie rzędu trzech do pięciu lat. Przyjmuje się taki mniej więcej okres zachodzenia istotnych zmian w otoczeniu rynkowym, niektóre firmy uznają nawet, że w ich branży okres ten nie przekracza jednego roku. Uśredniając podane wartości można uznać, że system IT powinien się zwrócić w trzy lata a minimalna inwestycja to 50tys.złotych. Oznacza to, że (dla uproszczenia nie licząc kosztu pieniądza) średniomiesięczny koszt to 50 tys./36 miesięcy=1388zł. Załóżmy, że na IT firmy wydają 2% przychodów (co moim zdaniem jest optymistycznym założeniem) to na inwestycję taką będzie stać firmę o minimalnych miesięcznych przychodach rzędu prawie 70 tys. zł.

Czytaj dalej Schyłek epoki krawców

Konferencja XIII Forum Teleinformatyki

Zostałem zaproszony na tę konferencję zarówno jako patron medialny (jako wydawca serwisu IT-Consulting.pl) oraz jako ekspert.

Wydaje mi się, że to jedna z ciekawszych konferencji jakie się odbywają w naszym kraju w tej branży gdyż gromadzi z jednej strony czołowe kadry naukowe a z drugiej przedstawicieli liczących się podmiotów na rynku i przedstawicieli instytucji rządowych czyli jednego z największych beneficjentów technologii ICT (ang. Information and Communication Technology). Poniżej moje refleksje z wybranych referatów. Pominięcie niektórych z nich to efekt mojego pewnego subiektywizmu w ich ocenie, starałem się zwrócić uwagę na pewne wybrane aspekty związane z obszarem moich zainteresować i mam nadzieję czytelników portalu. Dla porządku zamieszczam na końcu artykułu pełną listę referatów i ich autorów.

Czytaj dalej Konferencja XIII Forum Teleinformatyki

O błędach w modelowaniu

Poprawny model organizacji, w szczególności mapa procesów biznesowych, powinien opisywać tylko przedmiot analizy np. specyfikę organizacji będąca np. źródłem jej przewagi konkurencyjnej i to jak organizacja tę specyfikę tworzy. Model powinien się odwoływać do innych istniejących już dokumentów, np. zakresu kompetencji pracownika czy instrukcji stanowiskowej. Model zawsze powinien mieć jakiś cel swojego powstania i kontekst.

Czytaj dalej O błędach w modelowaniu

SOA: młot na pakiety zintegrowane ERP

[toc] Usługi na sztuki czy kompleksowe pakiety SOA moim zdaniem zagroziło zintegrowanym systemom np. ERPII i nie tylko. Pojawiło się światełko w tunelu dla szybko wdrażanych aplikacji na życzenie z…

Czytaj dalej SOA: młot na pakiety zintegrowane ERP