🚀 go-pugleaf

Użytkownik "ToJaJarek" <tojajarek@gmail.com> napisał w wiadomości 
news: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.