A szolgáltatásorientált architektúra (SOA) egy napjainkban rendkívül elterjedt vállalati integrációs stratégia, köszönhetően az újrafelhasználható elemeket, egyszerű, átlátható struktúrát, valamint rugalmas telepítést lehetővé tevő megközelítésének. A SOA olyan üzleti folyamatokat valósít meg, melyek szabványos adatformátumokat és kommunikációs protokollokat használó üzleti szolgáltatásokból épülnek fel.

Ezek a szolgáltatások tipikusan két fő kategóriába sorolhatók:

• Az adatszolgáltatások kinyerik, módosítják/konvertálják, rögzítik és elérhetővé teszik az adatokat.

• A döntési szolgáltatások az eltérő adattípustól függetlenül lehetővé teszik a megfelelő döntések meghozatalát. Tipikusan továbbítják az adatokat vagy dokumentumokat, és visszaküldenek egy adatot, amely egy üzleti szabály végrehajtásán alapuló döntésre vagy tevékenységre épül. Például ha a szolgáltatás egy biztosítási alkalmazást ér el, egy listával tér vissza a jelentkező minősítésének megfelelő programokról és árakról.

A döntési szolgáltatásoknak azonban számos olyan aspektusa van, melyek hatékony kezelése nehéz az IT számára.

1. probléma: A szolgáltatások, mint fekete dobozok
A SOA-alapú működésnél az üzleti folyamatokkal, és ennek megfelelően a szabályokat tartalmazó döntési szolgáltatásokkal több szereplő foglalkozik. Az üzleti menedzser a folyamatok futtatásáért felelős, valamint koordinálja a szolgáltatások kialakítását. Informatikai oldalon az architekt tervezi meg a szolgáltatásokat. Ezeket majd a szolgáltatásfejlesztő implementálja, és ő valósítja meg a döntési logikát is. Több különböző személy, több különböző szerepkörben felelős tehát a folyamatért, s jellemzően valamennyien csak a saját területüket látják át. Különösen az üzleti menedzsernek jelent ez problémát, aki számára a rendszer csak egy fekete doboz. A rálátás ilyen hiánya komoly problémát jelent például akkor, ha egy szabályt meg kell változtatni. Ezt a folyamatot tipikusan az üzleti menedzser indítja el és kommunikálja - az üzleti zsargon használatával -, míg az architektek és fejlesztők az implementálást végzik el. A kód telepítése azonban nagyon nehéz, ha nem tudni, ki a felelős a szolgáltatásokért, és pontosan kiket érintenek. Gyakran ezt a problémát úgy oldják meg, hogy egy-egy új verziót telepítésekor külön szolgáltatásként kezelnek. Megmutatják az ismert felhasználóknak azzal a szándékkal, hogy az végül majd a maradék felhasználókhoz is eljut. Ez a megoldás azonban a lassúság mellett a szolgáltatásszám túlzott növekedéséhez is vezet, s újabb problémákat vet fel. Honnan tudhatja a menedzser, melyik verzió érvényes? Hogyan menedzselheti valamennyit eredményesen?  A működés és telepítés részleteinek átlátása nélkül senki nem tudja kezelni a szolgáltatások és funkciók burjánzását. Mi több, ezek a szolgáltatások az újrafelhasználhatóságot sem teszik lehetővé. Ha a menedzser nem tudja leírni, hogy a szolgáltatások hogyan hozzák meg a döntést, a szolgáltatás nem lesz újrahasználható.  

2. probléma: Mi történik a fekete dobozon belül?
Mivel az üzleti szabályok, melyeket a döntési szolgáltatások implementálnak, gyakran törvényi előírások, fontos, hogy auditálhatók legyenek. Más szóval, rekonstruálhatóvá kell tenni, hogy az alkalmazás milyen lépéseken keresztül jutott el egy következtetés levonásáig. A szokásos út eddig a logikai döntéselem logok generálása volt. Ennek a megoldásnak azonban több lényeges korlátja van:

• Nehéz rekonstruálni a döntési utat

Egyrészt nehézkes a logokból dolgozni, másrészt gyakran tartalmaznak külső adatokat  - például külső path-okat - és a fejlesztőtől órákat vesz el, hogy egy nyomtatott anyagból kiderítse, mikor mi történt.

• A túl sok adatrészlet és IT-adat áttekinthetetlenné válik

Hacsak nem tervezték a log keretrendszert speciálisan erre a feladatra, túl sok részletet fog tartalmazni (a „Tegyünk bele mindent, mert bármikor szükség lehet rá később” megközelítés miatt). A log ezért kevés használható információt tartalmaz, vagy azok túl technikaiak. A kezdeteknél az audit így nehézkes lesz, a későbbiekben pedig egyenesen lehetetlenné válik.

• Ritka a folyamatos loggolás

A lognak helyesen kell tükröznie a döntési folyamatot. Ennek érdekében a döntési logika valamennyi módosításánál át kell adni a szükséges adatokat a log módosításához. A napi rohanásban azonban sem az üzleti felhasználók sem az informatikusok nem szeretnek időt áldozni a programkód megváltoztatásakor a logrendszer frissítésére. Egy idő után a logok nem lesznek szinkronban az általuk monitorozott szolgáltatással, és lehetetlenné válik a döntési logika nyomon követése.

3. probléma: A szabályok feltérképezése az újrafelhasználható döntési szolgáltatásokhoz
A SOA-migráció gyakran két-lépcsős feladatként jelentkezik. Egyrészt a meglévő programokat webszolgáltatásokkal rejtik el, másrészt a szolgáltatásokat összekapcsolják a SOA-implementációhoz. Ennél az egyszerű megközelítésnél azonban tekintetbe kell venni egy lényeges megszorítást: a létező szoftvermoduloknak külső változtatás nélkül is jól kell működniük SOA-komponensként. Ez az egyik meghatározó tulajdonsága a SOA-újrafelhasználhatóságnak. A meglévő alkalmazásokat azonban ritkán készítették újrafelhasználható szolgáltatás szemlélettel, inkább választották azt az utat, hogy csak összeillesztik a szolgáltatásokat. Sok SOA-implementáció összedrótozása azonban túlméretezettséget és nehezen kezelhető komponenseket eredményez. SOA-nak tűnnek, de valójában olyan webszolgáltatás protokollok, melyeket kommunikációra használnak. Ez e helyzet még rosszabb a döntési szolgáltatásoknál. Az üzleti szabályok gyakran a forráskódban, az alkalmazás nagyon mélyen fekvő rétegében követhetők csak nyomon. Sok esetben az azonos üzleti szabályokat alkalmazó megoldások különböző verziókat használnak, ami ellentmondásokhoz vezet. A szabályok ráadásul gyakran fekete dobozok, melyeket az informatika elrejt az üzleti oldal elől, és így nehéz az előírások és döntések egységesen megfogalmazott készletévé alakítani őket.


Átlátható döntési szolgáltatások
A helyes SOA-működéshez a vállalatnak felül kell vizsgálnia döntési szolgáltatásainak kezelését. Fel kell térképeznie az üzleti folyamatokat, és átlátható, testre szabható, újrafelhasználható és auditálható döntési szolgáltatásokat kell kialakítania. Ha kezelhetetlen, fekete doboz megközelítést használ, elrejtve a meglévő kódot, nem fogja a SOA-átalakítás eredményeit élvezni. Az újrafelhasználhatóság helyett csak egy újabb réteg bonyolítja az architektúrát. Az átláthatóság érdekében új típusú döntési szolgáltatásokra van szüksége, amelyekben a szabályok tervezését és menedzselését az üzleti elemző végzi, aki így betekintést kap a döntéshozás mechanizmusába. Megnézheti, módosíthatja, tesztelheti, szimulálhatja az üzleti folyamatokat.
A SOA különálló szolgáltatásokból épül fel, melyek más szolgáltatásokból is elérhetőek. Az átlátható döntési szolgáltatás megvalósításával egy ilyen architektúra kulcstevékenységekre vagyis döntésekre épül. E megközelítés használatával az üzleti szabályok (az üzleti elemzők által) formalizáltak, és a vállalati repository-ban helyezkednek el. Amikor valamelyik szolgáltatásnak vagy alkalmazásnak szüksége van döntési mechanizmusra, egyszerűen belép a szolgáltatásba és meghatározza a végrehajtandó szabálysort. Az üzletiszabály motor aztán végrehajtja a szabálysort, és visszatér a megfelelő döntéssel vagy értékkel. Ez a tervezés támogatja és biztosítja a SOA-megvalósíthatóságát, hiszen

• Újrafelhasználható szabályokra épül

Ugyanazt a szabályt tudja felhasználni valamennyi olyan alkalmazás, amelynek azonos típusú döntésre vagy adatértékelésre van szüksége. A hagyományos, mély kódban fellelhető szabályok módszere átadja a helyét a szinkronizált, összetett alkalmazásoknak. Valamennyi olyan alkalmazás, melynek azonos döntésre van szüksége, azonos szabályt használ fel.

• A szabályok gyorsan módosíthatók

Az üzleti szabályokat azonnal telepítik, így a szabályozók vagy előírások változása a központi szabály repository-n keresztül gyorsan és átfogóan átvezethető. Mivel a szabályváltozások rendkívül gyakoriak – új szabályokat vezetnek be, a régieket pedig módosítják –, a gyorsaság az egyik legfontosabb igény napjainkban.

• Szöveg alapú szabályleírások

A szöveg alapú szabályokat egyszerűbb megírni és telepíteni, mint a kódalapúakat, ezért ezek nagyobb IT-rugalmasságot tesznek lehetővé. Segítségükkel egyedi megoldások hozhatók létre, tesztelhetők az új eljárások, ellenőrzési pontok implementálhatók, valamint megtervezhetők az egyes célcsoportoknak szóló ajánlatokat – s mindezt programozás nélkül. A döntési logika egy újrafelhasználható szolgáltatás, és így hatékonyan telepíthető a teljes vállalatnál.

• Könnyű implementálni

Az üzleti szabály technológia nem igényli a rip-and-replace (megszakítás és elmozdítás) típusú implementációt. Inkrementális installációval megoldható, a meglévő alkalmazással párhuzamosan futtatható. Az igényeknek és az események ütemezésének megfelelően migrálható aztán.


Az üzleti szabályok szerepe a BPM és workflow megoldásokban

Az üzleti logika az üzleti folyamatokon belül gyakrabban változik, mint maga az üzleti folyamat. Fontos tehát, hogy a szabályokat a folyamatok módosítása nélkül változtathassuk meg. A gyorsan változó üzleti igényeket a hagyományos BPM-fejlesztési életciklus nem tudja követni. A BRM-eszköz segítségével azonban lerövidül a folyamatfejlesztési ciklus (Time to Market).

A BRMS-eszköz

• automatizálja az üzleti folyamatokban a kulcsdöntések meghozatalát, valamint

• leegyszerűsíti az üzleti folyamatok struktúráját.

• Segítségével a döntések az üzleti folyamatokból, mint szabványos üzleti szolgáltatások hívhatók meg,

• gyorsabban módosíthatók, mint a teljes üzleti folyamat.