Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: "nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale". To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa... a nie raz z jego łamaniem.  Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji.…

Czytaj dalejCzy wdrożenie zawsze wymaga reorganizacji?

Prawa autorskie w ARCHITEKTURZE

Niedawno pisałem (Instrukcja dla prawników...) o tym, że prawnicy to nie inżynierowie. Nie był to przytyk, a zwykłe wskazanie na fakt, że to po prostu  rożne kompetencje. Problem prawa autorskiego w obszarze szeroko pojętej inżynierii jest bardzo trudny, nie jest to "wiedza humanistyczna". Podejście prawników z reguły jednak bazuje na humanistycznej wiedzy tychże. Poniżej cytat pewnego bloga: Utwór architektoniczny należy moim zdaniem zakwalifikować (albo traktować analogicznie w tej kwestii) do szeroko rozumianych dzieł plastycznych. Te ostatnie bowiem, w przeciwieństwie np. do utworów muzycznych lub wyrażonych słowem, dużo ściślej związane są…

Czytaj dalejPrawa autorskie w ARCHITEKTURZE

Mikroserwisy c.d.?

Dwa lata temu pisałem o mikroserwisach: Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem  ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst  (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien…

Czytaj dalejMikroserwisy c.d.?

PERSPEKTYWY 2017 – ERP, CRM, MRP, Business Intelligence, MRP

Jako partner merytoryczny Raportu zapraszam do lektury... PERSPEKTYWY ERP 2017Wzorem ubiegłego roku oddajemy do Państwa dyspozycji materiał stanowiący podsumowanie działań kluczowych dostawców rozwiązań wspomagających zarządzanie przedsiębiorstwem w 2016 r. oraz prezentację kierunków rozwoju oferowanych systemów ERP w roku bieżącym. Mamy nadzieję, iż zaprezentowane wypowiedzi będą dodatkowym argumentem przy wyborze partnera w działaniach zmierzających do optymalizacji i podniesienia efektywności posiadanych zasobów IT w roku 2017. Źródło: PERSPEKTYWY 2017 - ERP-view.pl - ERP, CRM, MRP, Business Intelligence, MRP

Czytaj dalejPERSPEKTYWY 2017 – ERP, CRM, MRP, Business Intelligence, MRP

UML polecane książki dla moich studentów

  Krótki wpis o literaturze dla studentów. Te trzy pozycje, niestety chyba już tylko biblioteki i antykwariaty, polecam uczącym się. W zasadzie drobnych poprawek wymagały wybrane diagramy ale książki te są napisane przez programistów, wiec ich treść ma uzasadnienie i książki te bronią się. Same. Są to: Martin Fowler, UML w kropelce, P.Graessle, H.Baumann, P.Baumann, UML 2.0 w akcji, Joseph Schmuler, UML dla każdego.   Do tego zestawu warto dodać UML i wzorce projektowe, C.Larrmana.

Czytaj dalejUML polecane książki dla moich studentów

Component Software

Kolejna książka z cyklu "ta wiedza się nie starzeje" a nie starzeje się architektura i wzorce.  Tym razem:  Component Software: Beyond Object-Oriented Programming (ACM Press), Clemens Szyperski, Published by Addison-Wesley Professional (1998), ISBN 10: 0201178885 ISBN 13: 9780201178883 Autor doskonale opisuje kwestie komponentów, interfejsów, polimorfizm. Zwraca uwagę na często błędne pojmowanie i używanie dziedziczenia w architekturze (!), nie raz wręcz szkodliwe. Zwraca uwagę na  aspekty rynkowe koponentowej architektury. jej dużej podatności na zmiany rynkowe.  Opisuje rynkowe standardy różnych dostawców, w tym Microsoft, Oracle, OMG. Najciekawsze są prognozy rynkowe, drugie wydanie (reprint) pochodzi z…

Czytaj dalejComponent Software

Opis Przedmiotu Zamówienia – instrukcja nie tylko dla prawników

Od lat stosuję w swoich analizach i projektach między innymi, diagramy takie jak powyższej. Pomagają one ustalić precyzyjnie wszelkie aspekty i prawne i projektowe w umowach, do czego gorąco zachęcam. Niestety wielu prawników przyjmuje za cel swojej pracy ?obudowanie? paragrafami tego czego żądają od nich w umowach, ich klienci ? dostawcy oprogramowania. Owszem firmy IT płacą prawnikom za to, że Ci chronią ich interes, ale wiele z tych umów to niestety manipulacje i korzystanie z niewiedzy nabywców oprogramowania? nie raz nieznajomość (niezrozumienie) prawa przez dostawców oprogramowania?

Czytaj dalejOpis Przedmiotu Zamówienia – instrukcja nie tylko dla prawników

Agile w PZP

Polecam lekturę ciekawej Opinii Prawnej kancelarii Maruta Wachta sp. j.. (dalej odpowiednio Opinia i Kancelaria) na temat MOŻLIWOŚCI I SPOSOBU WYKORZYSTANIA METODYKI AGILE W PROJEKTACH INFORMATYCZNYCH REALIZOWANYCH Z ZASTOSOWANIEM USTAWY ? PRAWO ZAMÓWIEŃ PUBLICZNYCH. Kluczowe pojęcia i definicje Zanim się odniosę do Opinii, najpierw klika słów na temat zwinnego realizowania projektów. Jak rzadko, posłużę się Wikipedią, gdyż pojęcie "metody zwinne" nie ma ścisłej definicji, Manifest Agile zaś jest na tyle ogólny, że nie jest możliwe użycie go jako definicji. Po drugie Wikipedia jest powszechnie przywoływana jako źródło w środowiskach związanych ze…

Czytaj dalejAgile w PZP

Domain-Specific Conceptual Modeling czyli logika wydzielona z modelu procesu

Tę recenzje książki zacznę nieco inaczej. Swego czasu pisałem, że warto stosować reguły biznesowe w modelowaniu procesów. Zwracałem uwagę na to, że nie ma sensu modelowanie decyzji w BPMN... ... bo to prowadzi do masakrycznej złożoności diagramów. Po drugie w każdym procesie mającym ?w sobie? zdarzenie związane z odpisaniem na pismo musielibyśmy  ?narysować? powyższy ciąg czynności. Zarządzanie zmianą w takiej dokumentacji to koszmar. Model procesu powinien zawierać wyłącznie elementarne procesy biznesowe (aktywności z ich wejściem i wyjściem):Proces biznesowy w notacji BPMN z wydzielonymi procedurą i reguła biznesową. Proces biznesowy w…

Czytaj dalejDomain-Specific Conceptual Modeling czyli logika wydzielona z modelu procesu

Strategia… w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym

Tym razem natchnieniem do napisania tego tekstu była krótka dyskusja w internecie i to stwierdzenie jednego z jej uczestników: "...strategia budowana przez Zarząd". Gdyby chciał Pan na tym bazować to w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym. Nawet jeśli któraś z tych firm ma strategię (lub wydaje się jej, że ma) brzmi ona mniej więcej tak: "W najwyższym możliwym stopniu zaspokoić potrzeby klientów przy minimalnych możliwych kosztach własnych". Obaj wiemy, że to nie jest żadna strategia. Trzeba szukać innego fundamentu. Autor tej wypowiedzi ma…

Czytaj dalejStrategia… w przypadku 90% małych i średnich firm w Polsce bazowałby Pan na niczym

Biznesowy (kanoniczny) model danych – nie chcemy

Nadal obserwuję to, że model relacyjny i "tworzenie bazowych modeli danych na etapie analizy wymagań" (kanoniczny model danych) trzymają się twardo mimo tego, że nie wiele wnoszą do projektu a narzucają (sugerują) kiepską architekturę aplikacji z jedną relacyjna bazą danych.  Co ciekawe zaczynanie od bazy danych jest wręcz zaprzeczeniem zwinności (konieczność ukończenia projektu docelowej bazy danych przed rozpoczęciem kodowania czyli klasyka waterfall, w efekcie betonowanie stanu z dnia rozpoczęcia) mimo, że autorki artykułu piszą o sobie że są agile...) Popatrzmy na to co proponują w tym 2017 roku.: Jeśli w…

Czytaj dalejBiznesowy (kanoniczny) model danych – nie chcemy

Wymagania umarły. Rozwiązaniem jest cykl życia produktu

Jak to mawiał mój dawny profesor filozofii: "gdy dwóch mówi to samo to już nie jest samo".  To co nazywamy "zwinnym podejściem" to coraz częściej uznanie nieskuteczności metody polegającej na "zbieraniu wymagań" i obrona przed "obiecaniem z góry tego co ma powstać", bo nikt nie wie czym to coś będzie jak już powstanie...(o ile powstanie). Takie głosy pojawiają się coraz częściej, i to nie od wczoraj.... Dzisiaj metody oparte na abstrakcji Takie "pomysły" jak MDA (architektura bazująca na modelowaniu), MDE (inżynieria bazująca na modelowaniu), notacje BPMN, UML, SysML, SoaML i…

Czytaj dalejWymagania umarły. Rozwiązaniem jest cykl życia produktu

Koniec treści

Nie ma więcej stron do załadowania