affärsregler kommer först

nyligen pratade kollegor och jag med chief software developer på en stor kundorganisation om framsteg på en stor ombyggnadsinsats där. Vår oro var om projektgruppens medlemmar kunde möta en tidsfrist på cirka nio månader för att leverera en storskalig prototyp. Vi hade bara spenderat flera intensiva månader på att utveckla en omfattande affärsmodell, och de hade fortfarande flera månaders systemdesign kvar att slutföra.

den här huvudutvecklaren är väldigt skarp-inte en som förbinder sig till något svar lätt. Under den längsta tiden sa han ingenting, förlorad i tanken. Till sist, kollade de detaljerade affärsdiagram putsade på väggarna runt, han sa, “om vi redan hade börjat kodning, jag skulle säga att vi hade ingen chans alls. Men eftersom vi inte har börjat koda ännu, skulle jag säga att chanserna är ganska bra.”

jag var tvungen att köra det flera gånger i mitt sinne innan jag fick hans mening. “Om vi redan hade börjat koda skulle jag säga att vi inte hade någon chans alls.”

jag visste att han trodde att själva applikationskodningen skulle bli ganska tuff. Det skulle innebära att man använder en reglermotor, ett världsomspännande distributionsnät, grafiska användargränssnitt och några betydande middleware.

han sa att om de var tvungna att lösa alla affärsproblem medan de kodade, skulle de aldrig dra av det i tid—eller förmodligen någonsin. Men eftersom projektgruppen hanterade de tuffa affärsproblemen på förhand (inklusive att specificera affärsreglerna) trodde han att de hade en ganska bra chans att slutföra koden före måldatumet.

i stort sett handlar affärsregelmetoden helt enkelt om att ställa rätt frågor till rätt personer. Det finns bara ett sätt att ärligt möta en tidsfrist—och det är att lösa affärsproblemet först.

affärsdriven IT

i de tidiga dagarna av att bygga affärssystem kunde affärssidan i huvudsak luta sig tillbaka och bara låta dem hända. Fördelarna med att automatisera var så övertygande att du kunde göra nästan inget fel. Nu, för alla praktiska ändamål, fungerar affärer och IT oskiljaktigt. När man genomför projekt skulle det logiska steget då vara att sätta ihop sömlösa affärs-/IT-projektgrupper och få dem att följa ett affärsinriktat tillvägagångssätt för att utveckla krav. Ändå är många företag ingenstans nära att göra det idag.

alltför ofta producerar affärssidan fortfarande fuzzy, dåligt fokuserade ” krav “och IT-sidan fortsätter att göra” krav ” bara ett hack eller två ovanför programmeringen. Hur kan detta gap mellan affärsmän och IT-proffs för att utveckla krav elimineras?

svaret är relativt enkelt. Verksamheten behöver ett organiserat tillvägagångssätt som gör det möjligt för affärsmän att driva utvecklingen av krav. Detta tillvägagångssätt måste ge en färdplan som visar hur man ställer rätt typer av frågor om rätt saker vid rätt tidpunkter. Vad som behövs är ett affärsdrivet tillvägagångssätt.

i traditionella utvecklingsmetoder går mycket vanligtvis förlorat i översättningen av upfront-krav till det faktiska körsystemet. Men att skriva en uppsättning tydliga affärsregler förbättrar kommunikationen mellan affärssidan och IT och ger en bro mellan affärsanalys och systemdesign. Affärsregelmetoden hjälper till att stänga kravgapet mellan affärssidan och IT-sidan.

så vad är en affärsregel? Ur affärssynpunkt är det ett direktiv som syftar till att påverka eller styra beteende. Affärsregler är bokstavligen den kodade kunskapen om dina affärsmetoder. Ur en IT-synvinkel är en affärsregel en atomär del av återanvändbar affärslogik.

på ett sätt vet alla vilka affärsregler som är—de är det som styr ditt företag när det gäller att driva sin dagliga verksamhet. Utan affärsregler måste du alltid fatta beslut i farten och välja mellan alternativ från fall till fall. Att göra saker på det sättet skulle vara väldigt långsamt.

regler är bekanta för oss alla i verkligheten. Vi spelar spel efter regler, vi lever under ett rättssystem baserat på en uppsättning regler och vi sätter regler för våra barn. Ändå är tanken på regler i affärssystem ironiskt nog främmande för de flesta IT-proffs. Säg “regler” och många IT-proffs tänker vagt på expertsystem eller artificiell intelligens. Det finns lite erkännande av hur centrala regler faktiskt är för den grundläggande, dagliga verksamheten i verksamheten.

inte av en slump har många arbetare och chefer på affärssidan blivit så väl indoktrinerade i processuella åsikter för att utveckla krav att tänkande när det gäller regler kan verka främmande eller abstrakt. Praktiskt taget varje metod är skyldig i detta avseende, oavsett om det gäller omkonstruktion av affärsprocesser, systemutveckling eller mjukvarudesign.

detta är olyckligt av två skäl:

1. Att tänka på någon organiserad aktivitet när det gäller regler är faktiskt väldigt naturligt. Tänk dig till exempel att försöka förklara ett spel som schack, checkers, baseball eller fotboll utan att förklara reglerna.

2. Affärsarbetare och chefer har den kunskap som krävs för att skapa bra regler.

Provregler

ta en titt på provreglerna som följer och Lägg märke till hur varje aspekt av operativ kontroll i ett affärssystem kan hanteras av regler:

• begränsningar: en kund får inte placera mer än tre rush-order som debiteras sitt kreditkonto.

• heuristik: En kund med önskad status bör få sina beställningar fyllda omedelbart.

• beräkningar: en kunds årliga ordervolym måste beräknas när den totala försäljningen stängdes under företagets räkenskapsår.

• slutsats: en kund måste anses vara föredragen om kunden placerar mer än fem beställningar över $1,000.

• Timing: en kund måste arkiveras om kunden inte gör några beställningar under 36 månader i följd.

• utlösare:” skicka förhandsmeddelande ” måste utföras för en beställning när beställningen skickas.

regler bygger direkt på villkor och fakta. Villkor-som kund, leverans och faktura—bör ha en exakt, entydig definition i verksamheten. Till exempel kan kunden definieras som: “en organisation eller enskild person som har lagt minst en betald order under de två föregående åren.”

fakta ges av enkla, deklarativa meningar som förbinder termerna med ett verb eller verbfras, till exempel “kunden lägger order.”

en “faktamodell” är en uppsättning fakta som beskriver resultaten av en affärsverksamhet. En faktamodell bör fungera som en första ritning för en datamodell, men dess främsta syfte är att fånga kunskap om verksamheten i en strukturerad form, destillerad från de anställda och chefer som har den.

regler lägger i huvudsak känslan av orden måste eller får inte till villkoren och fakta, som i “order på kredit över $1,000 får inte accepteras utan en kreditkontroll.”

regler bör uttryckas i tydlig, entydig, välstrukturerad affärsengelska, med början med ett uttryckligt ämne. Reglerna bör inte ha fluff och inga saknade fakta. Regler kan kvalificeras, som i “en försändelse måste vara försäkrad om sändningsvärdet är större än $500.”Och regler kan innehålla tidskriterier, som i “en student måste vara inskriven i minst två kurser vid slutet av registreringen.”

regel oberoende

ett företag är väldigt mycket som en mänsklig kropp. Kunskap (term och faktum) strukturen är som skelettet; processerna är de kraftfulla musklerna; och reglerna är nervsystemet som styr de andra två. Alla tre är väsentliga och inbördes relaterade. Men affärsreglerna bör vara separata från de andra två. En grundläggande princip för detta tillvägagångssätt är att regler är oberoende av processer och förfaranden. En fördel med denna “regeloberoende” är en enorm förenkling i processerna.

resultatet är en “tunn process”, ett långvarigt mål för många IT-proffs. Genom att ta bort reglerna från processerna kan du producera processer som är relativt enkla och kan ändras när behovet uppstår.

i National Football League, om ett spel inte fungerar för ett lag, kommer det att vara borta från sin playbook inom ett par spel. Pjäserna är i huvudsak throwaways. På samma sätt måste företag se sina egna förfaranden som throwaways—billiga nog att kasta och ersätta lätt när förfarandena inte längre fungerar bra.

Avfallsförfaranden är ett måste för att verksamheten ska kunna anpassas och vara konkurrenskraftig. Denna bedrägligt enkla ide-möjliggjort av affärsreglerna-kan revolutionera hur arbetet görs och system utformas.

omtryckt med tillstånd från Principles of the Business Rule Approach, av Ronald G. Ross (Addison-Wesley, 2003). Ross är medgrundare och rektor för Business Rule Solutions LLC och verkställande redaktör för webbplatsen BRCommunity.com.

Library Fact Model
detta diagram visar en grafisk faktamodell för ett bibliotek. Regelns formulering bygger direkt på faktamodellen, som är ett diagram över grundläggande affärskoncept – en kunskapsstruktur. En faktamodell kan och bör ge en första cut-ritning för hur data så småningom kommer att organiseras i en databas. BESTÄMMELSE: Ett bibliotekskort får användas för att checka ut en bok endast om boken ägs av ett bibliotek som kortet är godkänt för.