Pravila i obrasci koji se izvode u procesu
Pravilnik ne bi smio biti daljinski proročište
Poslovna pravila obično se uvode kao nešto jednostavno. Kupac je podoban ili nije. Transakcija prolazi ili ne prolazi. Ponuda dobiva popust. Korisnik može pristupiti resursu. Zatim pravila rastu, stižu iznimke, usklađenost traži dokaze, i odjednom je jednostavna provjera postala servis politika, tumač, predmemorija, posao usklađivanja i sastanak s dobavljačem. Divno. Ponovno smo izumili semafor s pretplatničkim planom.
Lattice polazi od manje teatralne ideje: pravilnik bi se trebao izvršavati tamo gdje se donosi odluka. Trenutna Lattice stranica opisuje Apache 2.0 Rust komponentu koja unaprijed kompajlira pravila u binarni artefakt koji se može preslikati u memoriju. Evaluacija je prolazak kroz zapakirano stablo unutar procesa. Artefakt nosi kontrolne zbrojeve. Ista pravila i isti podaci opisani su kao da daju isti odgovor na podržanim ciljnim platformama. Nijedan dodatni servis ne mora stajati na putu odluke. To je koristan oblik.
To nije protiv upravljanja. Upravo suprotno. Upravljanje slabi kada pravila žive daleko od sustava koji ih koriste i kada se objašnjenja moraju naknadno rekonstruirati. Pravilnik koji je verzioniran, kompajliran, zaštićen kontrolnim zbrojem, učitavan u proces i ponovljiv daje revizorima nešto konkretnije od pitanja smo servis politika i rekao je ne. Ta rečenica može biti istinita. Nije dovoljna.
Kompajlirajte jednom, prestanite tumačiti zauvijek
Putanja stranice je jasna: definiraj, kompajliraj, zapakiraj, evaluiraj. Pravila i ograničenja žive uz izvorni kod i povijest verzija. Kompajliranje klasificira ograničenja i fiksira pozadinski program za rješavanje. Pakiranje proizvodi binarni artefakt s XXH3-64 kontrolnim zbrojevima nad zaglavljem, sadržajem i datotekom. Učitavanje je sistemski poziv, ne parsiranje. Evaluacija prolazi kroz zapakirano stablo unutar procesa. Taj slijed je važan jer pretvara posao u vrijeme izvođenja u posao u vrijeme izgradnje.
Tumači su zgodni dok ne sjede na svakom zahtjevu. Daljinski servis politika je zgodan dok mrežni skok ne postane dio proračuna latencije i servis ne postane još jedna stvar koja može pasti. JIT je zgodan dok različita ciljna okruženja, verzije ili optimizatori ne postanu dio objašnjenja. Lattice je namjerno manje dramatičan. Kaže da bi pravilnik trebao postati datoteka koju aplikacija može preslikati i izvršavati deterministički. Putanja zahtjeva ne bi trebala ponovno otkrivati pravila svaki put.
Stranica izvještava o brojkama mjerenja za trenutnu putanju artefakta, uključujući brojku za vruću evaluaciju, hladno pretraživanje nakon mmap i brojke propusnosti. Te brojke pripadaju stranici i njezinom kontekstu mjerenja, ne mitu koji bi se trebao kopirati u svako buduće izdanje. Trajna inženjerska poanta je dizajn: zapakirani artefakt, evaluacija lokalna za predmemoriju, bez parsera na kritičnom putu, bez alokatora na kritičnom putu i bez mrežnog skoka po odluci.
Jedan jedinstveni API za pravila ne bi smio skrivati stvarnost rješavača
Pravila nisu sva ista. Neka su čiste boolean provjere. Neka kombiniraju logiku s aritmetikom. Neka su linearni programi. Neka zahtijevaju cjelobrojne odluke. Neka su ograničenja konačnih domena. Neka su problemi putanja ili meka ograničenja. Ozbiljan stroj za pravila ne bi smio provlačiti svaki slučaj kroz jednu rupu u obliku rješavača. Trebao bi klasificirati pravilo i usmjeriti ga na odgovarajući pozadinski program.
Stranica Lattice navodi SAT, SMT, LP, MIP, CP, A* i MaxSAT pod jednim API-jem za pravila. SAT pokriva čiste boolean pravila i značajke. SMT obrađuje miješane teorije poput logike, aritmetike, polja i bitvektora. LP pokriva kontinuiranu optimizaciju. MIP ili ILP obrađuje cjelobrojne odluke. CP obrađuje konačne domene i nelinearna ograničenja. A* i MaxSAT pokrivaju probleme putanja i mekih ograničenja. Ključna rečenica o proizvodu jest da pozivatelj piše pravila, a ne pozive rješavača.
To je važno za održivost. Ako svaki tim za proizvod piše integracijski kôd specifičan za rješavač, sloj politika postaje zbirka pametnih lokalnih trikova. Pametni lokalni trikovi skupi su u revizijama jer se nitko ne sjeća koji je trik bio pametan, a koji je bio samo petkom. Klasificirana površina pravila timovima daje jedno mjesto za pregled pravila, njegove klase pozadinskog sustava, kompajliranog artefakta i odgovora koji je proizveo.
Latency je također poslovno pravilo
Sustavi za odlučivanje vole pretvarati da je latency tehnička naknadna misao. Nije. Ako provjera usklađenosti stoji na svakoj transakciji, latency je dio proizvoda. Ako kontrola pristupa stoji na pristupnoj točki, latency je dio sigurnosti. Ako se cijene izračunavaju u trenutku ponude, latency je dio prihoda. Ako se provjera prijevara odvija prije namirenja, latency je dio rizika. Sporo pravilo može biti ispravno, a operativno pogrešno.
Zato je evaluacija unutar procesa važna. Trenutna stranica Lattice suprotstavlja interpretirane ili udaljene provjere na skali milisekundi s putanjom pakiranog artefakta te ističe trošak mrežnih skokova, pomoćnih servisa i praznina u reviziji. Točan broj za jednu mjeru uspješnosti manje je važan od oblika troška. Ako jedan zahtjev treba deset provjera, možda stara putanja preživi. Ako jedan zahtjev treba deset tisuća provjera, stara putanja počinje zauzimati prostor u proračunu zahtjeva. U tom trenutku mehanizam pravila više nije komponenta. On je ono na što korisnici čekaju.
Operativna korist nije samo brzina. Riječ je o manjem broju pokretnih dijelova. Bez dodatnog servisa za politike. Bez mrežne putanje koju treba održavati zdravom. Bez zasebnog procesa za parsiranje. Bez zasebne predmemorije koju treba objašnjavati. Pravilnik stoji uz aplikaciju, unutar jurisdikcije i operativne granice koju već kontrolirate. To je manje glamurozno od nadzorne ploče. No i manje je vjerojatno da će nekoga probuditi.
Odgovor za reviziju je ponavljanje
Kad revizor pita zašto je odluka odbijena, najgori odgovor je odlomak rekonstruiran iz sjećanja. Drugi najgori odgovor je snimka zaslona. Koristan odgovor je: ova verzija pravilnika pokrenuta je na ovom ulazu i proizvela je ovaj izlaz, ovdje je kontrolni zbroj artefakta, ovdje je pravilo, ovdje je ponavljanje. Lattice je izgrađen upravo kako bi taj odgovor bio moguć.
Stranica povezuje Lattice s automatiziranim odlukama prema GDPR-u, transparentnošću prema EU AI Actu, operativnom otpornošću prema DORA-i i osiguranjem opskrbnog lanca prema NIS2. Te oznake mogu postati puko marketinško obećanje ako sustav ne može pokazati ništa konkretno. Konkretan dio je artefakt. Kompilirani pravilnik može se imenovati. Kontrolni zbroj može odbaciti neovlaštenu izmjenu. Zabilježeni ulazi mogu reproducirati odluku. Bitno identičan izlaz znači da prebacivanje na rezervni sustav ne bi smjelo tiho promijeniti odgovor. Izvođenje unutar procesa u kontroliranim sustavima pomaže izbjeći problem vanjskog servisa na putu odlučivanja.
Gdje se najprije uklapa
Lattice ima najviše smisla na točkama odlučivanja koje se često događaju i za koje je kasnije potreban dokaz. Provjere usklađenosti na transakcijama. Određivanje cijene i podobnosti u trenutku ponude. Odluke o pristupu na pristupnicima. Provjera prijevara prije namirenja. Provjere podobnosti u javnom sektoru. Kontrolne točke u osiguranju. Dopuštenja unutar radnih procesa. To su mjesta gdje samo da ili ne nije dovoljno. Sustav mora znati koja se verzija tog da ili ne dogodila.
Također se uklapa na mjesta gdje ista odluka mora ostati ista na različitim poslužiteljima. Prebacivanje na rezervni sustav ne smije promijeniti rezultat provjere usklađenosti. Regionalna implementacija ne smije tumačiti pravilo drugačije zbog različite verzije biblioteke. Revizijska reprodukcija ne smije ovisiti o tome da isti usluga kod davatelja i dalje postoji. Pravilnik bi trebao biti dovoljno prenosiv da se izvodi tamo gdje ga organizacija kontrolira, i dovoljno jasan da troškovi promjene ostanu niski.
Zato je otvoreni kod i ovdje važan. Pravilnički stroj koji sudjeluje u usklađenosti, pristupu, cijenama ili prijevarama nije ukrasna ovisnost. Dio je upravljačke ravnine. Ako ga nitko unutar organizacije ne može pregledati, zaključati, testirati i održavati, onda pravilnik zapravo nije njihov. To je unajmljeni autoritet.
Što pregledati prije usvajanja
Prvo, identificirajte točke odlučivanja. Ne počinjite s migracijom platforme. Počnite s jednim pravilnikom koji danas stvara probleme. Koliko često se izvršava? Što štiti? Tko postavlja pitanje zašto? Što se događa ako je usluga nedostupna? Koji su dokazi dostupni šest mjeseci kasnije?
Drugo, pregledajte oblik pravila. Jesu li ograničenja logička, aritmetička, linearna, cjelobrojna, konačnodomenna, putanjska ili mekana? Koja klasa pozadinskog sustava treba njima upravljati? Ako pravilo ne može objasniti zašto se usmjerava na obitelj rješavača, apstrakcija je previše magična.
Treće, pregledajte disciplinu artefakta. Gdje je pohranjeno izvorno pravilo? Koja je izgradnja proizvela artefakt? Koji je kontrolni zbroj učitan? Koja verzija aplikacije ga je koristila? Koji su ulazi zabilježeni? Koji put reprodukcije dokazuje odgovor? Ako je odgovor razbacan po tri sustava i osobi po imenu Jan, pravilnik još nije revizijski objekt. To je tradicija.
Pouka
Lattice je priča o pravilničkom stroju, ali zapravo je priča o kontroli. Kompajlirajte pravilnik prije zahtjeva. Spakirajte ga u artefakt koji aplikacija može preslikati u memoriju. Provjerite artefakt prije učitavanja. Usmjerite ograničenja na pravu obitelj rješavača. Izvršavajte unutar procesa. Kasnije reproducirajte s istim ulazom i istom verzijom pravilnika.
To nije glamurozno. Dobro. Poslovna pravila ne bi trebala biti glamurozna. Trebala bi biti dosadna, brza, jasna i provjerljiva. Važni sustavi odlučivanja u tvrtki ne bi trebali ovisiti o udaljenim proročištima, petljama parsera i revizijskoj arheologiji. Trebali bi nositi svoje pravilnike poput infrastrukture.
Pravilnik ne bi trebao biti udaljeno proročište. Trebao bi biti nešto što sustav može izvršiti, imenovati i reproducirati.