Erfaringer med SMARTS fra en forretningsarkitekt
19. september 2024På denne bloggen har det allerede blitt skrevet en del innlegg som handler om Decision Management Systems (DMS), eller beslutningsstyringssystem på norsk. Jeg ønsker å skrive litt om min opplevelse med SMARTS fra en person som har bakgrunn som forretningsarkitekt, der hovedfokuset oftest er på krav, forretningsprosesser og livlige diskusjoner mellom personer i grenselandet mellom IT og fag.
Alf-Kenneth har allerede skrevet en god introduksjon til hva SMARTS er, og fordeler ved å bruke verktøyet. Øystein har skrevet et 2-delt innlegg om hvordan A-B testing i SMARTS kan utføres, der det er synliggjort hvordan du enkelt kan vurdere konsekvenser av endringer i reglene.
Uten den tekniske bakgrunnen kan det oppleves som å vandre inn i ukjent terreng med mange fallgruver når man selv skal begynne å «kode» regler. Mitt hovedpoeng er at det er det liten grunn til, fordi dette er så enkelt at man kan lære seg de mest elementære (og viktigste) bruksområdene på kort tid – uten særlig teknisk kompetanse. Jeg har nå brukt en knapp uke på å sette meg inn i SMARTS, og selv om jeg ikke kan påberope meg ekspertise på systemet kan jeg allerede nok til å sette opp et enkelt regelsett med fakta, vilkår og utfall. Og vel så viktig kanskje – jeg kan lese og forstå hva som foregår i etablerte regelsett uten å måtte ty til utviklere for hjelp. Om du har satt opp et Excel-ark med noen enkle formler er du kapabel til å ta i bruk SMARTS, som er et såkalt «Low-code/No-Code» verktøy.
Uten at jeg kan eller skal skrive en komplett guide her, vil jeg vise hvor enkelt det er å sette opp et enkelt regelsett med noen fakta og en enkel beslutningstabell. Med min bakgrunn fra pensjonsfaget er jeg moralsk forpliktet til å ta et eksempel derfra. Vilkårene for innvilgelse av «påslagspensjon» (fra offentlig sektor) er gjort betraktelig enklere sammenlignet med den gamle «brutto-ordningen», og handler i hovedtrekk om tre enkle vilkår:
- Medlemmet må være fylt 62 år
- Medlemmet må ha søkt i tide (med andre ord kan en ikke søke tilbake i tid)
- Medlemmet må ha minimum 1 dag opptjening etter 31.12.2019
(Så håper jeg at mine kollegaer med pensjonskompetanse kan tilgi meg for å ha gjort noen forenklinger for eksempelets skyld)
Rekkefølgen for hvordan man ønsker å gjøre dette er fleksibel, men vi ser med en gang at vi her trenger å få etablert tre enkle faktum. Vi begynner med å sette opp faktum i SMARTS, som tre true/false (boolske) variabler.
I SMARTS har du i prinsippet mulighet til å strukturere felter og seksjoner som du ønsker, men for å gjøre et tydelig skille mellom hva som er input (som er avhengig av- og prisgitt eksterne data og deres modeller) og fakta anbefaler vi at regler kjører på det vi enkelt kaller «fakta». Hva som er fakta i denne sammenhengen er det lovverket som bestemmer – ikke hva man har som input i en gitt kontekst. Rent praktisk er det å legge til seksjoner og felter svært enkelt – så lenge man tar stilling til datatypen (som i dette tilfellet altså er boolske).
I SMARTS kan vi med enkle grep benytte oss av disse faktaene og sette opp regelen som en beslutningstabell:
Tabellen viser de tre vilkårene (sendt innen fristen, fylt 62 år og har opptjening etter 31.12.2019) som kolonneoverskrifter. Hver rad i tabellen kan ses på som en regel – der utfallet av hver regel leses i den siste kolonnen (VilkårForPåslagOppfylt).
Noe forenklet forklart er dette så enkelt som å trykke add new decision table, og legge til rader og kolonner (add row og add column). Den mest kompliserte biten er å knytte kolonnene med de (etablerte) fakta til tabellen – og det tok ca. 2 minutter. Ellers er det å fylle inn enten «true» eller «false» slik at en får en fullstendig tabell med alle potensielle varianter.
Utfallet fastsetter her verdien «Vilkår for påslag oppfylt» som enten true eller false. Her har du mulighet til å legge inn flere utfalls-kolonner, om du for eksempel vil legge til hjemmelshenvisning, begrunnelse eller annet for hver rad som kan slå til.
Når jeg har fylt inn tabellen kan jeg endre visning av regelen til rule list, der jeg ser koden som er generert:
Bildet viser de samme reglene som uttrykt i beslutningstabellen over som individuelle kodede regler. I hver regel er det en tittel (fet skrift), vilkår og utfall.
Foreløpig har vi tatt utgangspunkt i en regel der forutsetningen er at faktum er etablert. I den virkelige verden vil vi også måtte utlede disse faktaene – med andre ord transformere input til de faktaene vi trenger. Her er det flere veier til mål, men én enkel mulighet er å utlede dette med flere regler i SMARTS. I mitt eksempel har jeg skilt mellom regler som utleder fakta, og vilkårsregler (som igjen kjører på fakta). For å utlede fakta har jeg lagt inn noen enkle utledningsregler:
Utledningsreglene fastsetter altså de fakta som vi benytter for å kjøre de «reelle» forretningsreglene våre. Dette var nok det vanskeligste å få fatt på for min del – men her er det prøving og feiling, og det å gjøre seg kjent med SMARTS sin dokumentasjon og veiledning som gjelder. Du kan også få hjelp av den innebygde AI-assistenten til SMARTS, som jeg har vist med et enkelt eksempel her:
Det er langt flere muligheter og funksjoner i SMARTS enn det jeg har fått vist med mitt enkle eksempel her – og erfarne brukere eller kodere vil nok ikke være 100% overbevist av mitt forsøk på å implementere denne regelen. Men det er heller ikke poenget med denne bloggposten.
Som funksjonell arkitekt er det en kjent problemstilling at forretningslogikken er lite tilgjengelig. Både fagpersoner, forretningsressurser, testere og andre har ofte lite innsikt og tilgang til den faktiske koden. Og selv om vi hadde sittet med koden foran oss er det ikke gitt at vi hadde blitt mye klokere. Fagpersoner som sitter med den faktiske forretningskompetansen jobber aktivt med faget og utarbeider oppslagsverk og wikier, men har sjelden eierskapet eller innsikten i den faktiske implementeringen – som i realiteten er måten de samme reglene praktiseres på.
Når systembrukere oppdager feil eller mangler i eksisterende systemer er det ofte en tungrodd prosess å spore hva som faktisk foregår. Feilsøking og påfølgende kravspesifisering og retting kan være tidkrevende og frustrerende. Ofte er systemer eller tjenester såkalte «black boxes» – der få (eller ingen) i virksomheten helt vet hvordan løsningen fungerer. Men hva om saksbehandleren eller fageksperten selv kunne gå rett inn å sjekke den faktiske regelimplementeringen? Eller enda bedre – om fageksperten selv kunne rettet feilen med noen tastetrykk?
Å spore hvilke regler som er kjørt – og eventuelt slått til er heller ikke særlig problematisk i SMARTS. I eksempelet nedenfor kan jeg se (med «grønt lys») hvilke regler som har slått til i mitt testcase:
Én av hensiktene med DMS er altså å la fagekspertene selv få innsikt og til syvende og sist eierskap til de praktiserte reglene i systemene. Det er et oppnåelig mål, og spesielt for virksomheter der kompliserte forretningsregler er en del av hverdagen. Betyr det at det også er et mål å «kvitte seg» med utviklere eller systemarkitekter? Selvsagt ikke. For å ta i bruk en DMS kreves det integrasjoner, kvalitetssikring og testing for å nevne noe. For komplekse regler vil også det å utlede fakta være krevende – og i større grad kreve kompetanse med koding. Vi ønsker heller ikke at fageksperter skal bli fulltidskodere (med mindre de selv har veldig lyst) – men jeg har forsøkt å vise (med de rette hjelpemidlene) at gapet mellom forretning og IT kan bli litt mindre med enkle grep.
