Temat: Połowa projektów SOA kończy się porażka

http://www.infoq.com/news/2008/07/Only1

Próbka była mała więc łatwo o bład statystyczny, lub też stronniczość przy wybieraniu firm - ale to co najciekawsze to przyczyny niepowodzeń.

Polecam wszystkim przeczytanie i zastanowienie się czy podobnych objawów nie widać na własnm podwórku.

Temat: Połowa projektów SOA kończy się porażka

Jan B.:
http://www.infoq.com/news/2008/07/Only1

Próbka była mała więc łatwo o bład statystyczny, lub też stronniczość przy wybieraniu firm - ale to co najciekawsze to przyczyny niepowodzeń.

Polecam wszystkim przeczytanie i zastanowienie się czy podobnych objawów nie widać na własnm podwórku.

ciekawy artykuł, jest troche prawdy..:) no cóż, projekty informatyczne to nie tylko technologie i produkty a przede wszystkim LUDZIE... i... ich decyzje ;)

samobójem jest podjęcie decyzji o wdrożenia SOA bez fundamentalnej wiedzy o organizaji, jej kulturze, stanie, infrastrukturze (również IT) a zwłaszcza o procesach biznesowych w niej występujących...

dotychczasowe, iteracyjne podejście do budowania systemów informatycznych (Total Development) nie sprzyja wdrożeniu SOA. istnieją "drobne" różnice, niuanse w podejściu do analizy biznesowej na podstawie której zbuduje się system (aplikację użytkową) a wiedzą jaka jest niezbędna aby podjąć decyzję o wdrożeniu SOA.

żeby z sukcesem wdrożyć SOA - potrzebna jest szczególna wiedza. wiedza o procesach, aktywnościach a zwłaszcza usługach. faza inwentaryzacji i identyfikacji powinna dać odpowiedź na pytanie czy wchodzić w np. SOA i jeśli tak to w jakim zakresie. skoncentrować się należy przede wszystkim na aktorach systemu (ludzie i systemy), ich aktywnościach i procesach za które są odpowiedzialni oraz (być może najważniejsze) w jaki sposób ze sobą współpracują.

jeśli po SOAD (SOA+Design) okaże się, że z usługami jest krucho - jak można mówić o wdrożeniu takiej architektury? dla mnie osobiście - byłoby to bez sensu.

dlatego moim zdaniem tylko 1 na N projekt to "sukces" :)

Pozdrawiam!
RF

Temat: Połowa projektów SOA kończy się porażka

Wg raportów The Standish Group rozkłada się to bardzo podobnie dla całości projektów IT. Pokrywa się też sporo przyczyn porażek z obu badań :-)

Zgadzam się w 100% z Romanem - wszystko zależy od ludzi i odpowiedniego zarządzania całym projektem :)

Temat: Połowa projektów SOA kończy się porażka

Roman Frania:

projekty

informatyczne to nie tylko technologie i produkty a przede wszystkim LUDZIE... i... ich decyzje

a ja bym do tego dodał jeszcze 2 czynniki zaangażowanie i budzet

i mamy dużą szanse na sukces...

problemem wiekszosci projektów jest fakt ze ktos cos usłyszał ... coś sie spodobało to to wdrozymy... po czym taka osoba ceduje to na kogos innego kto ma to gleboko w powazaniu... i wtedy zaczynaja sie problemy w projekcie.

Temat: Połowa projektów SOA kończy się porażka

Kończą się porażką, ponieważ wdrażanie podejścia SOA, nie jest realizacją jakiegoś tam "projektu", tylko metodyka długofalowego rozwoju infrastruktury IT w korporacji w zupełnie inny sposób niż się to robiło w tej korporacji dotychczas.
Wprowadzenie SOA a tym bardziej SOA Governance zmienia w takiej korporacji dosłownie wszystko - sposób myślenia o IT jako o całości, kto z kim ma co ustalać i jak to opisać, a nawet postrzeganie kosztów rozwoju infrastruktury przez management.

W założeniach SOA, po fazie adaptacji powinno wyraźnie ograniczyć wydatki na IT, umożliwić dokonywanie zmian w oprogramowaniu w krótszym czasie, pokonać ograniczenia w rozwijaniu dużych monolitycznych systemów, i ogólnie usystematyzować IT, wprowadzając warstwę ustandaryzowanych i reużywalnych usług.
Mając wspólną platformę integracyjną, łączącą wszystkie systemy, a rozcinając połączenia punkt-punkt, niemal automatycznie (zależy od platformy) klarują się przepływy (można je zamodelować diagramami dostosowanymi do faktycznych procesów biznesowych), dostajemy za darmo monitoring, łatwość podmiany danego systemu na inny, łatwość wprowadzania dowolnych zmian w zagmatwanej infrastrukturze IT.
Trochę teoretycznie to zabrzmiało, ale ja to potwierdzam, ponieważ przerabiałem to w praktyce.
Nie ukrywam, że początki są ciężkie (nieznajomość produktu, brak fachowców, brak infrastruktury, nie wiedza "jak to być powinno", przeróbki w systemach legacy/dziedzinowych, tworzenie adapterów, warstwy usług) i z początku nie widać wartości dodanej, a wszystko działa jakby gorzej, wolniej, mniej przewidywalnie.

Jedynym problemem jaki widzę, jest umiejętne zarządzanie tym nowym tworem, wykorzystywania zalet danej platformy integracyjnej i ścisłe podążanie zasadami przyświecającymi SOA.Borys M. edytował(a) ten post dnia 01.12.09 o godzinie 16:36

Temat: Połowa projektów SOA kończy się porażka

Czytając tą grupę można dojść do wniosku, że SOA to genialny patent ...
Na temat do rozmaitych konferencji, szkoleń, prezentacji etc...
Taki mały AMWAY się z tego robi.

Stosunkowo prosta technologia, jedna z wielu, do której dorwali się marketingowcy. I tylko paru nieopatrznie zrozumiało jak to działa.
- reszta nie znalazła takiej potrzeby.

taka moja luźna dygresja :)Maciej Filipiak edytował(a) ten post dnia 01.12.09 o godzinie 16:59

Temat: Połowa projektów SOA kończy się porażka

Nie, SOA to nie technologia, tylko filozofia projektowania systemów, pewien poziom abstrakcji na poziomie którego łatwiej jest projektować różne rzeczy. SOA można realizować za pomocą różnych technologii. Z wspomnianego na początku tekstu wynika, że problem nie leży w wyborze technologii, szyny, middleware etc., tylko w rozumieniu co należy wyodrębnić jako serwis. Jest o tym dobry artykuł, może już znany na tym forym: "DOA with SOA: adopting this architectural style is no cure-all", http://queue.acm.org/detail.cfm?id=1217275.

Jestem bardziej teoretykiem, niż praktykiem w SOA. Ale zastanawia mnie:

1. czy ktoś robił badania, jakie zyski/oszczędności firmy osiągnęły po wprowadzeniu SOA w ramach firmy w stosunku do starych architektur?

2. W jakim stopniu wykorzystywane są serwisy z poza firmy, czyli re-use zewnętrznych serwisów do realizacji własnej logiki biznesowej?

W latach osiemdziesiątych robiono takie badania przy re-use software. Pytano, jakie są oszczędności z tytułu wprowadzenia bibliotek istniejących komponentów i używania ich zamiast tworzenia od komponentów od nowa (polecam tekst: "Implementing faceted classification for software reuse", http://scholar.google.it/scholar?cluster=3140579855964.... Dlatego ciekaw jestem, czy ktoś robi podobne badania dla SOA.Maciej Gawinecki edytował(a) ten post dnia 26.01.10 o godzinie 22:26