Services kræver forretnings-kompetence ikke it-kompetence
Da begrebet serviceorientering kom frem, var budskabet, at man skulle serviceorientere trinvist med små skridt af gangen. Dette budskab er nu næsten druknet i marketingbudskaber om at serviceorientering er en større arkitekturøvelse, typisk forankret i it-afdeling og med krav om større investeringer i nye kompetencer, teknologier og arkitekturretningslinier.
For de fleste virksomheder er dette ikke den rette måde at starte serviceorienteringen på!
Serviceorienteringen skal udgå fra forretningen ikke fra it-afdelingen (se også Har it-afdelingen kuppet SOA ?). Forretningen skal forstå, at services handler om at identificere steder, hvor virksomheden f.eks. har:
- Funktionalitet i deres it-løsning som kan genbruges i andre systemer (egne eller tredje parts) (F.eks. beregninger omkring deres produkt)
- Selvbetjeningsløsninger på deres hjemmeside, som vil give større værdi for kunden, hvis funktionaliteten var tilgængelige direkte i kundens eget it-system (F.eks. en track and trace løsning)
- Data til rådighed som kan have værdi for andre. (F.eks. ordrehistorik eller information om ens produkter)
For hver at disse potentielle services bør forretningen opstille en business case, der f.eks. involverer
- Hvad betyder det, at det bliver lettere at handle med virksomheden
- Hvad betyder det, at kunden (eller kundens kunder) knyttes tættere til virksomheden
- Hvad betyder det, hvis ens forhandlere kan service de fælles kunder bedre
- Hvad betyder det, hvis ens produkter lettere kan integreres i andres ydelser
I den første del af serviceorienteringen (jeg kalder det 'det organisk stadie'), gælder det ikke om at lave en ny it-arkitektur. Det gælder om at få lavet de services, som giver værdi for virksomhedens kunder. Bare en/få af gangen i henhold til hvor attraktiv business casen er
Når virksomheden har et antal services kørende, kan den påbegynde beslutningen, om services skal være den fremherskende it-arkitektur i virksomheden eller services skal fungere som supplement til en anden it-arkitektur.
Det er mit budskab, at den naturlige næste udvikling på internettet er at udbyde forretningsfunktionalitet som services. Services der integreres direkte i det system, hvor brugeren har behov for funktionaliteten og ikke kun på virksomhedens hjemmeside.
Udbud af de rette services vil være kritiske for virksomhedens fremtidige konkurrenceevne, da det vil have betydning for, hvor let og attraktivt det er at handle med virksomheden.
Det kræver derfor forretnings-kompetence ikke it-kmpetence at forstå, hvordan virksomheden kan udnytte services
Kommentarer (7)
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.
-
0 -
0
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.
-
0
-
0
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.
-
0
-
0
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.
-
0
-
0
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.
-
0
-
0
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.
-
0
-
0
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.
-
0
-
0
Tilføj kommentar
