🚀 go-pugleaf

On 25 Cze, 13:44, "Filip Sielimowicz" <sie...@wp.pl> wrote:
> Użytkownik "ToJaJarek" <tojaja...@gmail.com> napisał w wiadomościnews:1181634592.336923.219170@d30g2000prg.googlegroups.com...
>
>
>
> > ETL to nie proces biznesowy. Nie ma więc takiego problemu.
>
> > Wydaje mi się, że wiele opisów SOA to zbyt technologiczne podejście do
> > prostej w pewnym sensie idei: systemy IT powinny wspierać pojedyncze
> > procesy biznesowe a nie całe organizacje. Nawet na stronie OMG.ORG
> > jest w jednym z artykułów stwierdzenie (autor jest pracownikiem IBM,
> > niestety nie pamiętam linka do tego):  ,,SOA to nie technologia a idea
> > architektury, technologie co najwyżej ją wspierają i to na różne
> > sposoby".
>
> > Metody modelowania procesów biznesowych (ICOM, IDEF0, BPMN, inne),
> > teoria łańcucha wartości (M.Porter), zarządzanie zorientowane na
> > procesy (np. Geary Rummler, Alan Brache) jawnie oddzielają procesy od
> > zasobów je wspierających. Technologie IT to właśnie zasoby. Procesy
> > ETL to techniczny element np. hurtowni danych. Użytkownik biznesowy
> > oczekuje możliwości analizy danych, skąd i jak są one pozyskane to nie
> > jego kłopot. Zasób ma to zapewnić.  Jeżeli użyjemy słowa ,,proces" w
> > stosunku do ETL to owszem, ale jest to wewnętrzny proces systemu IT a
> > nie proces biznesowy.
>
> > Uważam, że tego typu problemy: jakim procesem jest ETL w strukturze
> > SOA to problem sztuczny i nie istniejący w sensie SOA. Być może jest
> > to efekt innego rozumienia idei SOA. SOA to usługi świadczone procesom
> > biznesowym. ETL to proces przetwarzania danych. Nawet jeżeli jego
> > implementacja wymaga znajomości jakichkolwiek reguł biznesowych (co z
> > reguły ma zresztą miejsce) to nie jest to proces biznesowy.
>
> > Ja w każdym razie w swoich projektach tak traktuję SOA.
>
> Rzeczywiście patrzę na temat zdecydowanie bardziej od strony "spodu", czyli
> technologicznie, a nie "od góry", czyli z poziomu biznesu. A poza tym SOA to
> dla
> mnie na razie teren w który wchodzę a nie znajome pole (rozpoznaję co tu
> mniej
> więcej rośnie i wygląda zazwyczaj na całkiem jadalne ...)
>
> Patrząc od tej strony, uwzględniając fakt, że architektura SOA zaczyna być
> już
> nieźle wsparta "wypasionymi" wspomagaczami (szyna ESB z otoczką: np.
> monitoring
> stanu usług - "działa"/"szlag trafił") traktuję tę architekturę jako dobry
> szkielet
> do tworzenia systemów informatycznych - niezależnie od tego, jak to wygląda
> z góry. A dokładniej: jako dobry szkielet do tego, by zmierzyć się z tematem
> wymiany starego technologicznie systemu na nowy - poprzez wyodrębnienie
> usług
> i stopniową ich wymianę. W tym kontekście usługa ma dla mnie znaczenie nie
> tyle
> jako pewna funkcja systemu, ale jako pewien hmmm ... artefakt do wytworzenia
> w ramach procesu wytwarzania. Artefakt, którym można zarządzać: badać (a
> nawet
> w sposób ciągły monitorować) jego jakość, niezależnie testować, wymieniać
> (jak się
> żarówka przepali), tworzyć na jego bazie dokumentację systemu. Przy tak
> postawionej
> definicji oczywiście istnieje duże ryzyko, że warstwa usług stanie się
> jakimś mało
> zrozumiałym (dla procesów biznesowych) zbiorem niskopoziomowych funkcji. Ten
> problem
> jednak rozwiązałbym już tylko i wyłącznie odpowiednią hierarchizacją usług:
> np. na publiczne
> (wysokopoziomowe, zrozumiałe dla biznesu) i hmmm... chronione/ukryte
> (interfejsy wewnętrzne).
> Takie podejście pozwala mi (przynajmniej pozornie ...) zminimalizować liczbę
> technologii
> (warstw technicznych, pojęć), którymi się trzeba posługiwać przy opisie
> systemu, opisie
> postępów w jego wytwarzaniu, badaniu jakości i błędów, formułowaniu
> precyzyjnych zadań.
> Czy tu jednak za bardzo nie przesadzam - tego jeszcze nie wiem.
> I w takim też sensie mnie interesuje proces ETL: wolałbym, by wpasowowywały
> się w ten
> klimat, czyli bym mógł je określać jako "usługi", które poza parametrami
> funkcjonalnymi,
> mają parametry kosztowe (wytworzenie, serwisowanie) i jakościowe oraz cechę
> łatwej
> wymienialności.
> W skrócie: wielopoziomową strukturę procesów wytwarzania systemu
> informatycznego wraz
> z jej produktami chciałbym możliwie wiernie "rzucić" na architekturę SOA,
> tak, by produkty
> tych procesów tworzyły, jeśli to ma sens, schierarchizowane usługi zamiast -
> wielopoziomowego
> systemu warstw komponentów i funkcji, gdzie każda warstwa rządzi się
> własnymi technologiami,
> prawami i jest inaczej testowana, rozumiana itp ... Oczywiście teraz mocno
> już poleciałem w przestrzeń,
> ale generalnie chodzi o to, by wykorzystać siłę architektury SOA i jej
> techniczne wspomagacze do tego,
> by silniej zintegrować z nią proces wytwórczy oprogramowania.
>
> A w szczególności: mamy problem dużego molochowatego systemu napisanego w
> starej technologii
> i stoi przed nami wyzwanie stopniowego podziału go na mniejsze kawałki.
> Sytuacja niemal benadziejna,
> jednak skoro już temat dotykamy, to chciałbym, by jeśli będą powstawać
> interfejsy wewnętrzne
> (jako podstawa do modularyzacji tego systemu), to by były one widoczne np.
> na szynie usług.

No to chyba widze wspólny mianownik tej rozmowy:
- dla mnie SOA to architektura rozwiazania
- dla Ciebie SOA to lista artefaktów
- i dla mnie i dla Ciebie (tak sądzę) SOA jest sposobem na "spis
treści" modelowania systemu, gdzie artefaktami będą i Twoje projektu
zmierzajace do kodu i moje opisujace organziację i spsób zrealziowania
wymagan na system IT.

Z mojej płaszczyzny artefaktami są np. model procesów, lista
funkjonalnosci (możłiwe że pzrypadkó użucia), diagram klas i model
danych. Dla Ciebie zmierzajaca do implementacji kontynuzajca budowy
szzcegółów architektry systemu i jego wnętrza czyli implemntacja. Może
to jest odpowiedź?

Wracając do procesu ETL to będzie to chyba problem jak zaimplementować
jeden z potrzebnych mechanizmów (usług wewnętrznych systemu), być może
chodzi o artefakt jakim będzie model tej klasy z być moze diagramem
sekwencji i diagramem czynności dla tego i współpracujących obiektów
(komponenetów).