Selskapets Advisor/J er et viktig element i verktøykassa til utviklingsarkitekturen som Posten SDS skal legge til grunn for sin satsing framover.
- Neuron Data ble dannet i Palo Alto i California i 1985 av en gruppe franske og amerikanske spesialister på kunstig intelligens, forteller salgsdirektør Patrick King.
- Året etter hadde de sitt første produkt klart, verdens første PC-baserte ekspertsystem. I 1991 engasjerte vi oss i verktøy for grafiske brukergrensesnitt, og fikk blant annet nettstedet til Nasdaq som kunde. Siden 1996 har vi satset eksklusivt på objektorienterte utviklingsmiljøer under fellesbetegnelsen Elements. Poenget her er at vi ikke skal konkurrere med Borland og Microsoft. Vår spesialitet er regler, det gjennomsyrer alt vi gjør.
Denne nisjesatsingen har gjort selskapet stadig mer internasjonalt orientert. I siste regnskapsår gikk 42 prosent av omsetningen til andre land enn USA og Canada, særlig Japan og EU. Med tre kontorer i Europa og et i Tokyo, regner King med at den ikke-amerikanske omsetningen vil bli størst innen seks måneder. Selskapet har investorer som Morgan Stanley og TL Ventures, og kundene er store kjente selskaper innen finans, industriproduksjon, telekommunikasjon og forsikring - dynamiske bransjer i stadig forandring.
- Applikasjoner som skal bære bedriftens forretninger må kunne utvikles raskt, og de må kunne endres raskt. Regel-baserte applikasjoner kan endres samtidig med forretningsmiljøet, ikke etterpå. Vår forretningsidé er følgelig å tilby de grunnleggende komponentene for å utvikle og sette sammen regeldrevne applikasjoner.
Neuron mener at til sammen, utgjør forretningsreglene selve forretningen. King definerer en forretningsregel som ethvert konsept, enhver framgangsmåte, enhver virksomhet, som beskriver hvordan man handler i forretningsmiljøet. En typisk regel kunne formuleres slik: "Når en kunde har bestilt for mer enn 500.000 kroner, og har vært aktiv i mer enn fem år, så tilbyr vi ti prosent rabatt, ellers..."
- Forretningsreglene er selve tankeprosessen i virksomheten. Det er ikke alltid de er eksplisitt formulerte. Ofte finnes de enten i hjernen til de ansatte, eller kodet i bedriftens datasystem. Begge steder er det svært vanskelig å forandre dem etter hvert som forretningsmiljøet krever endringer. Vår løsning er å formulere reglene i klartekst og lagre dem i en egen repository eller regeltjener, og forfatte bedriftens applikasjoner slik at de henter sine regler derfra.
King viser til at 85 prosent av alle IT-prosjekter mislykkes, og at grunnen er nettopp at man ikke har skilt ut forretningsreglene, men bygget systemer der reglene bli planløst fordelt mellom de ulike lagene, i noen tilfeller til og med kodet inn i selve databasen. Med tanke på norske erfaringer som Tress 90, der et hovedproblem nettopp var et stadig skiftende regelverk som ikke lot seg håndtere gjennom gammeldagse kravspesifikasjoner, synes påstanden innlysende.
- Å bygge forretningsreglene inn i databaseapplikasjonen er som å støpe dem i betong. Men det gjøres til og med av objektorienterte programmerere. Hvorfor skal du grave ned bedriftens sjel i utilgjengelig kode?
Etter Neurons modell skal databasen og regelbasen stå hver for seg. Selve applikasjonen henter informasjon fra databasen, og sørger for at den behandles i tråd med reglene. De som driver selve selskapet er de som forholder seg direkte til regelbasen. De utvikler reglene, de vedlikeholder dem, og de styrer dem.
- Reglene er vår del av denne helheten. La oss si du så fyller ut modellen med arbeidsflyt og objektorientert utvikling. Da får du noe som virkelig er spissteknologi. Det er nettopp det Posten SDS gjør, og det er derfor deres programvarearkitektur er så epokegjørende.
All slags støttesystemer for behandling av kunder og saker er typiske kandidater for regeldrevne applikasjoner, mener King. Andre eksempler er støtte til vurdering av lån og investeringer, styring av produksjonssystemer, og alt som inngår i elektronisk handel.
- Fordelene må vurderes i forhold til dynamikken i det miljøet applikasjonen skal fungere i. Du sparer mye på at selve utviklingen av applikasjonen går langt raskere, og at den blir lettere å vedlikeholde og tilpasse omgivelsene. Reglene er dessuten skrevet i vanlig språk, slik at den grunnleggende logikken i datasystemet kan forstås av ikke-datafolk. Andre fordeler er at prototyper kan bygges raskt, og utvides trinnvis, samt at koden du får er gjenbrukbar.
King viser til en erfaring hos den britiske skatteetaten.
- De hadde spesifisert et system, og regnet med at utviklingen ville sysselsette 60 folk på heltid over to år. Da våre folk tok over prosjektet, brukte to av dem fire uker på å lage en første prototype. Med to utviklere til var hele systemet ferdig etter et halvt år.
Et annet eksempel gjelder et prosjekt hos Bell Helicopter.
- Innkjøpssystemet der var kaotisk. De hadde 200 innkjøpere som skulle forholde seg til 40.000 leverandører, hver med mellom 200 og 300 forskjellige produktlinjer. De måtte stadig ty til overtid, men kunne ikke oppfylle myndighetenes krav om at alle delleveranser måtte kunne spores tilbake til leverandøren, og de kunne ikke foreta vurderinger av typen pris mot leveransetid. De gikk bare etter pris, og visste ikke at ved å betale litt mer hos en annen leverandør, kunne de fått varen levert dagen etter, i stedet for å vente i seks uker.
Innkjøpsordningen forsinket produksjonen, og intern frustrasjon skadet arbeidsmiljøet. Det regelbaserte systemet som Neuron Data utviklet, reduserte den gjennomsnittlige ventetiden på delleveranser fra over fire uker til én, og sparte bedriften for 3,4 millioner dollar det første driftsåret. Alle offentlige krav til sporbarhet ble oppfylt, og arbeidsmiljøet ble trivelig.
Det viktigste produktet for Neuron Data er det Java-baserte regelverktøyet Advisor/J 2.0. Etter spesifikasjonene er det fullt ut kompatibelt med Suns Java, med JavaBeans, og med objektformidling etter CORBA.
