Eksperter på tjenesteorientert arkitektur – SOA eller «service oriented architecture» – som har sammenfattet erfaringene fra denne motens første år, advarer at gevinsten er avhengig av at man bygger tjenester som faller sammen med bedriftens forretningsmodell. Ellers vil utviklingen i beste fall være bortkastet, i verste fall føre til ustabile og upålitelige tjenester som er vanskelige å holde styr på.
Dette var budskapet på IBMs SOA-konferanse i Oslo i april: SOA dreier seg primært om forretningsdrift. Det er ikke en lur måte å lage IT-løsninger på. Det er en videreutvikling av objekttankegangen, anvendt på forretningsprosesser. Det er et behov som forretningen stiller til IT-avdelingen, ikke en tjeneste som IT-avdelingen tilbyr forretningen.
– SOA dreier seg om å utvikle forretningskomponenter med tanke på at nye løsninger kan utvikles raskere og mer effektivt, i tråd med forretningens behov, understreker IBM-erne Brian Safron og Greg Rader, henholdsvis global sjef for SOA-marketing og løsningsarkitekt, i samtale med digi.no.
De mener SOA kom i forbindelse med en erkjennelse av at IT ikke hadde holdt tritt med utviklingen i forretningsverdenen.
– Globaliseringen av økonomien skaper et behov for å endre forretningsmodeller og utnytte nye muligheter langt raskere enn tidligere. Da kreves fleksibilitet av IT-systemene som skal støtte opp om forretningsvirksomheten. Ubøyelige IT-systemer undergraver konkurranseevne og fornyelse rundt nye forretningsprosesser, poengterer de to. Globaliseringen og vår nye flate verden gjør ineffektive IT-systemer enda mer kostbare for bedriften. Selve poenget med SOA er en løsning der IT strengt underordnes forretningen.
Safron oppfatter SOA som et evolusjonært fenomen.
– Arkitekturen kommer fra verdenen med komponenter, objekter og distribuert teknologi. Men vi må spørre oss: Føler vi virkelig at bedrifter får den typen gjenbruk vi hadde håpet på? Objekter er det riktige utgangspunktet for hvordan dette skal løses teknisk. Men erfaringene viser at de fleste objektene som tilbys forretningen, ikke er definert som forretningsobjekter. Bare en liten gruppe forstår hva det enkelte objektet er til for. Forretningsfolkene gjør det ikke. Objektene blander som oftest forretning og teknologi. Det er ikke definert som tjenester, og de ligger på et for lavt nivå for å kunne fungere som tjenester.
En annen erfaring som Safron trekker fram, er at objektorientering er fokusert på struktur. Det svarer ikke til forretningens interesse for prosesser og dynamikk.
– Nøkkelen er gjenbruk. SOA betyr gjenbruk av noe som trengs i flere forretningsprosesser. Da må det fokuseres på grensesnittet, ikke på implementeringen. Implementeringen kan forandre seg. Kredittsjekk er en gjenbrukbar tjeneste. Den beste måten å gjennomføre kredittsjekk kan endre seg over tid. Det betyr at måten tjenesten implementeres på, må endres. Men grensesnittet til tjenesten behøver ikke å endres, fordi selve oppgaven ikke er endret. Dette er forskjellen mellom å tenke forretningsmessig, og å tenke teknologisk.
Rader mener dette er essensen i SOA: Gi objektene en oppførsel – en funksjon – som defineres i form av hva den bidrar med til forretningen. SOA-objekter inngår i en forretningsmodell, og denne skal være fri for tekniske detaljer.
– SOA skal gi forretningen og informasjonsteknologien en felles plantegning, med felles plattform og ordbruk. Da kan man kommunisere på et nivå som gjør gjenbruk mulig.
Dette gjør SOA til vesensforskjellig fra andre og tidligere angrepsmåter.
– Corba er et eksempel på at objekter ble for tett knyttet til sin tekniske implementering. En av årsakene var mangel på teknologiske standarder. Corba-objekter kan ikke brukes teknologinøytralt. De krever kunnskaper om opphavet. I SOA heter det klart: Du kan ikke kreve av to systemer som utveksler tjenester, at de skal vite om hverandre.
Det er lettere å gripe dette i teori enn i praksis. Hele utviklingskulturen har vært bundet opp i at brukerne sier hva de vil ha, og så implementeres det av IT-folk. Nå må brukerne selv se for seg hva de vil ha i form av gjenbrukbare tjenester. Og de må få med seg IT-folkene på hva som er mulig å definere som tjeneste slik at alle teknologiske løsninger er kapslet inne i tjenesteobjektet for å der å implementeres på best mulig måte, uten at det gjør noe forskjell for applikasjonene som skal bruke det.
– Man må starte med å gjøre systemene i bakkant tilgjengelige som tjenester, sier Safron. – Start med én tjeneste, så kan du legge til en og enda en. Test dem etter hvert som du lager dem. Iterasjoner er nøkkelen. Tenk ikke at det skal lages én stor applikasjon. Tenk modulært og tjenesteorientert. Rull ut etter hvert som tjenestene blir ferdige.
Safron mener at kravspesifikasjoner ofte inneholder selvmotsigelser, og at det er sjelden de over tid gjenspeiler en organisasjons strategi.
– Når du skal avgjøre hva du skal starte med, må du ta utgangspunkt i forretningen. Noen ser på applikasjonene de har, og tar sikte på å dele dem opp i tjenester. Det er ikke veien å gå.
Rader er spesielt opptatt av hvordan SOA-prosjekter skal ledes, de amerikanerne kaller «governance».
– Tilnærmingen må defineres. En mulighet er å bygge på en modell som klargjør eierforholdene til forskjellige ressurser: Hvem eier forretningsprosessene og hvem eier programvaren. Å kartlegge samspillet mellom applikasjonene og forretningsprosessene hjelper til å oppdage hvor mulighetene ligger, hvilke kandidater man har for å utvikle til tjenester.
En slik kartlegging kan bidra til at man avdekker parallelle funksjoner internt i bedriften. I stedet ved å holde fast ved denne formen for dobbeltarbeid, kan man lage tjenester som begge kan bruke. Mye forretningsfornyelse stammer fra denne formen for integrering.
– Det er i dag populært å snakke om BPM [business process management, altså styring av forretningsprosesser]. I en SOA-kontekst får BPM en ny betydning: Evnen til forandring, til å gjennomføre nye prosesser i framtiden. Et annet bilde er at SOA dreier seg om å legge opp nye ledninger til prosessene. Det er i forandringer SOA kommer mest synlig til nytte.
Det Safron mener med det siste er at bedrifter som har tilrettelagt sine systemer med tanke på SOA, raskt kan bygge nye forretningsmuligheter ved å kombinere tjenester.
– Når flyoperatørene begynte å se på reiser fra brukernes ståsted, så de at det hele dreier seg om en prosess med mange mulige tjenester. De som var i stand til å bygge nye produkter der kundene kunne velge ikke bare fly, men også leiebil, overnatting, togtransport med mer, fikk en fordel.
Safron og Rader mener SOA dreier seg om å være beredt på å møte både forutsigbare og uforutsigbare forandringer.
– Det er en åpen arkitektur med maksimal fleksibilitet. Det lar banker tilby sluttbrukertjenester samtidig som de uanfektet kan bedre hvordan de implementeres, og tilby dem med stadig nye grensesnitt, for eksempel ikke bare via PC men også over telefon eller over mobil. Innen oppkjøp og konsolidering betyr SOA at integrering av produkter og tjenester kan gå mye raskere.
– Hva er det så man ikke skal gjøre?
Rader og Safron svarer blant annet med disse åtte punktene:
- Ikke utsett beslutningen om hvordan SOA-prosjektet skal ledes og styres. Det omfatter også hvem som skal betale hva.
- Ikke utsett tidspunktet der en skal trekke inn hele bedriften. Legg opp til at informasjonsmodellen skal være felles, og ha en klar definisjon av modellen for forretningsprosessene.
- Ikke lag for mange tjenester. Hold dere til det som er riktig for forretningen, og til det som faktisk kan gjenbrukes.
- Ikke glem at det er et lag med forretningslogikk bak hver tjeneste.
- Ikke forkast forretningsentiteter som kan gjenbrukes. Noen koder om overflaten fordi de tenker at har skal ting deles opp i komponenter. Men man må ikke lage en ny tjeneste for en funksjon som allerede er del av en tjeneste.
- Ikke skap en mengde begrensede tjenester som krever omfattende koreografi: Det fungerer dårlig i praksis, og det er vanskelig å kommunisere hva de enkelte tjenestene faktisk gjør.
- Legg grensesnittet tilstrekkelig høyt slik at man unngår skravl mellom mange tjenester i det som skulle vært én tjeneste.
- Ikke bygg på standarder for web services for å lage punkt-til-punkt forbindelser mellom applikasjoner. Det er «pre-SOA-tenking». SOA krever en ESB [enterprise software bus].
Les også:
- [23.05.2007] HP trapper opp innsatsen innen SOA
- [03.05.2007] SOA-pionerer er utsatt for kostnadssmell
- [26.04.2007] Skal utvikle Norges nye pensjonsportal
- [24.04.2007] Mangel på visjoner kan felle IT-bransjen
- [10.01.2007] Hva er skrittet etter åpne standarder?
- [10.01.2007] Råder norske IT-folk til å droppe programmering
