Hver tredje er skuffet over SOA

Kun 10 procent af it-professionelle har oplevet, at SOA-projekter har givet større udbytte end forventet. Hver tredje er skuffet.

Det viser en undersøgelse gennemført af InformationWeek blandt 278 it-professionelle, der er blevet spurgt om deres erfaringer med it-projekter baseret på service orienteret arkitektur (SOA).

60 procent finder, at SOA generelt lever op til forventningerne, men kun 10 procent har oplevet bedre resultater end forventet. Den sidste tredjedel af de adspurgte er generelt skuffede over SOA.

Når en tredjedel af de adspurgte ikke har fået indfriet forventningerne til SOA, er årsagerne blandt andet, at SOA ifølge 60 procent af de adspurgte øger kompleksiteten i it-systemerne i stedet for at nedbringe den.

30 procent af de adspurgte peger på, at implementeringen af SOA har vist sig at koste mere end forventet.

Blandt de primære årsagerne til at benytte SOA nævner de adspurgte et ønske om større fleksibilitet, laver udgifter og bedre integration mellem produkter.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Frank Vilhelmsen

Det forstår jeg godt. For nogle mennesker handler SOA om at eksponere software gennem web services. I mange tilfælde forventer de forskellige WS-* standarter og de er parat til accepterer alle former for transport(XML over http). For nogle mennesker handler SOA om en arkitektur hvori applikationer forsvinder. I stedet bygges forretnings funktionaliteten over et sæt af services adskilt fra datagrundlaget.

For nogle betyder SOA at systemer kan kommunikere med andre systemer på en standardiseret strukturel form. Det foregår næsten altid med XML. I den værste form er det reelt CORBA med “Tuborg klammer” mens den sofistikerede form er konstrueret specielt som forretningens rygrad og alle applikationer benytter denne. Denne rygrad involverer ofte http som transport. For nogle betyder SOA at der kan sendes asynkrone beskeder mellem forskellige systemer. Dette kan betragtes som EAI system uden en ressource tung forhandler som mellemled.

Jeg har hørt folk tale om alle de fede ting ved SOA. SOA separere data fra proces, at SOA kombinere data med proces, at SOA kun bruger web standarder, at SOA er uafhængig af web standarder, at SOA er asynkron, at SOA er synkron, at SOA er løst koblet, at SOA så løst koblet at det kan være svært at samle dem osv.

Jeg er ikke skuffet! Jeg er bare træt af SOA.

  • 0
  • 0
#2 Kim Madsen

Jeg har også set det ene SOA projekt efter det andet med elendige svartider, over komplicerede systemer og ustabile elementer i løsningen.

Årsagen er ofte at man tager udgangspunkt i black box open source. I.e. man vælger kasser fra en lang række forskellige leverandører, der efter sigene kan løse en specifik opgave, og så klistrer dem sammen i håb om at en løsning nemt og hurtigt er tilstede.

I praksis sker der det at tingene ikke helt virker som forventet, der er nogle funktionelle krav der ikke helt bliver opfyldt etc. og man derfor er nødt til enten at forsøge at ændre i den sorte kasse, med alle de vedligeholdelses mæssige problemer det giver, eller at hægte flere, nu hjemmelavede, kasser ind i løsningen for at kompensere for den manglende funktionalitet.

Det kan definitivt lade sig gøre at levere virkeligt gode SOA løsninger, men kun hvis man tænker sig grundigt om, og undlader at lade sig besnære af de fine salgstaler der florerer vedr. standard produkter.

Der er foreksempel mange tilfredse kunder (via andre software huse) kørende på denne SOA løsning til Delphi, kbmMW (www.components4developers.com). Årsagen er at der er en god intern integration og fleksibilitet, men uden at ofre udvikler venligheden med unødvendige features og tænkte cases. Det er udviklet med praktiske situationer in mente. Vi anbefaler selvfølgelig ikke at bruge XML over HTTP som transport formatet mellem kendte kasser i løsningen, hvor der er fuld kontrol, men istedet at benytte det meget hurtigere og effektive binære transport format, som iøvrigt også er portabelt og kan benyttes fra Java, C, C#, PHP m.m. I de situationer hvor integrationen skal foregå med kasser som der ikke er kontrol over (typisk eksterne leverandører eller kunder etc.) kan man uden problemer tilføje SOAP eller XML over HTTP el. andre som et alternativ i løsningen, uden at det kræver nogen form for omprogrammering eller lign. Plug and play så lang hen ad vejen som muligt.

med venlig hilsen

Kim Madsen kbm@kbmitexperts.dk

  • 0
  • 0
Log ind eller Opret konto for at kommentere