Gjenbrukbare Web Services i klesskapet

Jeg er opptatt av gjenbruk på mange områder. Jeg sorterer søppel og prøver å ikke kjøpe for mange nye klær. Men jeg er ikke flink til å sy, så klær som burde vært reparert eller omsydd ligger i skapet og tar plass.

Utfordringen med gjenbruk av Web Services kan sammenlignes med å bruke de klærne man har. Er en tjeneste ødelagt, har det oppstått feil, så reparerer vi den. På dette området kan vi sy og reparere.

Hvordan kan klesmetaforen lære oss om gjenbruk av tjenester?

Design og domenemodell

Man skal jo kjøpe mindre klær, både av hensyn til økonomien og miljøet. Med Web Services handler gjenbruk om å lage tjenester som kan brukes av flere.

En løsning når det gjelder klær er å skaffe seg en basisgarderobe. En basisgarderobe er et grunnsett med klær som passer sammen og kan brukes til mange antrekk. Fargene skal passe sammen, og de skal være solide sånn at de ikke må byttes ut så ofte. Så kan man heller utvide med småting for forandringens skyld.

I SOA-verden kan man utvikle ett sett med grunntjenester, som dekker de grunnleggende behov. Gjerne beskrevet ved hjelp av en domenemodell. Domenemodellen definerer hva en kunde er for oss, hva en konto er, hva en forsikring er, i vår organisasjon.

Har du domenemodellen kan du enkelt lage helhetlige tjenester, som egner seg for gjenbruk. Får du bestilling på en endring kan du slå opp i modellen og se hvor endringen hører hjemme.

En løsning når det gjelder klær er å skaffe seg en basisgarderobe. I SOA-verden kan man utvikle ett sett med grunntjenester, som dekker de grunnleggende behov.

Domenemodellen og tjenestene må designes ut fra hva som er kundenes, brukernes og forretningens behov. Hva er det vi ønsker å presentere for kunder og brukere? Det er fort gjort å bli opphengt i hva slags muligheter som finnes. Designer du ut fra hva fagsystemet kan levere er det lett å glemme å ha fokus på det som gir forretningsverdi.

Det kan være en stor engangskostnad å kjøpe basisgarderoben. Klærne i garderoben skal være solide og nøye utvalgte. Domenemodellen tar tid å lage fordi det er så mange som må involveres og som skal bli enige. Det er som om du skulle kjøpt basisgarderobe sammen med hele slekta, på deling.

Det er ofte ikke aktuelt å kaste det man har for å lage eller kjøpe alt nytt. Du trenger å vite hva som finnes fra før.

Struktur og oversikt

For at tjenester skal kunne brukes av flere trengs en oversikt over hva som finnes fra før.

Når du står i butikken og ser på en fin svart genser, så vet du at det trenger du ikke - for det har du i skapet. Den du har hjemme er kanskje ikke helt perfekt for formålet, lørdagskveld for eksempel, ettersom det er en hverdagsgenser. Men du kan utvide den med et skjerf, så oppfyller den det behovet også.

Det samme gjelder for Web Services. Dersom noen trenger å bruke tjenesten til et litt annet formål enn den er laget for, så kan den enkelt og billig utvides. Før helga.

Der jeg jobber har vi en oversikt over alle Web Services som er tilgjengelig. Den ser for eksempel ut som i figuren under.

Figur 1: Utsnitt av oversikt over tilgjengelige Web Services

Figur 1: Utsnitt av oversikt over tilgjengelige Web Services

I lista er det nesten 200 tjenester. Dette er for mye til å bla igjennom når man trenger noe kjapt. Da grupperer vi. Etter gjennomgangen og ryddingen i skapet har du sortert klærne, og har full oversikt. For eksempel har du lagt klærne i hyller eller esker.

Her er et utvalg av vår gruppering:

Figur 2: Utvalg av grupperte Web services

Figur 2: Utvalg av grupperte Web services

Ved hjelp av gruppering er det lettere å finne noe som ligner på det du trenger, selv om du kanskje må åpne flere esker. Hva slags informasjonsarkitektur har du valgt? Har du både en eske som heter sommerklær og en som heter gensere. Hvor ligger da den tynne, hvite genseren, som passer å bruke på sommerkveldene?

For all gruppering gjelder det at man må tenke informasjonsarkitektur, også for gruppering av Web Services.

Vi vet hvilken type begreper som skal brukes når vi lager nye pakker, og vi endrer pakkenavn når det kan gjøres uten for mye støy. Litt og litt nærmer vi oss en gruppering der alle tjenester kan finnes ut fra funksjonalitet

I eksemplet over har noen pakker navn etter prosjektet de ble utviklet i, noen navn antyder hvilken funksjonalitet som finnes, og noen sier hvilket fagsystem de er knyttet til.

For oss som jobber med disse tjenestene til daglig er det greit å finne fram, selv om vi bruker mer og mer tid på å hjelpe andre å lete.

Løsningen er å lage et et målbilde for hvordan informasjonsstrukturen skal se ut framover. Vi vet hvilken type begreper som skal brukes når vi lager nye pakker, og vi endrer pakkenavn når det kan gjøres uten for mye støy. Litt og litt nærmer vi oss en gruppering der alle tjenester kan finnes ut fra funksjonalitet.

Hva hindrer gjenbruk

Regelen er å utvide heller enn å lage nytt. Når en designer tjenester bør en tenke på hva slags funksjonalitet og hvilke data konsumentene trenger uavhengig av hvilket fagsystem det hentes fra. Likevel er det en tendens til at de tjenestene vi har er tett knyttet til fagsystem. For eksempel “hente kunde fra Evry”, “hente kunde fra datavarehuset”, og “hente kunde fra Brønnøysundregistrene”.

Forståelsen for gjenbruk har det tatt tid å få inn hos alle, akkurat som at det fortsatt er mange som ikke tenker gjenbruk når de står i klesbutikken.

En bør tenke på hva slags funksjonalitet og hvilke data konsumentene trenger, uavhengig av hvilket fagsystem det hentes fra.

En mulig årsak er at når man har det travelt får man "tunnelsyn". Vi vil gjerne designe gjenbrukbare tjenester, men arkitekter i prosjekter har tidsfrister som gjør at de er sterkt fokusert på behovet til den ene konsumenten, og det ene fagsystemet.

Det samme kan oppstå når en kollega må ha ny kjole til julebordet, og det haster. Hun har ikke tid til å se igjennom klesskapet om det finnes en kjole som kan oppgraderes, selv om det kunne vært gjort mye billigere enn å kjøpe ny.

En mulig årsak til at det fortsatt blir sånn er at når man har det travelt får man tunnelsyn.

I et prosjekt kan det lønne seg å bruke litt tid på å se om noe vi har fra før kan utvides, selv om det ikke er så enkelt å finne fram i grupperingen.

Hvordan lage gjenbrukbare Web Services?

Det er ikke alltid man kan starte fra scratch og gjøre det riktig fra starten. Det er ikke uvanlig at en informasjonsmengde er liten i utgangspunktet, sånn at man ikke er fokusert på informasjonsarkitektur og design. Behovet for oversikter kommer etter hvert, når det begynner å bli en uoversiktlig mengde.

Design og domenemodell

Om du ikke kan starte med å designe hele domenet, så plukk ut et viktig område og begynn med det. Snakk med de som vet hva forretningen ønsker og hva brukerne trenger. Bestem hvordan dette området skal se ut, og sørg for nyutvikling skjer i henhold til hva du har bestemt. Refactoring kan gjøres også på Web Services, i henhold til nye krav.

Gi prosjekter mandat til å se ut over sitt konkrete behov
Spør om de har vurdert om noe kan utvides i stedet for å lage nytt. Sørg for at de designer tjenester som kan brukes av flere. Bruk dine/forretningens begreper, ikke fagsystemets.

Jobb med brukernes behov, og løsriv deg fra hva hvert fagsystem kan levere.
Konsumentene skal ikke trenge å vite hvor data kommer fra. De skal stole på at du leverer det de trenger, og at du fletter sammen data fra flere fagsystemer om det er nødvendig.

Lag en informasjonsstruktur som er lett å finne fram i, og som har gode entydige begreper.
Det finnes eksperter på informasjonsstruktur, design og domenemodellering som kan hjelpe deg i gang.

Alternativet er å bruke viljen. Å bestemme deg for å gå igjennom klesskapet hver gang du lurer på om du trenger noe nytt. Viser det seg at du har noe som kan utvides har du tjent inn tiden du brukte, og du har kanskje ryddet litt mer underveis.

Hvordan jobber du med gjenbruk?