A blokklánc-alapú vállalati architektúra tervezésének bevált gyakorlata

Ebben a cikkben útmutatások találhatók a vállalati architektúra megtervezéséhez, ebben az esetben a blockchain és más technológiák bevonásával.

A vállalati architektúra egy keret vagy modell, amely leírja a vállalkozás szerkezetét és funkcióját. Segít az építészeti elemek elemzésében, megtervezésében, megtervezésében, megvalósításában és karbantartásában. Amit meghatározunk, a logikai architektúra, nem pedig a fizikai architektúra. Ez az architektúra írja le, hogy az összetevők mit csinálnak, nem pedig a gyakorlatban történő megvalósításukat.

Az architektúrák különféle típusú összetevőket tartalmazhatnak, például üzleti folyamatokat, szervezeti egységeket, embereket, eszközöket, rendszereket és IT-infrastruktúrát. Általában a rendszerekre és a támogató infrastruktúrára összpontosítanak, olyan háttérre leképezve, amely üzleti egységeket vagy logikai rétegeket mutat.

Példaként az alábbiakban bemutatjuk az OEL Alapítvány vállalati architektúráját. Az OEL Alapítvány egy nonprofit szervezet, amely irányítást és erőforrásokat biztosít az Open Enterprise Logistics blokklánc ökoszisztéma fejlesztéséhez. Az architektúra bemutatja azokat az összetevőket, amelyeket a logisztikai termékek és szolgáltatások szállításában használnak az ökoszisztéma résztvevői számára.

Hogyan lehet megtervezni egy olyan vállalati architektúrát, amely magában foglalja a blockchain technológiát?

Nincs alapvető különbség az építészet megtervezésével - a blokklánc csak egy újabb műszaki elem. Vannak azonban a blockchain technológia néhány szempontjai, például az intelligens szerződések, amelyeknek az architektúrában összetevőként kell megjelenniük.

Tehát hogyan kezdjük meg általában a vállalati építészet megtervezését?

Nincsenek „helyes” vagy „rossz” válaszok, bár egyes megközelítések sokkal hasznosabbak, mint mások. Ne feledje, hogy a vállalati építészet is olyan élő dolog, amely idővel megváltozik és fejlődik.

Van néhány általános útmutatás, amelyek hasznosak az építészet tervezésében:

1. Tartsd egyszerűen

2. Lásd az ipari példákat és a bevált gyakorlatokat

3. Ismerje meg a releváns ipari fejleményeket

4. Határozza meg az építészet határát

5. Döntse el a használni kívánt szervezési alapelvet

6. Töltse fel az architektúrát a megfelelő összetevőkkel

7. Keresztesse a végleges architektúrát az ipari példákkal

8. Tekintse át és alapul vegye az architektúrát

Ne komplikáld túl

Általában véve, ha valami nem egyszerű, akkor az általában azért van, mert a bonyolultság egy vagy több tényezőt tükröz, például: hiányos elemzést és tervezést, túl alacsony részletességgel dolgozik, vagy túl sok dolgot próbál beépíteni a modellbe.

Az átfogó építészeti szabvány, például az Open Group Architecture Framework (TOGAF) teljes körű alkalmazásának próbálása szintén helytelen lehet, kivéve a nagyon nagy szervezeteket.

A vállalati architektúrát különféle bonyolultsági fokokkal lehet megtervezni. Néhány vállalati architektúra nagyon bonyolult és nehezen érthető, még az emberek számára is, akiket állítólag használni akarnak. Sokkal jobb, ha az architektúrát olyan egyszerűnek tartjuk, amennyire csak tudunk, anélkül, hogy elveszítjük a kulcsfontosságú információkat. Ez segíti az embereket az építészet és annak alkotóelemeinek megértésében és használatában.

A blokkdiagram jó alapot nyújt az egyszerű architektúrához. Ez lehetővé teszi számunkra, hogy megvizsgáljuk a fő alkotóelemeket és azok egymással való széles körű kapcsolatát anélkül, hogy részletesen leírnánk azok működését vagy kapcsolatát.

Lásd az ipari példákat és a bevált gyakorlatokat

Számos példa található az architektúrákra, eltérő bonyolultsággal, eltérő megközelítésekkel és szervezési elvekkel, valamint számos különféle típusú alkotóelemmel.

Gyakran nincs olyan szabványos architektúra-keret vagy modell, amely referenciaként használható. Ennek hiányában építészeti példákat kell keresnünk a vezető iparági résztvevőktől vagy az akadémikusoktól. Ez megmutathatja nekünk, hogy mások hogyan közelítették meg az építészeti elemzést és a tervezést, és alapul szolgálhatnak saját építészetünkhöz.

Időnként könnyű megtalálni széles körben eltérő megközelítéseket, amelyek zavaróak lehetnek.

Egy hasznos módszer a képek keresése a megfelelő kulcsszavak segítségével, és olyan érzés megszerzése, amely a modellek számára vizuálisan vonzó. Tekintse át ezeket magas szinten, anélkül, hogy elveszne a részletekben. Válasszon közülük négy-öt, amelyek különösen relevánsaknak tűnnek további felülvizsgálat és referencia céljából.

Nézze meg, mi a közös és mi a különbség. Mit tartalmaz az építészet és mi nem? Próbáljon gondolkodni az építkezés során alkalmazott szervezési elv (ek) ről. Milyen összetevők vannak felsorolva? Ne aggódjon, ha nem érti meg őket teljesen, vagy ha olyan elemeket tartalmaz, amelyek számodra irrelevánsak. Ne feledje, hogy nincs „helyes” vagy „rossz” válasz.

Az OEL Alapítvány vállalati architektúrájához referenciaként az Ethereum, az Ontology, a CSCC / IBM, a Tibco építészeti modelljeit és a kiválasztott iparági résztvevőket használtuk.

Ismerje meg a releváns ipari fejleményeket

Bármely iparág és egy sor technológia összefüggésében dolgozunk, amelyek folyamatosan változnak. Ez a viszonylag közelmúltban alkalmazott megközelítéseket irrelevánsnak és elavulttá teheti.

Meg kell próbálnunk megérteni ennek a helyzetnek a jelenlegi helyzetét, és meg kell próbálnunk előretekintni és azonosítani az ipar, a gazdaság és a technológiák várható jövőbeli fejleményeit. Ezt nagyon nehéz megtenni. A legjobb megközelítés az, ha megpróbáljuk meghatározni azokat a széles körű fejleményeket, amelyek relevánsak lesznek.

A blokklánc-alapú architektúra esetében a szokásosnál inkább hátrányos helyzetbe kerülünk, tekintettel a technológia viszonylagos éretlenségére és a gyors változási ütemre.

Az OEL Alapítvány vállalati architektúrájához négy olyan fejlesztési kategóriát azonosítottunk a piacon és a technológiát, amelyek különösen fontosak az OEL Alapítvány ökoszisztémája szempontjából:

1. Digitális üzleti modellek

2. Blokklánc-technológiai fejlesztések (különös tekintettel a feltörekvő ökoszisztéma-támogatásra)

3. A blockchain és az üzenetküldési technológiák konvergenciája

4. A felhőalapú szolgáltatások, például a szoftver-szolgáltatásként (SaaS), a szolgáltatás-szolgáltatásként (PaaS) és az infrastruktúra-szolgáltatásként (IaaS) egyre növekvő használata és jelentősége.

Adja meg az építészet határát

Mint minden rendszert, meg kell határoznunk az architektúránknak a rendszerhatárt, elválasztva a rendszer belsejét és a rendszeren kívüli részét.

Időnként a határ nem a megfelelő helyen húzódik. Előfordulhat, hogy sok külső szereplőt és harmadik féltől származó összetevőt (amelyeket nem használunk közvetlenül az építészet megvalósításához) láthatunk egy építészetben. Ez nem segít beazonosítani azokat az alapvető belső elemeket, amelyeket az építészethez használni fognak.

Ha hasznos megvizsgálni az építészet és a környezet kapcsolatát, ezt egy grafikus kiadvány, például egy kontextusdiagram segítségével kell megtenni. Ez az absztrakció magasabb szintjén áll, mint maga az építészet.

Az OEL Alapítvány vállalati architektúrájához harmadik féltől származó technológiát és szabványokat használunk az építészetben, valamint külső partíciókhoz és rendszerekhez is kapcsolódunk építészeti összetevők, például API-k, üzenetküldő köztes szoftverek és láncok közötti integrációs komponensek felhasználásával. Mindezeket úgy tekinthetjük, mintha az építészet határán lennének.

Az ökoszisztéma résztvevői, a külső rendszerek vagy eszközök, vagy az ezeknek az építészethez történő integrálására szolgáló eszközök az építészet határán kívül helyezkednek el.

Döntse el a használni kívánt szervezési alapelvet

A szervező elv (ek) segítenek bennünket az építészet felépítésében, és alapot képeznek az építészet összetevőinek az építészet különböző részeire történő hozzárendeléséhez.

Számos megközelítést alkalmazhatunk itt, ideértve az alábbiak közül egyet vagy többet:

1. Teljes körű üzleti folyamatáramlás

2. A vállalkozás belső szervezeti felépítése (külső kapcsolatokkal vagy anélkül)

3. Szabványos referenciamodell

Megpróbálhatjuk az end-to-end üzleti folyamatokat felhasználni az összetevők megszervezésére, például szállítóról vásárlóra. Az építészet elemeit ezután a felek közti folyamatfolyamat mentén rendezik.

Az architektúra gyakran tükrözi a belső szervezeti struktúrát, amely olyan szervezeti funkciókból (vagy szervezeti egységekből) áll, mint például a marketing, értékesítés, műveletek, pénzügyek stb. Ez magában foglalhatja a külső rendszerekkel vagy felekkel való kapcsolatokat is.

Az OEL Alapítvány vállalati architektúrájához az ISO Open Systems Interconnection modell (OSI modell) variációját használjuk szervező elvként. Az OSI modell egy fogalmi modell, amely leírja a telekommunikációs vagy számítási rendszer kommunikációs funkcióit.

Az OSI modell hét réteget használ, de számos blokklánc-alapú architektúra háromrétegű modellt használ. Ezeket néha különféle néven nevezik, de általában Platform (vagy Alkalmazás) réteget, Protokoll réteget és Hálózati réteget tartalmaznak. A „protokoll” fogalma önmagában zavaró lehet, nem egyértelmű és értelmezhető. Hasznos lehet megállapodni abban, hogy mit értenek ezek a kifejezések, ami segít azonosítani az összefüggéseket az adott összefüggésben.

Töltse fel az architektúrát a megfelelő összetevőkkel

Ha megvan a teljes építészeti struktúra, akkor eldönthetjük, hogy az architektúrának mely összetevőket kell tartalmaznia, és ezeket hozzárendelhetjük az építészet megfelelő részéhez.

Használhatunk olyan összetevőket, amelyeket a referencia-architektúrákban azonosítottunk, valamint olyan komponenseket, amelyeket beépíteni szándékozunk, amelyek tükrözik az ismert vagy feltételezett technológiai fejlesztéseket vagy az ökoszisztéma résztvevőinek követelményeit.

Ez nagyon iparágra, sőt szervezetre vonatkozik, így nehéz általános tanácsokat adni.

Két általános alapelvet kell alkalmazni:

1. Az alkotóelemeknek nagyjából azonos felbontásúaknak kell lenniük

2. Korlátozza az alkatrészek számát

Nem akarjuk, hogy az alkatrészek méretükben szignifikánsan különbözzenek másoktól. Ez gyakran nyilvánvaló, ha egy komponenst valami „mag” -nak neveznek, ami azt sugallja, hogy magasabb felbontású lehet, mint más alkatrészek, és esetleg logikai részekre kell bontani.

Hasznos hüvelykujjszabályt alkalmazni az architektúrában megjelenő összetevők számára. Egy nagy, összetett multinacionális szervezet számára ez potenciálisan nehéz lehet, mivel különféle alkalmazások százai is lehetnek benne. Ezeket azonban logikusan csoportosítani lehet alkalmazáskategóriákba. Általános megközelítés az, hogy egy rétegben hét plusz vagy mínusz két összetevőt használnak, és a teljes architektúrában nem lehet több, mint húsz elem.

Keresztesse a végleges architektúrát az ipari példákkal

Végül áttekintheti az architektúrát az eredetileg azonosított referenciamodellekkel szemben, ezek segítségével ellenőrizheti az architektúra teljességét és következetességét.

Tekintse át az egyes referenciamodelleket az architektúrája alapján, és ellenőrizze, hogy a referenciamodell összetevői megtalálhatók-e a sajátban. Ha nem, akkor kérdezd meg, miért van ez és miért kell bevonni őket. Ha az architektúrában vannak további összetevők, akkor kérdezze meg, szükség van-e ezekre, és próbálja megérteni, miért nem szerepelnek a referenciamodellben. Lehet, hogy nem relevánsak e modell összefüggésében.

Ez jó észellenőrzés, hogy az építészet valamilyen kapcsolatban áll-e más modellekkel, amelyeket láthat, hogy a gyakorlatban használják.

Tekintse át és alapozza meg az architektúrát

Ezen a ponton megvan az építészet működő modellje. Most továbbadhatja azt kollégák és más érdekelt felek számára felülvizsgálat céljából, és megpróbálhatja felhasználni a gyakorlatban. Valószínűleg észreveszi, hogy bizonyos változtatásokra van szükség, ami normális. Ne félj alkatrészeket mozgatni, ha úgy gondolja, hogy nincsenek a megfelelő helyen, vagy eltávolíthatja vagy behelyezheti az új alkatrészeket.

Ne felejtsük el, hogy a vállalati architektúra egy élő dolog, amely idővel megváltozik, tükrözve a szervezet változó igényeit vagy az iparban vagy a technológiában bekövetkező külső változásokat.

A vállalati architektúra-modellt most verzió-ellenőrzés alá lehet helyezni, és felelõsséggel tartozik annak folyamatos karbantartásáért, amelyet egy adott funkcióhoz vagy félhez rendelhetnek. Nagy szervezetben ez lehet formális építészeti funkció vagy egyéni építész. Kisebb szervezetekben ezt a funkciót egy vagy több személy vállalhatja, akik tipikusan üzleti elemzők vagy rendszertervezők.

Reméljük, hogy ez a cikk hasznos lehet abban, hogy néhány útmutatást ad Önnek arról, hogyan kell megközelíteni az elemzést és a tervezési munkát a saját vállalati architektúráján, és sok sikert kívánunk ehhez.

Mark Nelson az OEL Alapítvány műszaki vezetője. Ha többet szeretne megtudni az OEL Alapítványról, látogasson el a https://oel.foundation weboldalra, vagy forduljon közvetlenül a szerzőhöz a mark.nelson@oel.foundation e-mail címen.

Ön is csatlakozhat az Alapítványhoz a táviratban.