Jeg må sige, at jeg er ret uenig i den påstand.

Jeg er enig så langt, at (forretnings)services selvfølgelig bør tage sig udgangspunkt i forretningen. IT-afdelingen (eller IT-leverandøren) skal selvfølgelig ikke definere forretningen.

Omvendt, så er det afgørende, at forretningen ikke bare ender med at "kaste krav over hegnet" som IT-folkene så skal implementere. På den måde opnår man bare fordyrende re-implementeringer af eksisterende funktionalitet, services der designes efter skiftende modeluner, eller services der passer meget dårligt ift. f.eks. sikkerhedskrav og krav om performance. Der er brugt for en konstant dialog mellem IT og forretning.

Det er vel også derfor, at arkitektur (på flere niveauer) er indtænkt allerede tidligt i projektmodellen i mange modne organisationer.

Præcis det jeg tænkte da jeg læste Henriks indlæg. Jeg tror umiddelbart at god IT-teknologi kommer af et fornuftigt samarbejde og forståelse for blandingen af IT og forretning. Det er vigtigt at finde et passende kompromis mellem at IT-systemerne skal nærme sig forretningen -- men også at forretningen kan vinde ved at nærme sig IT-systemerne. Man kan systematisk procesoptimere efter at manuelle arbejdsopgaver kan automatiseres.

Personligt tror jeg ikke at stakken af XML/SOAP/WSDL/UDDI bliver vinderen. Det er helt tydeligt at REST/JSON eller et andet simpelt format på sigt vinder. Grunden er simpel: REST/JSON kan implementeres af en kompetent programmør på en eftermiddag. SOAP-stakken tager flere mandeår (Og det er ikke løgn). Men du kan sagtens drive en SOA-style IT-infrastruktur på REST/JSON eller lignende så der er ikke ligefrem nogen problemer i det med det perspektiv.

Ideen i at skrive sin arkitektur omkring webservices er ikke dårlig: Systemmæssigt opnår du muligheden for at give Java og C# sparket for visse delsystemer hvor det ikke giver mening (Web-grænseflader lader sig meget nemmere beskrive i Ruby, Python eller PHP f.eks. - så sproginteroperabilitet er væsentligt). Samtidigt får du mulighed for at benytte de "tunge" sprog hvor det giver mening: I backenden af systemet hvor performance har stor betydning.

Det næste skridt er at du kan eksportere dele af dit API til 3.-part.

Jeg tænkte præcist det samme, da jeg læste Henrik's indlæg.

En ideel model efter min erfaring er, at man benytter SCRUM som udviklingsmetode med en løsningsarkitekt som nøgleperson til implementeringen; dette sikre konsensus i teamet.

Grunden til fokuset på løsningsarkitekten er, at ikke alle udviklere besider kompetencerne til at håndtere overordnet software arkitektur, der dels tilgodeser forretningen dynamiske ønsker, samt sikre - med tid for øje - en fornuftig implementering af løsningen (best practises, patterns, conventions, idioms).

Alt for ofte har jeg erfaret udviklere der rask væk koder hvad forretningen ønsker (uden omtanke for applikationen), men fordobler (hvis ikke mere) implementeringen af nye tiltag, og værste fald, gør applikationen ustabil med tab til følge for forretningen.

Nøgelordet her er SCRUM; så skal forretningen nok få deres services jf. konsensus med teamet.

Mit væsentlige budskab i bloggen er at forretningen skal forstå at services er afgørende for virksomehdens knkurreceevne og ikke blot betragte SOA som en måde at modernisere maskinrummet på og det derfor alene er noget for teknikerne.

jeg er jo ikke uenig i at en veldefineret serevice sker i samarbejde med it og services kræver de sædvanlige it-dyder.

Jeg synes at REST vs SOAP diskussionen er uinteressant. De har hver deres fordele og ulemper. Hvor REST rimært tilbyder er hurtig og let måde at få gjort service tilgængelige på, så passer SOAP-service i mange tilfælde bedre når der er behov for standardiseret sikkerhed, reliability osv. på tværs af organisationer.

Jeg har altid haft det frygteligt svært med at opdele en virksomhed i “forretningen og IT”. IT er og bliver en (stadig større) del af forretningen. Opdelingen er ligeså så dum som at sige, at virksomheden består af ”salg og de andre” eller ”marketing og de jordnære”.

Netop når vi taler om serviceorientering er det oplagt at tænke i en symbiose af mennesker, processer og teknologi, hvor det ikke er et element, der går forud for de andre, men hvor det er samspillet, der gør udslaget.

Det betyder så, at alle traditionelt forretningsorienterede mennesker kommer til at tilegne sig IT-forståelse ligesom traditionelt teknologiorienterede mennesker kommer til at tilegne sig forretningsforståelse.

Ja, men jeg har ikke en bedre teminolgi for medarbejdere der forstår teknologiens muligheder (og begrænsninger) og folk der ikke forstår det.

Jeg er så helt cirkulært enig i, at mange it-folk er gode til at forstå forretningen samt at mange fra forretningen vælger at betragte it som noget teknisk, der ikke vedkommer dem.

Mange fra forretningen har forstået mulighederne i hjemmesiderne (også de ikke it-kyndige), men de skal til at forstå at services bliver lige så uundværlige for virksomheden som hjemmesiderne er i dag.