facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přihlášení SystemNEWSPřehledy
 
Tematické seriály

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 
Nové!

RPA - automatizace procesů

Softwaroví roboti automatizují obchodní procesy.

články >>

 
Nové!

IoT – internet věcí

Internet věcí a jeho uplatnění napříč obory.

články >>

 
Nové!

VR – virtuální realita

Praktické využití virtuální reality ve službách i podnikových aplikacích.

články >>

 
Nové!

Bankovní identita (BankID)

K službám eGovernmentu přímo z internetového bankovnictví.

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
 
Partneři webu
IT SYSTEMS 9/2021 , AI a Business Intelligence , Trendy ICT

Od anarchie v datech k jejich monetizaci

Principy návrhu datově centrických IT architektur

Stefan Brock


Datově centrická architektura odděluje data z prostředí heterogenních aplikací s cílem vytvořit jejich fond (pool), který může být konzistentně využíván. Tento článek představuje klíčové principy návrhu i příklad realizace v praxi.


Pokrok v příštích desetiletích bude určován novou vlnou průmyslových a profesionálních dat, s nimiž mohou organizace vytvářet hodnotu ve formě nových toků příjmů, nových byznysových modelů, lepších zákaznických zkušeností a lepšího rozhodování. Například McKinsey odhaduje, že monetizace dat z propojených automobilů by mohlo hráčům mobilního ekosystému do roku 2030 poskytnout od 250 miliard do 400 miliard dolarů ročního přírůstku.

Není však jisté, do jaké míry budou schopny jednotlivé organizace tyto příležitosti skutečně materializovat. Aby toho mohly dosáhnout, musejí začít budovat řadu věcí souvisejících s monetizací dat – tj. musejí dovést k dokonalosti proces jejich extrakce, agregace, zpracování a analýzy a dát je k dispozici svým ekosystémům.

Mandát API vs. datová anarchie

Jak to funguje, ukázali cloudoví giganti. Jejich výhoda – byli schopni od začátku navrhnout svoje IT architektury jako data centrické. Například Jeff Bezos prohlásil v roce 2002 svoje známé „Pravidlo API“, které od té doby funguje v celém Amazonu a platí pro veškeré výměny dat prostřednictvím služebních rozhraní mezi aplikacemi a službami – bez výjimky a bez ohledu na použité technologie – a kdokoliv jej poruší, bude vyhozen.

Situace ve většině dalších společností je naopak zcela opačná. Jsou doslova zoologickými zahradami nejrůznějších jímek dat držených pospolu v jakémsi syrovém polotovaru připraveném k použití pomocí hromady skriptů, rozhraní a jednotlivých propojení mezi dvěma body. Z dlouhodobého hlediska jsou tyto „špagetové architektury“ nejen nákladné na provoz, ale z hlediska monetizace také velmi obtížně zvladatelné. Kvalita takových dat je často chabá a jejich velké množství leží ladem. Podle globálního průzkumu IDC a Seagate využívají společnosti pouze třetinu dat, která mají k dispozici. Proto je důležité takovou společnost celkově překlopit na datově centrickou IT architekturu – podle modelu cloudových gigantů, ale za obtížných podmínek daných historicky budovaného prostředí jejich IT.

Principy návrhu datově centrické architektury

Klíčové principy cílové datově centrické architektury lze snadno shrnout. Jejím základem je oddělit data od aplikací, které data vytvářejí, a to prostřednictvím kanálu vedoucím přes hlavní datový rozbočovač (hub). Ten využívá datové streamovací technologie typu Kafka nebo HPE Ezmeral Data Fabric, doplněný o datové storage založené na relační, NoSQL a grafické databázi, a stejně tak o datová jezera (obvykle s Hadoop). Každá aplikace funguje jako „tvůrce“ dat pro datový hub, kde je každý dotaz považován za „konzumenta“ v rozsáhlém, distribuovaném datovém fondu (poolu). Toto vše je zabudované a schované v datovém pracovním rámci.

V následujícím materiálu napřed popíšeme klíčové principy návrhu takové architektury. V praxi však do jeho nasazení vstupují organizační, kulturní a korporátní politické bariéry. Fiktivní případová studie pak nakonec ukazuje, jak je lze překonat.

Princip návrhu 1: Všechna data běží jako tok událostí přes datový hub

Všechny datové zdroje pouštějí svá data do datového hubu přes tok událostí. V případě aplikací jde o všechna data z logického datového modelu; v případě zařízení IoT jsou to lokálně posbírané informace o jejich stavech. Data jsou vysílána ve zdrojovém formátu; na aplikační úrovni se nemá provádět žádná transformace, protože to způsobuje chyby a ztrátu informace. Propojení je založeno na principu propoj jednou – tedy jedno propojení pro jeden zdroj dat. Pro přenos dat je k dispozici více možností, včetně protokolů MQTT pro IoT, Kafka Connect, CDC (Change Data Capture), Apache NiFi atd. Čím je vysílání blíže základnímu modelu zdroji dat, tím lze integraci provést rychleji a levněji. Dotazující aplikace a služby (konzumenti) komunikují podobně jako datové zdroje (tvůrci dat) přes datový hub. To odstraňuje nutnost přenastavovat s každým novým dotazem rozhraní pro dodatečnou informaci.

Obr. 1: Propojení do datového hubu je založeno na principu „propoj jednou“ – jedno spojení pro datový zdroj. Obr. HPE.
Obr. 1: Propojení do datového hubu je založeno na principu „propoj jednou“ – jedno spojení pro datový zdroj. Obr. HPE.

Princip návrhu 2: Všichni tvůrci dat publikují metadata

Aby bylo možno využívat data dlouhodobě, jsou všechna data běžící přes hub dokumentována. To zahrnuje přinejmenším relevantní sémantická metadata (údaje o významu dat) a jejich klasifikaci. Jak se pak architektura rozrůstá, přidávají se k metadatům další informační příznaky jako například: odpovídají GDPR, žádost o informaci GDPR, výmaz GDPR, automatický sběr dat, manuální sběr, informace o reálném čase, informace o periodickém sběru, stupeň prověrky/důvěryhodnosti atd. Aplikace, která tato data řídí, sbírá a spravuje šifrování dat a přístup.

Datové toky z jednoho zdroje často obsahují data různých stupňů bezpečnosti (od C1 do C4, tj. veřejná, interní, důvěrná a tajná data). Proto je nezbytné vytvořit tematickou souvislost pro každou z klasifikovaných úrovní a rozdělovat klíče mezi účastníky v závislosti na jejich pracovní roli. Odpovídající data totiž mohou vidět pouze ti účastníci, kteří jsou tomu oprávněni. Prvním krokem nebo minimálním viditelným produktem je, že informace v metadatech mohou být párovány pro přístup z aplikace založené na roli, což řídí žádost na úrovni tématu. Toto může být na vyšší úrovni rozšířeno o zahrnutí informace ze správy identit a přístupů pro přístup přes mikroslužby.

Obr. 2: Správa klíčů a přístupů založená na metadatech, šifrování dat různých úrovní zabezpečení; toto může být dosaženo dokonale přístupně. Obr. HPE.
Obr. 2: Správa klíčů a přístupů založená na metadatech, šifrování dat různých úrovní zabezpečení; toto může být dosaženo dokonale přístupně. Obr. HPE.

Princip návrhu 3: Každé rozhraní je částí CMDB a je monitorováno

Datový hub vyžaduje maximum dostupnosti. Platformy jako Kafka Connect a Ezmeral Data Fabric jsou pro takto přísné požadavky stavěny, avšak nemusí tomu tak být u všech konektorů. Například NiFi by mohlo běžet v rozporu s požadavky na vysokou dostupnost na jednom uzlu – a dokonce se u platformy Kafka Connect stává, že rozhraní nepracuje jak je požadováno. Je mnohem důležitější, aby CI představovalo v CMDB každé jednotlivé rozhraní. Také je důležité každé rozhraní sledovat a přiřadit mu určité KPI. Oddělení IT to zpočátku dělá manuálně; na vyšší úrovni vývoje mohou být prahové úrovně generovány s využitím strojového učení (ML – Machine Learning).

Princip návrhu 4: Všechna rozhraní jsou řízena

Prostředí se bude pravděpodobně rychle a neustále měnit. Architektura musí s těmito změnami držet krok. Změny rozhraní pro tvorbu a konzumování se musejí dít jednoduše a řízeným způsobem. Aby tomu tak bylo, IT oddělení musí být schopno všechna rozhraní řídit a operační tým musí být schopen provádět jednoduché interakce každý den na jediné kliknutí. Základní funkce, jako například „stop“ nebo „restart“ by tudíž měly být začleněny od samého začátku a měly by být dostupné pro service desk a pro podporu druhé úrovně.

Princip návrhu 5: Zachování podnikového datového modelu s katalogem dat a správa metadat

Zatímco zdroj dat od tvůrců zůstává co možná nejvíce blízký zdrojovému formátu když je přiveden do hubu, data by měla být konzumována ve standardizovaném formátu EDM (Enterprise Data Model). Proto IT oddělení definuje, publikuje a spravuje centrální EDM. Každá jednotka EDM je v datovém hubu nasazena ve vyhrazeném tématu. Pro každé téma musejí být definována pravidla, aby bylo zřejmé, kdo a jak k němu může přistupovat. Správa řízení přístupu a instrukce se dostávají přes správu metadat. To úzce souvisí se správou podnikové architektury, rolemi správy dat a vývojem datového hubu, podporováno funkcemi celkové správy. Na tomto základě IT organizace vytvářejí katalog dat pro předplácení dat. Pro správu dat musejí být dány jasné zodpovědnosti, včetně souvisejících roli – vlastníci dat určují, jak jsou data držena a využívána; datoví stevardi spravují data podle specifikací vlastníků dat a jsou zodpovědní za kvalitu dat a určují, která data budou vymazána.

Princip návrhu 6: Zaměření na uživatele – prvky v katalogu dat jsou dostupné přes API založená na mikroslužbách a mikro-UI

Tým IT poskytuje katalog dat pro aplikace, uživatele, a pokud je to nezbytné, také pro partnery. Aplikacím jsou data dostupná „as a service“ přes API, uživatelům a partnerům přes uživatelská rozhraní (micro-UIs) založená na specifických rolích. API založená na mikroslužbách a kontejnerové technologii totiž umožňují rychlý vývoj uživatelsky zaměřených aplikací, které poskytují uživatelům přesně ty informace, jaké potřebují. To činí pracovníkům snazší život. S vyšším stupněm vývoje jsou aplikace ušity na míru nejen pro specifické uživatelské role, ale také pro regiony a kultury.

Obr. 3: API založená na mikroslužbách a kontejenrové technologii umožňují rychlý vývoj uživatelsky zaměřených aplikací. Obr. HPE.
Obr. 3: API založená na mikroslužbách a kontejenrové technologii umožňují rychlý vývoj uživatelsky zaměřených aplikací. Obr. HPE.

Princip návrhu 7: Dokumentace odpovídá, je konkrétní, srozumitelná a snadno přístupná

Agilita a správa potřebují být transparentní. Proto je radno dokumentovat příslušné informace ve wiki, ke které mohou přistupovat všichni zaměstnanci, jichž se to týká. Obsah zahrnuje principy architektury, nejlepší praktiky, výjimky z pravidel a jejich zdůvodnění, protokoly od řídícího orgánu architektury, datové modely, a zejména EDM, na němž je katalog dat založen. Jestliže jsou komponenty zdrojového kódu součástí architektury, musí tam být odkaz do úložiště kódu. Komponenty architektury odpovídají nejlepším praktikám ve jejím wiki. Provozní koncepty, testovací koncepty, pravidla programování a správa testovacích dat musejí také být dokumentovány a přístupné. To pomáhá spolupráci, podporuje plynule zavádět vylepšení prostředí, propaguje agilitu a optimalizuje poskytování služeb a činností.

Princip návrhu 8: Zajistěte vývoj založený na testování a průběžné dodávky

Spolehlivý tok CI/CD s automatizovaným testováním zrychluje další vývoj datové architektury, zvyšuje kvalitu služeb a vytváří základ pro agilní vývoj a DevOps. Se zvýšeným počtem testování souvisí sběr testovacích dat. Stejně jako to platí pro samotný kód, musejí být uchována ve verzích, čímž se výkon a regresní testy zlepšují a dostávají se na vyšší úroveň.

Princip návrhu 9: „Digitální dvojče“ sdílených datových prostředků (poolu) tvoří základ pro všechny datové uživatelské případy

Představení datově-centrické architektury bezpochyby směřuje k cíli „digitálního dvojčete“ veškerých datových prostředků společnosti nebo ekosystému. Katalogizace dat a správa metadat veškerých dat zajišťuje transparentnost a vytváří základ pro neustálé zvyšování kvality dat. Správa centrálních dat také jako přídavek ke zdrojům dat rozkrývá hodnotu každého zdroje dat a překryvy dodávek dat. To znamená, že vhodná data mohou být nalezena a analyzována pro všechny aplikace. Katalog služeb podporuje na tomto základě tvorbu hodnoty dat tím, že vytváří data a analyzuje přístup k různým cílovým skupinám přes vhodné aplikace.

Obr. 4: Datově-centrická architektura poskytuje základ pro monetizaci dat. Katalog služeb vytváří data a analyzuje dostupnost pro různé cílové skupiny přes vhodné aplikace. Obr. HPE.
Obr. 4: Datově-centrická architektura poskytuje základ pro monetizaci dat. Katalog služeb vytváří data a analyzuje dostupnost pro různé cílové skupiny přes vhodné aplikace. Obr. HPE.

Cesta k monetizaci dat v praxi

Následující příklad ilustruje na fiktivní globální letecké logistické společnosti proceduru pro zavedení datově centrické architektury. Společnost postupně přebrala několik dalších firem. Výsledkem je heterogenní, smíšené IT prostředí, uzpůsobené potřebám jednotlivých funkcí a/nebo jednotlivým akvírovaným firmám. Aplikace komunikují přes propojení z jednoho bodu do druhého (point-to-point); neexistuje zde jednotná datová architektura. Nebyla navíc provedena důkladná analýza dat – respektive tyto projekty skončily po prvních pokusech, protože náklady na propojení k velkému množství datových zdrojů byly příliš nákladné a neexistoval jasný pohled na správné zdroje. IT specialistům z větších firem by proto měl být tento fiktivní případ povědomý.

Došlo však k obratu – společnost definuje datově-centrickou architekturu jako vizi a má podporu nejvyššího vedení. Počátečním obchodním případem je zavést datový hub včetně streamování událostí a správy metadat. Proces – každá změna výměny csv vede k nasazení propojení Kafka. Po pouhých několika měsících se ukázalo, že předchozí vysoké náklady na rozhraní se snížily. V tu samou dobu organizace dostala na svoje data lepší náhled s každým novým konektorem. Postupně se stalo zřejmým, že mnoho vnějších rozhraní bylo nadbytečných. Výsledkem bylo, že firma začala nepotřebné kontrakty ukončovat. V tu samou dobu také koncoví uživatelé shledali, že přístup k datům je nyní snazší a že data jsou spolehlivější.

Tým IT také vytvořil za účelem testování datovou kostku s daty z více zdrojů, aby ilustroval, jak mohou být použity analýzy přes datový hub pro zajištění prodeje na základě aktuálních informací. Obchodní oddělení se rozhodlo podpořit další rozvoj architektury. Poté, co byla do datového hubu připojena většina aplikací, následovala prověrka uskutečnitelnosti (PoC, proof-of-concept), která ukázala, jak uživatelsky centrická aplikace může zaměstnancům letišti pomoci. Pozemní personál obdržel přes aplikaci aktuální informaci o stavu letu, kterou bylo zapotřebí vyhledat – například zda je let zpožděn, nebo letadlo právě přistálo, nebo jestli došlo ke změně nákladní brány. Personál dostává instrukce od supervizora přes chat a může si vyměňovat informace s ostatními členy týmu. Jedním slovem – výhody nové aplikace se dostavily průřezem celou společností. Výsledkem je, že na IT oddělení se teď valí řada dalších požadavků na obdobné aplikace.

Pro stále více uživatelských případů jde o společnou řeč. Kvalita dat se stále zlepšuje, stále více zaměstnanců dostává data, která potřebují v reálném čase, a také pro vedení firmy je snazší sladit provozní a finanční data. V dalším kroku firma plánuje sdílet data se zákazníky a partnery. Koncoví zákazníci dostanou stavové informace zdarma, dopravci získají individuální přístup k datům v reálném čase – avšak za poplatek. Přímé zpoplatnění informací je nyní na dosah.

Závěr

Na uvedeném příkladu je zřejmé, že jakmile byly datové fondy sjednoceny se standardizovanou správou dat a s řízením přes datový hub, bylo relativně snadné rychle podpořit řadu uživatelských případů – cesta až sem však samozřejmě tak snadná nebyla. Bude také obtížné jít po této cestě dále, už když jen vezmeme zvyšující se složitost aplikačního prostředí a rychle rostoucí objemy dat. Proto bude zapotřebí strategické iniciativy IT, podpory vedení a pevného řízení, aby bylo možno tyto překážky překonat – nasadit agilní metody pro správu architektury a vývoj. Protože pak jsou způsoby a cíl v harmonii – v obou případech jde o překonání pyramid a úložišť s cílem zabývat se méně sám se sebou a více zákazníky.

Stefan Brock Stefan Brock
Autor článku je poradcem ve společnosti Hewlett Packard Enterprise.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.