Az IT túlzott merevedése: bekódolt szabályok

A vállalati informatikai rendszerek célja nem lehet más, mint a szervezet üzleti folyamatainak kiszolgálása, sokszor pedig egyre inkább azok megvalósítása: a cég működését mondhatni szoftverekbe öntik. A modern szolgáltatásorientált architektúrákban a folyamatok támogatására úgynevezett Business Process Management (BPM) eszközöket alkalmaznak, melyekkel automatizálhatóak, követhetővé és optimalizálhatóvá válnak az adminisztratív tevékenységek. A jelenleg elterjedt BPM-megoldásoknak is megvannak azonban a korlátai: nem elég rugalmasak az üzleti környezet változásának lekövetéséhez.

A mindennapi tapasztalatok azt mutatják, hogy míg a maguk a folyamatok viszonylag lassan változnak, addig a folyamatban szereplő paraméterek sokkal gyakrabban, ezek az úgynevezett üzleti döntési pontok. A hitelezési feltételekhez kapcsolódó konstrukciós lista például gyakrabban módosul, mint maga a hitelezési folyamat. A hagyományos megközelítésben a döntési pontokhoz tartozó szabályokat "beégetik" a szoftverbe, belekódolják a paramétereket, ráadásul a többféle szoftver miatt sokszor különböző programozási nyelveken. Ezek a döntési pontok jelenleg többnyire szétszórva találhatóak meg a különféle üzleti alkalmazásokban és egyéb szoftverekben, akár adatbázisokban, Excel-táblázatokban, vagy sokszor csak munkautasítások formájában léteznek.

Ennek a kifejezetten eklektikus, rendezetlen megközelítési módnak számos negatív következménye van Rácz Imre, az Alerant Informatikai Zrt. szakemberének tapasztalatai alapján, aki szerint a legsúlyosabb ezek közül, hogy egy üzleti szabályt érintő változtatáshoz, legyen szó akár egyetlen küszöbérték módosításáról, informatikai szakember bevonása szükséges. Az informatikai részleg vagy beszállító erőforrásai hamar szűk keresztmetszetté válhatnak, főleg régebbi, úgynevezett legacy alkalmazások esetén, melyekhez már nem áll rendelkezésre elegendő szakember. A változtatásokhoz pedig sokszor aránytalanul magas költségek társulnak, hiszen az üzletileg egyszerű változtatások is a programkód módosításával járhatnak.

BRM: a változás rugalmassága

Erre a problémára ad választ a Business Rule Management, vagyis a BRM, mely kiemeli az üzleti szabályokat az elszórt rendszerekből, központi szabálytárban helyezi el azokat, centralizálva kezelésüket. Használatukkal az üzleti felhasználók önállóan adaptálják szabályaikat a megváltozott körülményekhez, csökkentve az informatikai erőforrásigényt, egyúttal olcsóbbá és gyorsabbá téve a változások implementálását.

A BRM-eszközök megjelenésével megváltoznak az üzleti és informatikai oldalak feladatai. Több, korábban informatikai terület kerül át az üzlethez, köztük a szabálymeghatározás. Ennek a menete az egyik piacvezető terméknél, a JRules-nál a következő módon történik: a szabályok létrehozásáért felelős személy, az úgynevezett szabálygazda egy kötött struktúrájú, üzleti-szakterület specifikus nyelv, a BAL (Business Action Language) segítségével írja le a szabályokat, tulajdonképpen szintaktikailag helyes angol mondatokban fogalmazza meg azokat.

A banki hiteligénylés során például a banknak meg kell győződnie arról, hogy a hiteligénylő megfelelő jövedelemmel rendelkezik-e a hitel felvételéhez. Ehhez ellenőrzi a hiteligénylő éves jövedelmét, ami példánkban nem lehet kisebb 500 000 egységnél, továbbá az éves eladósodottság arányát, ami nem lépheti túl a jövedelem 30 százalékát. BAL–ban ezt "if … then …[else…]" szerkezetű mondattal tudjuk leírni:

Miután a gazda elvégezte a szabály rögzítését a központi szabálytárban, a háttérben a BRM-eszköz automatikusan lefordítja a szabálykiértékelő motor számára az üzleti nyelvet:

A két verzió között egyértelműen látszik a különbség: míg az előbbit lényegében bárki megfogalmazhatja, az utóbbihoz programozói tudás szükséges. Ha nem áll rendelkezésre a BAL-hoz hasonló magas absztrakciós szintű nyelv, valamint BRM-eszköz, mely azt interpretálni képes a szoftverek nyelvére, akkor a technikai szkriptnyelvet ismerő fejlesztő állandó bevonásával lehet csak létrehozni, majd később az igények megváltozásával módosítani az üzleti szabályokat -- ez pedig rontja a hatékonyságot, időben és költségben egyaránt.

A szabálymeghatározás mellett a BRM-eszközök további területeket is az üzlet irányítása alá helyeznek, így a szabályok karbantartását, menedzselését. Az üzleti területek számára mindezek eredményeképpen átláthatók lesznek az üzleti szabályok összefüggései, egyszerűbbé és gyorsabbá válik a felhasználásuk. Az IT pedig eközben arra tudja összpontosítani erőforrásait, hogy a szabályok kezeléséhez szükséges infrastrukturális hátteret a lehető legmagasabb színvonalon biztosítsa.

Egy szolgáltatásorientált architektúra igazán sikeres bevezetéséhez a vállalatnak nem csak üzleti folyamatait, hanem döntési szabályainak kezelését is felül kell tehát vizsgálnia. Az ezzel járó feladatkör-változások pedig új típusú ismeretet, nézőpontváltást várnak el mind az üzleti, mind az informatikai oldal szereplőitől. Az informatikai szakembereknek pontosan meg kell érteniük az üzlet elvárásait, hogy a lehető legmagasabb színvonalon szolgálhassák ki azt, az üzleti felhasználóknak pedig át kell látniuk területük informatikai struktúráját, folyamatait, működését is, hogy segíthessék az IT munkáját -- első lépésként a BRM-rendszer bevezetéséhez szükséges átgondolt tervezésben.

További részleteket az Alerant honlapján találhat.

[Az Alerant megbízásából készített anyag]