A rendszermérnöki csoport akkor vezeti az üzleti architektúrát, amikor a munka sok összekapcsolt alkatrésztől függ. Ez a csoport az üzleti célokat, az adatokat, a szoftvereket, az embereket, a szabályokat és a műveleteket egyetlen rendszerként kezeli.
Az üzleti architektúra meghatározza e rendszer formáját. Megmutatja, hol van ma a cég, hová szeretne eljutni, és hogyan tud mozogni a kettő között. Egy rendszermérnöki csoport jól pozicionálva van arra, hogy ezt a munkát vezesse, mert tanulmányozza, hogyan működnek együtt az alkatrészek egy teljes élettartamon át.
Ez a szerep egy egyszerű kérdéssel kezdődik: mit kell tennie az egész vállalatnak?
A válasz szélesebb, mint egy szoftverfunkciók listája. Egy rendszernek megoszthatnia kell az adatokat, védenie kell a nyilvántartásokat, támogatnia kell a személyzetet, teljesítenie kell a jogi kötelezettségeket, és tovább kell működnie, ha egy szolgáltatás kiesik. Minden szükséglet befolyásolja a többit. Egy új platform megoldhat egy problémát, miközben hozzáad egy új adattárolót, hozzáférési szabályt vagy támogatási terhet.
Az üzleti architektúra ezeket a hatásokat egyetlen nézetbe hozza össze. A rendszermérnöki csoport ezt a nézetet összeköti a valós tervezési döntésekkel.
A csoport a rendszergondolkodáson keresztül vezet
A rendszermérnöki tevékenység a szükségletekkel és korlátokkal kezdődik. Ezeket aztán egyértelmű követelményekké, lehetséges tervezésekké, teszteké és üzemeltetési tervek alakítja át. Ez a munka lefedi egy rendszer életét, a korai tervezéstől a kivonásig.
Ugyanez a minta illik az üzleti architektúrára. Egy nagy üzleti rendszer nem ér véget azzal, hogy egy projekt élesedik. Frissítésekre, támogatásra, biztonsági ellenőrzésekre, adatvezérlésre és változási tervre van szüksége.
A csoport ezért segít meghatározni több kapcsolódó nézetet:
- Üzleti képességek, vagyis amit a vállalatnak meg kell tudnia tenni
- Információáramlás, vagyis hogyan mozognak az adatok a csapatok és rendszerek között
- Alkalmazásszolgáltatások, vagyis a szoftver, amely kulcsfontosságú feladatokat lát el
- Technológiai platformok, vagyis a hálózatok, felhőszolgáltatások és eszközök, amelyek futtatják őket
- Biztonsági és ellenőrzési igények, beleértve a hozzáférést, a nyilvántartásokat és a audit trail-okat
- Egy szállítási sorrend, amely megmutatja, mely változások függenek másoktól
Ezek a nézetek hasznossá teszik az architektúrát. Egy diagram önmagában nem vezet egy vállalatot. Egy hasznos architektúra minden tervezési döntést összeköt egy üzleti szükséglettel és ismert korláttal.
Például egy pénzügyi folyamat függhet egy rendszerből származó ügyféladatoktól és egy másikból származó fizetési adatoktól. Az architektúrának meg kell mutatnia, ki tulajdonosa minden egyes rekordnak, hogyan cserélődnek ki az adatok, és mi történik, ha egy csere sikertelen. A rendszermérnöki csoport ezután áttekintheti az egész folyamatot, ahelyett, hogy izoláltan jóváhagyna minden egyes kapcsolatot.
Ez a közvetlen oka annak, hogy a csoport vezeti az üzleti architektúrát: képes tesztelni a helyi döntések hatását az egész rendszerre.
A irányítás döntésekké alakítja a terveket
A vezetéshez egyértelmű döntési folyamatra is szükség van. Enélkül az architektúra dokumentumok halmazává válik, amelyet a szállító csapatok figyelmen kívül hagyhatnak.
Egy rendszermérnöki csoport biztosíthatja ezt a folyamatot architektúra-áttekintésekkel, döntési naplókkal, tervezési szabályokkal és technikai útvonaltervekkel. Egy architektúra-áttekintés azt kérdezi, hogy egy javasolt változás illeszkedik-e a céltervezéshez. Emellett ellenőrzi a biztonságot, az adatminőséget, a támogatási igényeket, a költségkorlátokat és a jövőbeli változásokat.
Egy döntési napló elmagyarázza, miért hozták meg egy döntést. Megállapíthatja, miért használ egy alkalmazás egy jóváhagyott interfészt, miért maradnak az adatok egy bizonyos rendszerben, vagy miért nem adnak hozzá új szolgáltatást. Ez a napló segít a későbbi csapatoknak megérteni a döntést anélkül, hogy újra kellene vitatniuk az egész debattot.
A csoportnak kapcsolatokat kell fenntartania az üzleti vezetőikkel is. Az üzleti architektúra nemcsak technikai tevékenység. Az üzleti tulajdonosok határozzák meg a célokat és korlátokat. A pénzügy szabályozhatja a költségvetési kereteket. A jogi és biztonsági csapatok szabályozhatják az ellenőrzési igényeket. Az üzemeltetési csapatok tudhatják, hol fog egy tervezés a napi használat során megbukni.
A rendszermérnöki csoport vezeti a tervezési folyamatot, de nem helyettesíti ezeket a tulajdonosokat. Szerepe, hogy behozza az ő szükségleteiket egyetlen modellbe, és bemutassa a kompromisszumokat.
Ez a pont fontos, amikor a cégek AI-t vagy automatizálást vezetnek be. Egy AI-szolgáltatás jóváhagyott adatokat, identitás-ellenőrzést, naplózást, ellenőrzési lépéseket és hibajavítási módot igényelhet. Módosíthatja azt is, ahogy a személyzet elvégez egy feladatot. Az architektúrának le kell fednie az egész szolgáltatást, nem csak a modellt.
Ugyanez a szabály vonatkozik a felhőbe való migrációra, a megosztott adattárhelyekre és a nagy szoftvercsereprogramokra. Minden változás többet érint, mint a látható projekt határát.
Egy gyakorlati korlát
Van egy egyértelmű korlát. Egy rendszermérnöki csoport nem teheti hatékonnyá az üzleti architektúrát pusztán technikai kontroll útján.
Az architektúra mutathatja a megfelelő utat, de az üzleti prioritások változhatnak. Egy fúzió, új szabály, ellátási probléma vagy sürgős ügyfélszükséglet más választásra kényszeríthet. Régi rendszerek hiányozhatnak a tiszta interfészekből. Az adatbirtoklás lehet tisztázatlan. A csapatoknak eltérő céljaik vagy készségeik lehetnek.
Ezek a korlátok bizonytalanságot teremtenek. Egy célarchitektúra-terv nem jósolhat meg minden jövőbeli szükségletet. Egy célarchitektúra egy működő útmutató, nem pedig egy rögzített ígéret.
Ezért a csoportnak rendszeres áttekintésre van szüksége. Követnie kell a döntéseket, a nyitott kockázatokat, a rendszerfüggőségeket és az üzleti célok változásait. Lehetővé kell tennie a korlátozott kivételeket is, ha egyértelmű ok áll fenn. Egy naplózás nélküli kivétel rejtett architektúra-adóssággá válik. Az architektúra-adósság nehezebbé teszi a későbbi munkát, mert a régi döntések már nem láthatók.
A legerősebb üzleti architektúra-folyamat a változást normálisnak tekinti. Stabilan tartja a fő tervezési szabályokat, miközben lehetővé teszi, hogy a részletek változzanak. A haladást a döntések és a rendszer egészségi állapota alapján méri, nem pedig a készült diagramok száma szerint.
Egy hasznos teszt egyszerű: egy vezető képes magyarázni, miért létezik egy nagyobb rendszer, mire támaszkodik, ki birtokolja az adatait, és hogyan változhat? Ha a válasz homályos, az architektúra még nem látja el a feladatát.
A rendszermérnöki csoport úgy vezeti az üzleti architektúrát, hogy ezt a kérdést aktívan tartja az egész vállalatban. Összeköti az üzleti szándékot a rendszer struktúrájával. Teszteli a linkeket a szoftver, az adatok, az emberek, az ellenőrzések és a műveletek között. Rögzíti a döntéseket, hogy a későbbi munka rajtuk épülhessen.
A gyakorlati tanulság az, hogy az üzleti architektúra akkor működik a legjobban, mint egy folyamatos mérnöki diszciplína. Egyértelmű tulajdonosokra, látható döntésekre és a rendszer egészének rendszeres áttekintésére van szüksége. A terv változni fog. A megalapozott változtatások módszerének nem szabad.
Ez a minta központi szerepet játszik az EuroOp Insights-ban: egy alkalmazott K+F minta és egy gyakorlati tanulság az EuroOp termékei mögötti pipeline-ból. Ebben az esetben a tanulság közvetlen: a rendszermérnöki tevékenység az üzleti architektúra számára eszközt ad arra, hogy bizonyítékokon, kompromisszumokon és kontrollált változáson keresztül vezessen.