Wyniki wyszukiwania dla „architektura systemu” – Strona 16

Wstęp do architektury biznesowej

Autor prezentuje podejście, które nazywam podejściem “opartym na danych”. Co mam na myśli? Otóż podejście to zakłada, że istotą “systemu” jakim jest organizacja są gromadzona i zarządzane dane (wiedza). Inne podejście, nazwę je operacyjne (lub procesowe), zakłada że istotą organizacje jest odgrywanie określonej roli na rynku (dostawca produktów, usługodawca, itp.). Innymi słowy istotne jest to co potrafię zaoferować a nie to jakimi danymi dysponuję.

Czytaj dalej

Sekwencje a procesy

Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju “ale ja chcę zobaczyć to wszystko na jednym diagramie” pchamy projekt w kierunku “utraty panowania nad złożonością”… To prosta droga do klęski projektu.

Czytaj dalej

Czym jest dług technologiczny?

Tak więc stagnacja szkodzi, są to krótkotrwałe zyski, podobne do niezapłacenia rachunku za energie elektryczną: za miesiąc będzie dwukrotnie wyższy plus odsetki. Bieżące, dobrze zaplanowane “aktualizacje” (oprogramowania, dokumentacji projektowej, analizy i planowania, itp.) to relatywnie małe koszty, a dla firmy istotne są nie tyle kwotowe chwilowe wydatki (oszczędności) co płynność finansowa i długoterminowa rentowność. Dlatego permanentni dłużnicy zawsze płaca więcej a czasami bankrutują.

Czytaj dalej

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

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

Tak zwane projekty internetowe

Projektując internetowy system obsługi klienta tak na prawdę rozwiązujemy dwa zupełnie odrębne problemy: musimy zastąpić sprzedawcę naszą nową stroną WWW oraz obsłużyć zdarzenia, które wygeneruje nasz (tu wirtualny) sprzedawca.

Mamy więc niejako dwa odrębne projekty: opracowanie portalu, i to jest robota dla agencji interaktywnej. Drugi, to zaprojektowanie i wytworzenie (albo opisanie, zakup gotowego na rynku i zintegrowanie) czysto biznesowego, złożonego, oprogramowania “wypchanego” trudną i złożoną logika biznesową. Dlatego takie projekty należy dzielić na komponenty, na dwa (pod)projekty, z których każdy można (i ma to sens) realizować odrębnymi metodami pracy. Pierwszy (portal) zwinnie, drugi – planując i projektując.

Czytaj dalej

Sklep

Wielokrotnie byłem pytany o kurs on-line i zestaw ćwiczeń z odpowiedziami dla analityków i projektantów. Zadawane ćwiczenia i odpowiedzi moim zdaniem w tym przypadku nie sprawdzają się, dlatego publikuję tu…

Czytaj dalej

Analiza Potrzeb Użytkowników i Dokumentowanie Wymagań na system ERP

Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją. Korzyści: ochrona know-how Zamawiającego, kompletne…

Czytaj dalej