Adatrezidencia-architektúra gyakorlati útmutatója

Egy pénzügyi riport elkészítéséhez az egyik kolléga letölt egy táblázatot a felhőből, a másik adatot kér az ERP-ből, a harmadik pedig egy külső partner portáljáról másol adatokat. A folyamat működik - egészen addig, amíg fel nem merül a kérdés: pontosan hol vannak ezek az adatok, ki fér hozzájuk, és mi történik, ha egy rendszer vagy szolgáltató kiesik?

Az adatrezidencia-architektúra gyakorlati útmutatója nem elsősorban szerverek ország szerinti elhelyezéséről szól. Arról szól, hogy az üzlet számára fontos információk tárolása, feldolgozása, továbbítása és visszaállítása ellenőrizhető legyen. Egy 20-500 fős vállalatnál ez közvetlenül befolyásolja a működési folytonosságot, a riportok megbízhatóságát, a partneri bizalmat és a megfelelőségi kockázatokat.

Mi az adatrezidencia valójában?

Adatrezidenciának azt nevezzük, hogy az adat fizikailag és logikailag milyen földrajzi, jogi és üzemeltetési környezetben található. Nem elég azt tudni, hogy egy alkalmazás „felhőben fut”. Érdemes tisztázni, melyik régióban tárolja az elsődleges adatokat, hol készülnek biztonsági mentések, merre haladnak az integrációs üzenetek, és milyen országban működik az a támogató személyzet, amely szükség esetén hozzáférhet a rendszerhez.

A kérdés különösen akkor válik kézzelfoghatóvá, amikor egy webshop rendelési adatokat küld az ERP-nek, az ERP átadja az információt a számlázásnak, majd a logisztikai partner is megkapja a kiszállításhoz szükséges adatokat. Egyetlen rendelés adatai több rendszerben, több másolatban és akár több országban is megjelenhetnek. Ha ezt senki nem tervezte meg tudatosan, a vállalat valójában nem tudja teljes bizonyossággal, hol kezeli az adatait.

Az adatrezidencia ezért nem kizárólag jogi vagy informatikai kérdés. Üzemi kérdés is. Ha egy kritikus információ helye, tulajdonosa vagy visszaállítási módja nem egyértelmű, akkor a napi működés egy rejtett függőségre épül.

Adatrezidencia-architektúra: előbb az adat útját térképezze fel

A gyakori hiba az, hogy a szervezet szolgáltatót vagy felhőplatformot választ, mielőtt feltárná az adatáramlást. Ez olyan, mintha új raktárt építenének anélkül, hogy tudnák, milyen áruk, milyen gyakorisággal és honnan érkeznek oda.

A jó kiindulópont néhány kulcsfontosságú üzleti folyamat. Ilyen lehet a rendelés teljesítése, a gyártási munkalap kezelése, a számlázás, a bérszámfejtéshez kapcsolódó adatátadás vagy a vezetői riportkészítés. Minden folyamatnál azt kell megérteni, honnan indul az adat, ki módosítja, mely rendszerek kapnak belőle másolatot, és hol marad meg hosszú távon.

Nem minden adat igényel azonos védelmet vagy azonos földrajzi kezelést. Egy publikus termékkatalógus, egy belső készletjelentés, egy szerződés és a személyes adatokat tartalmazó HR-dokumentum eltérő kockázatot jelent. Az egységesen túl szigorú szabályozás feleslegesen drágíthatja és lassíthatja az üzemeltetést. A túl laza megközelítés viszont ellenőrizetlen hozzáféréseket és nehezen kezelhető megfelelőségi helyzetet eredményezhet.

Készítsen adatleltárt üzleti felelőssel

Az adatleltár nem egy IT-osztály által kitöltött technikai táblázat. Minden fontos adatcsoporthoz kell egy üzleti felelős, aki meg tudja mondani, miért szükséges az adat, meddig kell megőrizni, milyen hiba okozna üzleti problémát, és ki használhatja.

Érdemes rögzíteni az adat típusát, az elsődleges rendszert, az integrációk célrendszereit, a tárolási régiót, a mentések helyét, a megőrzési időt és a hozzáférési szerepköröket. Ha egy információ ugyanabban a formában három-négy rendszerben létezik, azt is fel kell jegyezni. A duplikáció nem mindig hiba: szükség lehet rá rendelkezésre állás, teljesítmény vagy jogszabályi megőrzés miatt. De minden másolatnak legyen indoka és gazdája.

A döntéseket a kockázat és az üzemi igény együtt vezesse

Az adatrezidenciáról szóló döntésben ritkán van egyetlen, mindenre jó válasz. Egy kizárólag hazai rendszerekkel működő vállalat számára indokolt lehet, hogy bizonyos adatok magyarországi infrastruktúrán maradjanak. Egy több országban értékesítő e-kereskedelmi cégnek viszont teljesítményi, ügyfélszolgálati vagy partneri okokból több régióban is szüksége lehet feldolgozásra.

A lényeg az, hogy a döntés dokumentált legyen. A vezetésnek értenie kell, mely adatok esetében követelmény a meghatározott földrajzi régió, melyeknél elfogadható más elhelyezés, és milyen kontrollok csökkentik a kockázatot. Ilyen kontroll lehet a titkosítás, a szigorú szerepköralapú hozzáférés, a naplózás, a rendszeres jogosultság-felülvizsgálat, valamint a tesztelt helyreállítási terv.

A földrajzi hely önmagában nem ad biztonságot. Egy helyben tárolt rendszer is kockázatos lehet, ha egy közös adminisztrátori fiókot használ több ember, nincsenek mentési próbák, vagy a hozzáférési naplók értelmezhetetlenek. Ugyanígy egy megfelelően tervezett, szabályozott felhőkörnyezet is lehet kontrollált megoldás, ha a szervezet tisztában van a felelősségi határokkal.

Különítse el az elsődleges adatot, a másolatot és a mentést

Sok üzembiztonsági probléma abból ered, hogy a vállalat nem tud különbséget tenni e három fogalom között. Az elsődleges adat az a hiteles forrás, amelyből a napi működés indul. A másolat lehet egy integráció miatt létrejött példány egy másik rendszerben. A mentés pedig nem napi munkára szolgál, hanem helyreállításra.

Ha a pénzügyi adatokat az ERP tekinti hitelesnek, de a vezetői riport egy kézzel frissített táblázatból készül, akkor a táblázat nem válhat csendben második igazságforrássá. Ilyenkor előbb a riportfolyamatot kell rendbe tenni: miért van szükség manuális átmásolásra, milyen adatok hiányoznak az ERP-ből, és melyik rendszerből kell automatikusan előállnia a riportnak?

Ez az adatrezidencia-architektúra egyik kevésbé látványos, mégis fontos része. Nem csupán azt rendezi, hol van az adat, hanem azt is, melyik adatban lehet megbízni.

Az integrációk gyakran rejtett adatútvonalak

Egy vállalat rendszerlistáján általában szerepel az ERP, CRM, webshop, számlázó és raktári rendszer. Kevésbé láthatók az adatforgalom szempontjából kritikus köztes elemek: integrációs szolgáltatások, e-mailes exportok, automatizált fájlátadások, külső riporting eszközök és fejlesztői tesztkörnyezetek.

Például egy webshopból érkező rendelés adata átmehet egy integrációs platformon, bekerülhet egy hibakezelési naplóba, majd egy e-mailes értesítésben is megjelenhet. Ha a rendelés tartalmaz személyes vagy üzletileg érzékeny adatot, akkor ezek az útvonalak mind az architektúra részei. Nem elegendő azt ellenőrizni, hogy a webshop és az ERP hol fut.

Ezért minden fontos interfésznél célszerű megvizsgálni, milyen adat halad át rajta, tárolódik-e átmenetileg, mennyi ideig marad meg, milyen hibakezelés történik, és ki látja a naplókat. Egy rosszul beállított hibajelentés évekig megőrizhet olyan adatokat, amelyekre az operációban már rég nincs szükség.

Tervezzen kiesésre, ne csak normál működésre

Az adatrezidencia döntéseinek valódi értéke hibahelyzetben látszik. Mi történik, ha az elsődleges régió nem elérhető? Mennyi adatvesztés fogadható el? Mennyi idő alatt kell helyreállnia a rendelésfeldolgozásnak, a termelési adatoknak vagy a számlázásnak?

Ezek nem kizárólag technikai kérdések. Ha a raktár négy órán keresztül nem látja a teljesítendő rendeléseket, az milyen késést, túlórát vagy ügyfélpanaszt okoz? Ha a termelés egy napig nem éri el a műszaki dokumentációt, képes-e biztonságosan dolgozni? A helyreállítási célokat ilyen üzleti következményekből kell levezetni.

A mentés csak akkor jelent védelmet, ha visszaállítható. A rendszeres helyreállítási próba ezért nem adminisztratív teher, hanem validáció. Megmutatja, hogy a dokumentáció valós-e, a jogosultságok rendelkezésre állnak-e, és a vállalat tényleg képes-e működésbe hozni a kritikus rendszereket.

Ne egy egyszeri projektként kezelje

Új partner, új ország, új webshop, felvásárlás vagy egy régi rendszer leváltása mind megváltoztathatja az adat útját. Az egyszer elkészített architektúra ezért gyorsan elavul, ha nincs változáskezelés mögötte.

Minden jelentősebb rendszerbevezetés vagy integráció előtt legyen egy egyszerű, de kötelező ellenőrzési pont: milyen adatot kezel az új megoldás, hol tárolja, kinek ad hozzáférést, milyen további szolgáltatók vesznek részt, és hogyan illeszkedik a mentési, naplózási és helyreállítási rendbe. Ez nem lassítja szükségszerűen a fejlesztést. A későbbi meglepetéseket, manuális kerülőutakat és költséges átalakításokat előzi meg.

A jó adatrezidencia-architektúra nem attól látható, hogy sok dokumentum készül róla. Attól, hogy egy vezető egy kritikus adatcsoportról gyorsan választ kap: hol van, ki felel érte, ki fér hozzá, mi kapcsolódik hozzá, és mi történik, ha az elsődleges rendszer nem elérhető. Ha ezekre ma csak több ember, több táblázat és hosszú e-mailváltás után érkezik válasz, ott érdemes az adat útjának feltérképezésével kezdeni.