424 Znaleziono wyniki wyszukiwania

Szukałeś: "ERP"
Business Analysis – diagram klas UML i bazy danych

Business Analysis – diagram klas UML i bazy danych

pytanie o diagram klas jako reprezentacja [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca) mówiących o modelowaniu danych diagramami klas notacji UML. Do modelowania danych używamy notacji ERD (ang. [[Entity Relationship Diagram]], diagram związków encji).

Czytaj dalej Business Analysis – diagram klas UML i bazy danych
Myślenie obiektowe w programowaniu

Myślenie obiektowe w programowaniu

Książka adresowana do programistów, sam tytuł to sugeruje. Warto ją kupić (programiści) bo bardzo  wyczerpująco opisuje to, co nazywam "implementacją obiektowości". Samo nauczenie się (semantyka i syntaktyka) obiektowo zorientowanego języka…

Czytaj dalej Myślenie obiektowe w programowaniu
Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w projektach IT

Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w projektach IT

Tak więc warto się zastanowić jak dotrzemy do wiedzy o naszej firmie, i na ile jest ona wiarygodna, nie zaciemniona nadmiarem zbędnych szczegółów i czy wiedza ta jest obiektywna. Dobra analiza konkretnej organizacji, firmy, urzędu, i jej wyniki nie może być np. polityczna (regularnie spotykam w firmach analizy, których celem jest wykazanie przydatności określonego rozwiązania!) bo to działanie polegające na oferowaniu leków przed diagnozą (reklamy leków bez recepty w TV!). Tak można sobie tylko zaszkodzić. A zdalna analiza (faktycznie zdalnie odbywa się ok. 80% pracy) pozawala po pierwsze obniżyć jej koszt, a po drugie zobiektywizować jej wyniki.

Czytaj dalej Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w projektach IT
Skomplikowana sieć aplikacji to kula u nogi działów IT

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 dalej Skomplikowana 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

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 dalej CHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług
Wymagania pozafunkcjonalne – integracja

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 dalej Wymagania pozafunkcjonalne – integracja
Wymagania pozafunkcjonane czyli jaka architektura

Wymagania pozafunkcjonane czyli jaka architektura

Jak wspomniałem, wielu dostawców oprogramowania jak Rejtan, broni się przed ujawnianiem architektury, swoich produktów. Głównym powodem jest zapobieganie przedwczesnego wyjawienia opisanych wyżej wad systemów z grubym klientem (znacznie rzadziej spektakularny pomysł, w końcu mamy jednak jakieś standardy). Przypadki, w których zakup systemu był relatywnie niski ale koszt utrzymania, rozwoju i dostosowania nie raz wręcz ogromny, to z reguły właśnie zakup systemu w tej kosztownej architekturze.
Jak starać się tego unikać? Na etapie definiowania wymagań poza-funkcjonalnych, żądać takich cech jak opisane powyżej czyli własnie: dostęp do całości przez przeglądarkę WWW, niskie wymagania na łącza przy zdalnej pracy i pracy w sieci rozproszonej terytorialnie, oddzielenie komponentu z własną dedykowaną logiką biznesową.

Czytaj dalej Wymagania pozafunkcjonane czyli jaka architektura
Przewodnik po Architekturze Korporacyjnej

Przewodnik po Architekturze Korporacyjnej

Mam w ręku książkę Guide to Enterprise IT Architecture (Springer Professional Computing, autorzy Col Perks, Tony Beveridge). Co prawda wydana w 2003 roku jednak, autorzy skupili się na pryncypiach dzięki czemu…

Czytaj dalej Przewodnik po Architekturze Korporacyjnej