Pravidla pod kontrolou

aExtrahujte obchodní pravidla z aplikací, a obchodní analytici v nich budou moci provádět změny bez toho, aby komplikova...


aExtrahujte obchodní pravidla z aplikací, a obchodní analytici v nich budou
moci provádět změny bez toho, aby komplikovali život firemnímu IT oddělení.
Základním pravidlem efektivního využívání technologií je, že chytré výsledky
získáte pouze pomocí chytrých nástrojů v rukou chytrých lidí. Vaši vývojáři
mohou být schopni napsat ten nejlepší kód, ale nechtějte od nich, aby činili
nerozumná rozhodnutí ohledně obchodních pravidel. A na druhé straně obchodní
analytici by se měli zaměřit na to, co umějí nejlépe, nikoliv se pokoušet o
překlad podnikatelských rozhodnutí do příliš detailních dokumentů týkajících se
požadavků na IT.
BRMS (Business Rules Management System) dokáže překlenout propast mezi obchodem
a IT tím, že přenechává kontrolu nad logikou a dokonce i nad příslušným kódem
obchodním analytikům. Tato kacířská myšlenka ovšem předpokládá zcela odlišný
přístup k vývoji aplikací, kdy vývojáři izolují obchodní logiku od logiky
validace dat obvykle v podobě nějakého grafického rozhraní a od řízení toku
dat. Obchodní logika získává svůj vlastní kontejner, BRMS, v němž podnikoví
analytici "programují" obchodní pravidla pomocí jednoduchého, běžné řeči
podobného programovacího jazyka.
Mezi příklady takových BRMS produktů patří JRules firmy Ilog, Blaze Advisor
firmy Fair Isaac, dále Corticon Decision Management System a OPSJ (Official
Production System for Java) od společnosti Production Systems Technologies
(PST). Do hry se s produktem Business Rules Framework for BizTalk 2004 zapojil
dokonce i Microsoft. BRMS enginy jsou zasazovány do vertikálních podnikových
aplikací, které mají na starosti např. pojištění, žádosti o úvěr, komplexní
plánování nebo jiné úlohy, které vyžadují simulaci (lidských) odborných
znalostí.
Výhody jsou zřejmé. Namísto telefonických konzultací s IT oddělením získává
obchodní část firmy přímou kontrolu nad pravidly, které řídí chování
podnikových aplikací. A pokud se obchodní analytik rozhodne, že je nutné
provést v pravidlech změnu, může příslušné úpravy zrealizovat sám a nemusí
čekat, až si na ně najde čas IT pracovník. Výsledkem jsou mnohem nižší náklady
na údržbu a mnohem vyšší jistota, že obchodní pravidla jsou implementována tak,
jak byla zamýšlena.

Překonání překážek
Podnikoví analytici mají zpravidla mnohem vzdálenější vztah k podnikovým
aplikacím než, řekněme, k tabulkovému modelu na stolním počítači. Pokud
obchodníci požadují vytvoření nové aplikace nebo změnu stávající, předají svůj
požadavek oddělení IT, které velmi pravděpodobně nemá ani sebemenší představu o
tom, o čem je vlastně řeč. A tak začíná nekonečný kolotoč schůzek mezi
obchodníky a IT, na nichž se urovnávají nejasnosti.
V určitém momentě začnou vývojáři vytvářet kód, přičemž obchodní pravidla buďto
zabudují do softwarových komponent na aplikačním serveru, nebo je implementují
do uložených databázových procedur. Vývojářský tým poté kód testuje a předá ho
zpět analytikům k ověření a v této chvíli je výsledek zamítnut, jelikož ani v
nejmenším neodpovídá představám analytiků. O několik měsíců později a po
několikerém přepsání kódu dostanou obchodníci konečně něco, s čím jsou schopni
pracovat.
S pomocí BRMS analytici obchodní logiku nejen sami určují, ale také píší.
Jediným požadavkem je, aby uměli pravidlo formulovat v běžném jazyce. Takové
obchodní pravidlo má obvykle následující podobu: POKUD (IF) dojde k výskytu
určité události nebo splnění určité podmínky, PAK (THEN) by mělo dojít k
určitým událostem, JINAK (ELSE) by mělo dojít k jiným událostem. Každý výrok
typu IF-THEN-ELSE představuje obchodní pravidlo. Každé z pravidel je svou
povahou deklarativní a může být ve vzájemné interakci s dalšími pravidly. Díky
BRMS si mohou analytici tato pravidla prohlížet, pochopit je, psát nebo měnit
je a udržovat bez nebo pouze s minimální pomocí IT.
BRMS pravidla "přechroustává", dokud nenajde řešení. Prochází pravidla stále
dokola až do chvíle, kdy již neexistují žádná další, která by bylo možné
vykonat. Celá myšlenka spočívá v tom, že změny dat řídí postup, v němž se
pravidla provádějí a že vzájemně se ovlivňující pravidla snižují nutnost
lidského zásahu. Sady pravidel propojené do vzájemných vztahů mohou kompletně
řídit schvalování půjček nebo třeba volbu způsobu dopravy zboží atd.
Naproti tomu při běžném vývoji aplikací jsou pravidla uspořádána velmi křehkým
způsobem odshora dolů (od obecnějších ke konkrétnějším). Kupříkladu pokud větev
následující za PAK mění údaje, jimiž se řídí podmínka POKUD jiného pravidla, je
nutné celý proces prozkoumat a stanovit správné pořadí pravidel. Právě proto
trvají psaní, změny a udržování obchodních pravidel pomocí běžných postupů
vývoje aplikací tak dlouho.

Pravidla a infrastruktura
Na úrovni vývojového diagramu vypadá aplikace řízená na bázi BRMS velmi podobně
jako konvenční podnikové aplikace. Představme si BRMS jako další úroveň
n-úrovňového systému zahrnujícího obvyklou kombinaci webového serveru,
aplikačního serveru a databáze. BRMS tvoří čtvrtou úroveň, která logiku vkládá
do rukou obchodních analytiků.
Díky analogické povaze BRMS příkazů s přirozeným jazykem bude schopen pravidla
kontrolovat třeba i ředitel firmy. Pravidla lze změnit, přidávat nebo mazat,
odesílat je IT oddělení k otestování a integraci a implementovat je během
několika dní, nebo dokonce hodin do produkčních systémů.
Přestože firmy mohou očekávat výrazné úspory v oblasti řízení změn, měly by
zároveň počítat s velkou počáteční investicí do vývoje a školení pro BRMS. Je
prakticky nemožné odhadnout, kolik času psaní obchodních pravidel zpočátku
zabere, neboť to závisí na jejich počtu, který nevyhnutelně bývá vždy vyšší,
než se očekávalo. Obchodní analytici se také mohou začít bránit při pouhé
zmínce o "programování" obchodních pravidel. A stejně jako každé velké IT
dobrodružství si musí i BRMS projekt především získat podporu vyššího
managementu.
Rozhodování o nasazení BRMS záleží na typu aplikace a charakteru stávající
infrastruktury. BRMS by byl pochopitelně zbytečností pro "malou" aplikaci,
speciálně určenou pro plnění jediné funkce. Naproti tomu mnohé rozsáhlé
komerční podnikové aplikace, jako jsou ERP nebo CRM systémy, již enginy pro
tvorbu pravidel obsahují, byť mohou být pro uživatele neviditelné. Ale pro
mnoho velkých aplikací vytvořených ve firmě může být BRMS přínosem, zvláště
pokud je už v původním návrhu obchodní logika izolována od zbytku aplikace.

Složitá extrakce
Složitější je však rozhodování, zda integrovat BRMS do stávajícího systému.
Oddělení IT a obchodníci musejí spolupracovat na extrakci obchodní logiky,
která byla původně smíchána dohromady s řídicí logikou a kódem pro validaci
dat. Některé softwarové komponenty ale mohou po extrakci obchodní logiky
přestat fungovat, navíc rozhodnout, které pravidlo kam patří, nemusí být
snadné. Zdá se být kupříkladu samozřejmostí, že obchodní pravidla neovlivňují
validaci dat. Ale v některých případech se parametry pro ověřování dat často
mění a je třeba je dostat pod kontrolu analytiků (mohou se měnit rozsahy dat,
seznamy kategorií mohou být dynamické atd.).
Dalším kamenem úrazu při úpravě stávajících systémů je skutečnost, že
existující pravidla jsou jen zřídkakdy (pokud vůbec) zcela správná. Díky
nekonzistencím mohou vznikat "politické" problémy nebo zdlouhavé diskuse, když
se analytici pokoušejí rozřešit složité otázky, kterým by se jinak mohli
vyhnout.
Nakonec je třeba každou existující součást obchodní logiky prozkoumat z
hlediska toho, jak zapadne do nového systému. Může se stát, že bude třeba
vytvořit nové objekty, i když většinu databázových aplikací lze rozšířit pomocí
BRMS, aniž by bylo nutné modifikovat samotnou databázi. V úvahu je také nutno
vzít nová grafická rozhraní (GUI), jelikož celá aplikace bude složitější a bude
pro svoji funkci vyžadovat více informací.
Mnohé firmy si najímají konzultanty, kteří jim pomohou stanovit objem práce
nezbytný pro nasazení BRMS. Pokud se vedení firmy pro využití BRMS rozhodne a
chápe jeho přínos, může být jednodušší zbavit se stávající aplikace a začít "od
nuly" s tím, že staré funkce pro validaci dat a řídicí kód budou využity jen
tam, kde to přinese úsporu práce a času.

BRMS a finančnictví
Jedním z nejlepších příkladů BRMS řešení v akci je jejich nasazení ve
finančních institucích. V několika minulých letech raketově vzrostla nabídka i
šíře úvěrových produktů, z nichž každý se řídí svými vlastními pravidly. Právě
zde dává BRMS prostor pro kreativitu obchodníků, kteří se nemusejí obávat
nadměrné režie na straně IT.
E-Loan, jedna ze společností poskytujících finanční služby, vloni poskytla
úvěry v objemu 6 miliard dolarů, přičemž většina z nich byla schválena pomocí
BRMS vyvinutého na bázi javového enginu Jess pro tvorbu pravidel. Firma použila
zdrojové kódy dodávané s Jess k napsání vlastního uživatelského rozhraní BRMS,
jehož prostřednictvím mohou obchodní analytici zadávat jednoduchá pravidla, jež
generují kód pro schvalování úvěrů. CEO firmy E-Loan Etienne Handman říká, že
náklady na vývoj aplikace (jež se koneckonců ukázaly jako nižší ve srovnání s
tradičními řešeními) se rychle vrátily zejména díky zlepšení vztahů se
zákazníky, jejichž spokojenost pramení z vyšší rychlosti rozhodování analytiků.
Naproti tomu Andy Marsh, CIO firmy CitiStreet, především zoufale postrádal
řešení, kterému by jeho obchodní analytici rozuměli. S využitím jazyka BAL
(Business Action Language), na němž je založen produkt Ilog JRules, však může
veškerá pravidla vyjádřit společnou řečí běžně využívanou ve firmě i celém
finančním průmyslu. Výsledkem bylo zkrácení průměrné doby, kterou týmy na
analýzu potřebují, ze šesti měsíců na tři. Nyní Marsh přemýšlí, jak využít
výhod BAL a JRules při řízení workflow.
Trochu jiný problém řešila společnost Equifax. Hnacím motorem, který vedl k
implementaci JRules, bylo podle Lisy Fiondellové, viceprezidentky produktového
managementu, "omezení chyb, které vznikaly při překladech mezi obchodníky a
programátory". A přidává hned dva další důvody: celkově vyšší výkonnost při
provozu IT a kratší dobu, za kterou byla firma schopna nabídnout nový produkt
InterConnect webovou platformu pro poskytování úvěrů.
Mnoho velkých bank, včetně Lloyds TSB, Barclays a Citibank, používá BRMS pro
nejrůznější aplikace, jako je hodnocení úvěruschopnosti či stanovení úroku.
Pomocí aplikace JRules v jedné z těchto bank kontrolují nejen úvěrovou minulost
a příjmy žadatele o půjčku, ale také bonitu všech spoluručitelů.

Jak měnit pravidla hry
I když největší úspěch zaznamenaly BRMS systémy ve světě financí, bývá tato
technologie využívána i v mnoha jiných oblastech. Obzvláště telekomunikační
firmy BRMS často nasazují pro mnohé aplikace od směrování zpráv přes plánování
odstávek pro údržbu až po řízení vztahů se zákazníky. Další častou oblastí
využití v oblasti telekomunikací je zajištění a optimalizace fungování v
souladu s federální, vnitrostátní i mezinárodní legislativou.
Při prvním setkání s BRMS firmy čelí koncepčním překážkám, spočívajícím ve
vytvoření pravidel, která budou ovládat nejrůznější obchodní funkce. Poté, co
se tento Rubikon podaří překročit a analytici se mohou soustředit na ta
pravidla, která se mění dynamicky, je možné BRMS úspěšně aplikovat i na
některých ne zcela očekávaných místech.

Volba BRMS
BRMS nástroje pokrývají širokou oblast od open source řešení až po rozvinuté
podnikové systémy. Ti, kteří si chtějí možnosti BRMS vyzkoušet, mohou začít u
produktu Jess vyvíjeného v Sandia National Laboratories, jenž je volně ke
stažení. Nicméně rozsáhlejší vývojové projekty v podniku vyžadují vzájemnou
komunikaci a spolupráci všech zúčastněných obchodních analytiků, programátorů,
manažerů, koncových uživatelů atd. Pro takové projekty lépe poslouží plně
vybavený BRMS.
Mezi příklady podnikových produktů nabízejících nezbytné nástroje pro ladění,
testování a analýzu patří JRules (Java verze) a Rules (C/C++ verze) od firmy
Ilog nebo Blaze Advisor společnosti Fair Isaac. Jedná se o produkty firem, jež
se specializují na celkovou optimalizaci obchodních procesů. Na druhou stranu
zákazníci, kteří vyžadují zejména rychlost a smíří se s nástroji s určitými
omezeními, mohou uvažovat o nasazení OPJS firmy PST.
Samotné jazyky pro tvorbu obchodních pravidel existují už celá desetiletí,
takže je docela dobře možné, že některé z firem už mají k dispozici vývojáře s
předešlými zkušenostmi. Pokud pracují v oddělení IT specialisté, kteří mají
zkušenosti se syntaxí OPS nebo CLIPS (C Language for Production Systems), stojí
za to vzít v úvahu produkty Authorete firmy Haley, CLIPS/R2 firmy PST nebo
zmíněný Jess. Na trhu se objevují také produkty s novými funkcemi, jako je
PegaRules firmy PegaSystems či Corticon, což je BRMS aplikace, která pro
zadávání pravidel nabízí rozhraní tabulkového procesoru.
Při správné implementaci a dobře zajištěné podpoře mohou IT oddělení podle
odhadů firmy Gartner očekávat snížení provozních nákladů o 10-15 procent. Tento
odhad nebere v úvahu neurčité faktory, jako je schopnost rychle reagovat na
měnící se obchodní požadavky apod. Vyčíslit takovou výhodu může být obtížné a
samotný trend izolace a konsolidace obchodní logiky se zpočátku může jevit jako
poněkud zvláštní. Ale ve většině případů se výhody takřka nevyhnutelně dostaví.

Nové standardy v oblasti BRMS
V počátcích systémů založených na pravidlech existovalo jen několik dodavatelů,
z nichž většina využívala některou z variant syntaxe vytvořené programátory OPS
(Official Production System) na Carnegie-Mellon University. Každý z nich si k
jazyku přidal své, a tak prakticky znemožnil zákazníkům přejít ke konkurenci.
Ale v průběhu doby se ukázalo jako potřebné najít způsob, jak zadávat pravidla
ve formátu, jenž by byl ve vztahu k enginu pro jejich zpracování neutrální.
Některé komunity tak pracují na návrhu standardů, jež mají v budoucnu obchodním
analytikům umožnit využívat jednu přenositelnou syntaxi pro zadávání pravidel,
přičemž jejich zpracování budou moci zajišťovat různé enginy.
Jedním z hlavních návrhů standardů je přitom BRML (Business Rules Markup
Language), formát na bázi XML pro tvorbu pravidel vůči enginu neutrálním
způsobem. Dalším navrhovaným XML standardem je DAML (DARPA Agent Markup
Language), jehož hlavním cílem je umožnit vývojářům označkovat celé stránky
údajů tak, aby tyto informace mohly být přečteny a zpracovány BRMS produkty a
využity v kontextu pravidel.
RuleML (Rule Markup Language) je pokusem o podporu metod využívajících při
tvorbě pravidel dopředné i zpětné řetězení. RuleML byl v srpnu 2000 na Šesté
pacifické konferenci o umělé inteligenci navržen jako XML standard, nicméně
poté byl rozšířen i do enginů pro zpracování pravidel na bázi jazyka Java.
FpML (Financial Products Markup Language) by se měl stát na finančním trhu XML
standardem pro swapy, deriváty a strukturované produkty. Organizace Business
Products Management Initiative navrhuje i standardizaci řízení obchodních
procesů zahrnujících větší počet aplikací, firemních oddělení a obchodních
partnerů.
A konečně společnost Sun Microsystems představila JSR (Java Specification
Request) 94 a přidělila mu místo i ve svém JDK. V této chvíli je příslušné API
javax.rule omezeno na pár tříd s několika rozhraními a třídami výjimek, ale tak
koneckonců začínala i samotná Java. Pro javové enginy by se specifikace JSR 94
mohla stát pojítkem, které sváže dohromady vývoj formátů pravidel neutrálních
vůči enginům.

Jak vypadá pravidlo?
Toto je příklad obchodního pravidla pro e-commerce web, které je reprezentováno
"pseudokódem", jemuž porozumí i obchodní analytik, neboť připomíná syntaxi
běžného jazyka.
>> IF máme nákupní košík
>> AND nákupní košík obsahuje nejméně dvě položky
>> AND nákupní košík neobsahuje více než čtyři položky
>> AND jestliže hodnota nákupu je nejméně 3 000 Kč
>> AND jestliže zákazník má status Gold
>> THEN zákazník obdrží 15% slevu
>> AND zobrazí se zpráva "Obdržel jste slevu 15 %"
>> ELSE IF hodnota nákupu je menší než 3 000 Kč, zobrazí se zpráva >> "Chcete
pokračovat v nákupu a získat 15% slevu?"

Obchodní pravidla v kostce
V oblasti enginů pro práci s obchodními pravidly je často využívána speciální
terminologie. Zde uvádíme přehled nejčastěji používaných pojmů.
BRMS (Business Rules Management System): Základna pro zpracování pravidel
postupem času se tyto systémy vyvinuly ve vyspělá řešení, zahrnující podstatně
vylepšená API a GUI pro ladění i sofistikované nástroje, které firemním
uživatelům a programátorům umožňují dobře odladit konečný produkt.
CLIPS (C Language for Production Systems): C/C++ systém založený na pravidlech,
jenž využívá OPS syntaxi pro tvorbu pravidel. Zdarma dostupný od NASA.
DAML (DARPA Agent Markup Language): Vznikající standard pro správu pravidel ve
vojenských aplikacích. n EHS (Else Hand Side): ELSE část pravidla, která se
uplatní v případě, kdy pravidlo není splněno (viz LHS, RHS).
Jess (Java expert system shell): BRMS od Sandia National Laboratories, který
pro tvorbu pravidel využívá CLIPS/OPS syntaxi.
JSR 94 (Java Specification Request 94): Zavádí API javax.rules pro zajištění
interoperability mezi BRMS na bázi Javy.
KBS (Knowledge-Based System): Komplexní projekt zahrnující systém založený na
pravidlech, znalostní bázi údajů a opatření a umělou neuronovou síť.
LHS (Left Hand Side): IF část pravidla (viz RHS, EHS).
OPS (Official Production System): Systém, u něhož pravidlo představuje výrobu.
Inspirován ranými systémy na bázi pravidel používanými v psychologii.
OPSJ (OPS for Java): Vytvořil jej dr. Charles Forgy z firmy Production Systems
Technology, objevitel algoritmu Rete. n RBS (Rules-Based System): RBS je tím,
co je dnes známo pod názvem BRMS. Izoluje logiku v deklarativním stylu, který
mohou snadno zadávat a upravovat neprogramátoři. n Algoritmus Rete: Public
domain algoritmus objevený dr. Charlesem Forgym v roce 1979. Minimalizuje počet
shod v systému založeném na pravidlech a 3 000x zrychluje provádění programu.
Rete 2: Podstatně pokročilejší Rete algoritmus, rovněž vynalezený Dr. Charlesem
Forgym. Je 100-1 000x rychlejší než původní algoritmus Rete.
RHS (Right Hand Side): THEN část pravidla (viz LHS, EHS).
XSLT (Extensible Stylesheet Language Transformation): Způsob transformace XML
popisu do téměř libovolné podoby; zvláště užitečný pro konverzi obecného
souboru XML popisů pravidel do formátu využitelného určitým BRMS enginem.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.