Lige siden Anne Thomas Manes fra Burton Group annoncerede, at SOA is dead på sin blog i januar, har den vidt omtalte blogpost været kendt som 'The SOA Obituary' - nekrologen over SOA. Omtalen nåede også til v2.
Anne måtte allerede få dage efter forsøge at korrigere de mange misfortolkninger af titlen på hendes blogpost - flere lod til at stamme fra folk som netop ikke var nået videre end til at blot at læse titlen. Mange glemte endda sidste halvdel af nekrologens titel ''; Long Live Services' og forstod ikke, at selvom SOA måske havde fejlet som teknologisk fix og som en ren it-øvelse, så havde SOA-mønstrene og -principperne stadigt et langt liv foran sig.
'Big SOA' is dead, but 'Little SOA' will survive var den ene misforståelse, der trivedes. SOA skal stadigt gøres ordentligt og Annes budskab var at Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change. Ikke nødvendigvis ved at indkøbe en (næsten) fiks og (næsten) færdig SOA-stak fra din lokale forhandler, men ved at anvende SOA-mønstre, hvilket jeg også har været fortaler for, fx i et foredrag hos Ditmer i sommers.
REST will fix everything var den anden almindelige misforståelse. REST er lige så slem som SOA hvis det bruges som et teknologisk fix.
På grund at hendes klare og velfunderede meninger (eller med andre ord: fordi hun mener det samme som mig) var Anne allerede inde på min radar da jeg fik en unik mulighed for at få en nærmere snak med hende i går. Vi var en lille sluttet kreds: Anne Thomas Manes, Burton Groups europæiske salgschef, mig selv og en god kollega fra Rambøll Management Consulting, der spiste en hyggelig frokost med udsigt over havnen mens Anne fortalte om sin forskning og sit indlæg på JAOO dagen efter (dvs. i dag, 2009-10-06)
Anne opererer med tre kategorier af 'assets' som tilsammen udgør en virksomheds evne til at levere sine services:
Det er interessant, at hun i den sammenhæng fortalte at
Citat:
REST is an architectural style oriented at communicating information about things. Not a style for modelling processes or capabilities. REST is a sort of a 'Thing Oriented Architecture'.
Nu virkede hun bestemt ikke som om at hun ville opfinde et nyt buzzword, Thing Oriented Architecture eller TOA. I stedet ville hun pege på hvor REST kan være en styrke men også hvor modellen ikke længere holder. Som fx de gutter, der forsøger at lave et REST-interface til en JMS-kø: Her er de ude i et misbrug som ikke gør nogen en tjeneste.
En anden pointe var 'SOA for reuse' Forget it. SOAs promise is agility' hvilket jo er en god vinkel på en anden spændende diskussion, der foregår her på sitet.
JAOO har et spor om Cloud computing, kan jeg se af programmet. Annes punch-line om cloud computing er, at 'You cannot do Cloud without SOA'. Det bliver interessant at høre hvordan det bliver modtaget på konferencen.
Et tilsvarende, men lignende, budskab er at 'You cannot do SOA without EA'. Og det er måske i virkeligheden den vigtigste pointe, hun har. Hvis man ikke sikrer at it-afdelingen laver det rigtige og sikrer at der er overensstemmelse mellem strategi, forretning og it, så kan selv teknisk velfungerende projekter ikke lykkes.
Det vil sige, at en af de mest teknisk velfunderede analytikere i branchen er kommet til den konklusion, at teknik faktisk er lige meget!
Ikke nogen kedelig frokost. Hun bliver helt klart inviteret på en bid mad næste gang hun er i byen.
Opdateret 2009-10-7: Nu også en artikel med hende her: "SOA-dræber: Fremtiden hedder ressourceorienteret programmering": http://www.version2.dk/artikel/12404-soa-draeber-fremtiden-hedder-ressou...
(Artiklen var publiceret mens Peter var ansat ved Rambøll Management Consulting)
Der er flere forklaringer derude på, hvad der gik galt (i det omfang, at det er så galt).
Selvom det fuldt ud er muligt at tale SOA uden nødvendigvis at tale IT, er der ingen, der gør det.
”Things” bliver i IT-systemer repræsenteret af data og i en nylig blog af David Linthicum siges det: Lack of Focus on Data Killing SOA
http://www.ebizq.net/blogs/linthicum/2009/07/lack_of_focus_on_data_killi...
Du beskriver det som om at genbrugelighed og agility ikke hænger sammen, men jeg vurderer at der er en klar sammenhæng.
Jeg er enig i at agility er det væsentligste budskab i SOA, men en af parameterne for at opnå dette, er genbrugelige services. Så når virksomheden har behov for at integrere med en ny partner, genbruger de den eksisterende service, som forhåbentlig er baseret på den pågældende industris standarder. Industristandarderne gør forhåbentlig at det også er genbrug for partneren
Så agility og genbrug er ikke sidestillede, men genbrug er et middel til at opnå den ønskede agility
Anne Manes nævnte også at både udviklingen af information og processer er vigtig. Ofte fokuseres der for meget på processerne, men man kan ikke komme langt med dem uden også at have fået data på plads.
Flere SOA-projekter, som jeg har set, drives faktisk af et ønske om Business Intelligence, fx om proces-data.
Du kommer jo heller ikke uden om at en god service skal være designet i den rette granularitet og også her er en forståelse af informationer/begreber/data essentiel.
Så agility og genbrug er ikke sidestillede, men genbrug er et middel til at opnå den ønskede agility
Der vil altid være en kobling mellem forbrugeren og servicen (om ikke andet på semantisk niveau). Desto flere forbrugere der deler en service, desto hårdere er den "bundet" op på de use-cases den indgår i (uanset om disse cases er eksplicit beskrevet eller ej).
Man kan uden tvivl opnå en hurtigere time-to-market når man kan genbruge en service. Men hvordan undgår man at en service der bruges af flere forskellige forbrugere ikke bliver mindre agil?
Jeg formoder at en del af forklaringen handler om at undgå lag-delte services og at definere services der svarer omtrent til forretningshændelser. Men det eliminerer efter min mening ikke det grundlæggende problem - at delte services er sværere at ændre, uden at skabe kaskadevise ændringer.
Jeg blev i går spurgt om hvorfor jeg havde tagget indlægget med ".net" og "java". Godt spørgsmål. Afsnittet om det var blevet redigeret ud, men her er den:
.Net eller java? En klassisk kamp i en it-funktion. Men Anne Manes' mening er klar: Det er strategisk set fuldstændigt lige meget - ingen af dem har en forretningsstrategisk fordel over den anden. Hun refererede til en rapport som Burton Group havde udgivet (som dog koster penge at se): http://www.burtongroup.com/research/PublicDocument.aspx?cid=1562
PS. Se også artiklen: http://www.v2.dk/artikel/12404-soa-draeber-fremtiden-hedder-ressourceori...
