Less is more

Hva skjer når gamle tjenester skal fases ut til fordel for nye og fagsystemets avhengigheter er dratt opp til konsumentene? Refactoring i et løst koblet tjenestemiljø kan bli en langvarig hodepine om du ikke gjorde jobben for fem år siden.

I denne artikkelen vil jeg dele noen refleksjoner over erfaringer gjort over flere år, med utvikling av web-tjenester i en organisasjon som har modnet med teknologien og som gradvis har blitt vridd over fra å være styrt av fagsystemets betingelser til å styre etter forretningens mål.

Ved å stille noen enkle spørsmål i det du designer tjenestene kan du motvirke framtidig hodepine, fremme gjenbruk og kanskje spare systemeieren din for noen vedlikeholdskostnader.

Erfaringer fra tjenesteorientering

Jeg har i en årrekke vært med på å løfte tjenester fra flere leverandører over på en tjenesteorientert plattform slik at disse kunne tilgjengeliggjøres for konsumentapplikasjoner over en sentral integrasjonsbuss.

Motivasjonen for å gjøre dette lå først og fremst i å kvitte seg med bindinger til Java-spesifikke grensesnitt. Etterhvert kom de første SOAP-tjenestene trillende. De bar preg av å være utviklet Bottom-Up, med tjenestegrensesnitt generert direkte fra EJB-implementasjoner og sterke bindinger til Axis og SOAP-RPC. Avhengighetene smittet over over på klientapplikasjonen og det utkrystalliserte seg et behov for en integrasjonsbuss for å løse opp i disse bindingene og for å etablere et kompetansemiljø på integrasjon mot de forskjellige fagsystemene organisasjonen benytter.

De første tjenestene som ble lagt ut på den nye integrasjonsbussen hadde sterke bindinger til både fagsystem og konsument. Ved tidenes morgen dro vi sågar opp XML-strukturen til fagsystemet ukritisk. Et halvår etter at konsumentene hadde tatt i bruk tjenestene kom fagsystemet med nytt grensesnitt. Siden verken det nye eller det gamle grensesnittet hadde særlig gjenbrukspotensiale ble integrasjonskostnaden duplisert opp til konsumentene.

Contract First, men..

Etter hvert som både tjenestedesignere og utviklere ble vant med formen ble de flinkere til å designe tjenestene contract-first med en viss grad av medvirkning fra konsumentsiden. Som gode skreddere tok vi mål av både konsument og fagsystem og forsøkte å finne en perfekt match, plagg for plagg uten å se den store helheten.

I årene som gikk ble det produsert tjenester litt isolert fra fagsystemet og litt løsrevet fra konsumentene, men avhengigheter fra begge skinner tydelig igjennom. Da det begynte å haste med å få funksjonaliteten ut, ble spørsmål om gjenbrukbarhet og løsriving besvart med at vi tar med alt vi tror konsumentene kan få behov for. Uten noen til å filtrere vekk unødvendige elementer ble alt tatt med.

Resirkulering av funksjonalitet

Nå står funksjonaliteten fra en EJB-basert løsning for tur til å fornyes. 15 års evolusjon, feilrettinger, midlertidige løsninger og andre endringer skal konsollideres til mer gjenbrukbare tjenester på bussen og overta mye av den funksjonaliteten vi allerede har utviklet der.

Både EJB-systemene og de nå litt eldre SOAP-tjenestene har avhengigheter til fagsystemet bak, både i attributter innen de ulike meldingene som utveksles med konsumenten og i hvilke meldinger man har behov for å utveksle. EJB-tjenestene ble utviklet i en lagdeling av en forholdsvis fet webløsning. Intensjonen den gang var å gjøre flere av tjenestene tilgjengelig for andre applikasjoner, men bindingene til den opprinnelige applikasjonen ble for sterke.

Da blir det å gå kanossagang mellom konsumentene for å finne ut om det lar seg gjøre å fjerne overflødig funksjonalitet

I resirkuleringsjobben prøver vi å kartlegge hva som er i bruk i dag, både av EJB- og SOAP-tjenestene. Jeg innser at tiden da jeg kunne be utviklingsverktøyet finne klasser, funksjoner og attributter som ikke brukes er forbi. Den løse bindingen mellom konsument og tjeneste gjør at en slik analyse blir en manøver i flere steg.

Først finne ut hva konsumenten bruker, for å oppdage at tjenesten brukes av flere konsumenter. Da blir det å gå kanossagang mellom konsumentene for å finne ut om det lar seg gjøre å fjerne overflødig funksjonalitet. Refactoring der verktøyet foreslo endringer og utførte dem i løpet av minutter er erstattet av endeløse tabeller møysommelig oppdatert med elementer, operasjoner, tjenester og konsumenter.

Uten kontroll over de forretningsmessige kravene vil endringer i fagsystemet måtte trekkes opp til grensesnittet

Etter å ha gått gjennom en håndfull tjenester og bare fått gjort refactoring på sandpapir-nivå innser man det håpløse i utgangspunktet: Det som engang er blitt publisert har noen tatt i bruk og er blitt spredt utover i organisasjonen. Selv om enkeltelementer ikke dekker konkrete forretningsmessige behov, var de tilgjengelige og da det hastet med å få funksjonaliteten ut til brukerne, tok de med alt for å være sikker.

Så står vi der da, med tjenester som var laget alt for omfattende i første omgang og som bare eser utover etterhvert som behov for endringer melder seg.

Å gi etter for presset om å publisere tjenester med romslig tjenestegrensesnitt framstår nå som en gedigen bjørnetjeneste. Felter og funksjonalitet henger med tjenestene år etter at de lagt i produksjon. Selv ubrukt funksjonalitet vedlikeholdes.

Det er her jeg innser at jeg, for lenge siden burde ha praktisert “Less is more” og kuttet unødvendig funksjonalitet på et tidligere tidspunkt.

Still spørsmål! “Hva?” og “Hvorfor?”

Når jeg tar i bruk romslige tjenestegrensesnitt fra en produsent, stiller jeg alltid spørsmål om hva som er det minste jeg må angi av input for å få kjørt meldingen gjennom tjenesten. Trenger jeg å angi noe som helst av de elementene som er deklarert valgfrie? Eller er det tilstrekkelig med de obligatoriske feltene?

Uten krav om innhold i meldingene til produsenten er det fristende å ta vekk alle obligatoriske felter fra kontrakten og se hva som hender. Uten krav fra forretningssiden vil tilsvarende strategi provosere fram krav og avhengigheter.

En tjeneste som ikke er forankret i forretningsmessige krav, vil være uten finansiering på lang sikt og visne etter at realiseringsprosjektet er avsluttet

Etterhvert som jeg får svar og kravene til innhold øker må jeg forstå hvorfor og ikke minst hvor konsumenten må finne fram til denne feltverdien. Er det et felt brukeren taster inn, hentes det fra et annet tjenestekall eller er det noe jeg må finne på?

Når man har kontroll over de forretningsmessige kravene, vil man kunne avgjøre om en endring i fagsystemet skal gjenspeiles i grensesnittet

På den måten øker jeg min forståelse for hva tjenesten jeg lager kan tilby av funksjonalitet og det er først da jeg kan finne ut om tjenesten dekker forretningssidens krav gjennom samme prosess: Hva er det minste av funksjonalitet tjenesten må tilby for at kravene kan oppfylles?

Det er lettere å legge merke til noe man åpenbart mangler enn noe man åpenbart ikke trenger

I første runde er det stor sjanse for at min minimumstjeneste ikke dekker kravene til konsumentene. Det er bra! Først da kan jeg være sikker på at jeg ikke drar med meg unødvendige avhengigheter nedenfra. Om kravstillerne godtar grensesnittet mitt uten å mukke har jeg sannsynligvis dratt med meg for mye. Det er lettere å legge merke til noe man åpenbart mangler enn noe man åpenbart ikke trenger.

Fortsett å spørre!

Om man fortsetter å spørre etter det minste felles multiplum mellom hva fagsystemet tilbyr og det forretningssiden etterspør, har man vesentlig bedre forutsetninger til å oppnå gjenbrukbarhet enn om man antar at fagsystemet har ivaretatt det for deg.

Hvis ikke, kan man bare begynne å hamstre hodepinetabletter til den dagen fagsystemet skal erstattes med noe annet.

Les gjerne også kollega Noralf Husbys artikkel om IT-styring på virksomhetsnivå.