Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Promítnutí architektury IT služeb do dílčích IT architektur
Promítnutí architektury IT služeb do dílčích IT architektur
Kód úlohy

Standardní kód úlohy v MBI.

:
U034A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Voříšek, J. (KIT, VŠE)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.6
Charakteristiky úlohy

Charakteristiky úlohy

1. “Promítnutí architektury IT služeb do dílčích IT architektur“ – cíl, účel
  • Cílem úlohy je zajistit správné vazby mezi podnikovou (byznys) architekturou, architekturou IT služeb a IT architekturami.
  • Navrhnout optimální skladbu aplikačního software (ASW) , datových zdrojů, základního software (ZSW) a hardware pro dodávku plánovaných IT služeb.
2. Obsah úlohy
  • V návaznosti na plánovanou architekturu IT služeb se navrhují, resp. inovují dílčí IT architektury.
  • Dílčí IT architektury se zpracovávají pouze pro ty IT služby, které bude IT útvar podniku poskytovat interně . Pro externě dodávané IT služby se tyto architektury v podniku nezpracovávají, protože jsou v kompetenci externího poskytovatele IT služby.
  • Tyto návrhy nemusí být vždy součástí informační strategie , mohou být součástí projektů, resp. aktivit taktického řízení, které ze strategie vyplývají.
  • Mezi dílčí IT architektury patří:
    • aplikační architektura,
    • softwarová architektura,
    • datová (informační) architektura,
    • technologická architektura.
2.1. Aplikační architektura
  • Aplikační architektura vychází z plánované architektury IT služeb a určuje, jakými aplikacemi (jakým aplikačním softwarem) bude pokryta funkcionalita IT služeb .
  • Mezi IT službami a aplikacemi je obecně vztah M : N , tzn. že funkcionalita IT služby může být zajišťována jednou nebo více aplikacemi a jedna aplikace může svojí funkcionalitou podporovat jednu nebo více IT služeb.
  • Systémem, nad kterým je aplikační architektura definována je ta část informačního systému podniku, která je provozována interně (tzn., že nezahrnuje aplikace, jejichž funkcionalitu podnik nakupuje jako IT službu od externích poskytovatelů).
  • Komponentami architektury jsou jednotlivé aplikace . Komponenta může být buď t ypovým aplikačním softwarem (TASW) nebo individuálním softwarem (IASW) .
  • Hlavním cílem aplikační architektury je pokrýt veškerou funkcionalitu, která je požadovaná interně provozovanými IT službami, s minimem duplicitní funkcionality a s minimem nepotřebné funkcionality (ta obvykle vzniká při využívání TASW).
2.2. Softwarová architektura
  • Softwarovou architekturou se v podniku zabýváme v plném rozsahu pouze u aplikací typu IASW , tj. u těch aplikací, které byly pro podnik vyvinuty na klíč.
  • V případě, že se jedná o aplikaci typy TASW , je její architektura pro podnikové informatiky většinou v plném rozsahu nedostupná, protože ji výrobce TASW zákazníkům obvykle nesděluje.
  • Pro integraci TASW do celého IS jsou pro podnikové informatiky podstatné aplikační programový interface (API ) a provozní prostředí celé TASW.
  • Pro výrobce TASW je ale softwarová architektura TASW velmi podstatná, protože její kvalita značně ovlivňuje flexibilitu aplikace a ovlivňuje také náklady na tvorbu a údržbu aplikace.
2.3. Datová architektura
  • V případě datové/informační architektury je systémem, na kterém architekturu definujeme, datová základna informačního systému podniku.
  • Hlavními komponentami , jejichž strukturu a vztahy architektura definuje, jsou datové objekty .
  • Architektura dále určuje způsob centralizace, resp. decentralizace a replikace jednotlivých datových komponent.
  • Datová architektura vychází z analýzy potřebných typů datových objektů a jejich vazeb. Na základě této analýzy se provádí konceptuální a následně logický návrh datové základny , tj. navrhují se datové entity, jejich vazby a atributy. Datová architektura je finalizována fyzickým návrhem datové základny , tj. návrhem databázových souborů a jejich fyzického uložení.
2.4. Technologiká architektura
  • V případě architektury technologické infrastruktury je systémem, na kterém architekturu definujeme, provozní platforma interně provozovaných aplikac í informačního systému podniku.
  • Hlavními komponentami , jejichž strukturu a vztahy architektura definuje, jsou hardwarové komponenty (servery, koncové stanice, počítačové sítě atd.) a komponenty základního programového vybavení (operační systémy, databázové systémy, komunikační systémy, integrační software atd.).
  • Snahou architektů technologické infrastruktury je, aby technologická infrastruktura mohla být pro všechny interně provozované aplikace jednotná . Jednotná technologická infrastruktura výrazně snižuje provozní náklady informačního systému.
  • Dimenzování technologické infrastruktury , tj. počet a výkonnost serverů, kapacita diskových polí, počet a výkon koncových stanic, kapacity přenosových cest stejně jako vhodný výběr SW platformy jako jsou operační systémy, virtualizační SW, middleware, databáze atd., se odvozuje od požadovaného objemu (počet uživatelů, objem dat,…) a kvality (dostupnost, spolehlivost,…) interně provozovaných IT služeb.
  • Mají-li být zajištěny dohodnuté parametry IT služeb , zejména dostupnost a doba odezvy, musí být technologická infrastruktura dimenzována na období s nejvyšším zatížením. Z toho ale vyplývá, že v době poklesu uživatelských požadavků nejsou zdroje technologické infrastruktury optimálně využívány . To je jedna z podstatných nevýhod, když podnik provozuje svoje aplikace na vlastní technologické infrastruktuře. I proto celosvětově sílí trend k využívání služeb cloud computingu (PaaS a IaaS).
3. Vstupy úlohy:
  • Katalog cílů informatiky (D041A ),
  • Informační strategie (D001A ), kapitoly 3, 4, 5,
  • Organizační a řídící dokumenty podniku (DQ002A ),
  • Katalog podnikových cílů (DQ004A ),
  • Katalog požadavků na IT (D042A ),
  • Katalog IT služeb (D111A ),
  • Procesní dokumentace podniku (DQ003A ),
  • KPI / KGI podniku a ve vztahu k cílům, procesům (DQ008A),
  • SWOT analýza podniku (D012A ),
  • SWOT analýza řízení informatiky podniku (D013A ).
4. Výstupy úlohy:
  • Informační strategie (D001A ), kapitola 7.2, kapitola 7.3, kapitola 7.4,
  • Aplikační architektura (D053A ),
  • Technologická architektura (D054A ),
  • Datová architektura (D055A ),
  • Softwarová architektura (D056A ).
5. Podmínky úspěšnosti úlohy
  • IT architektury, zejména aplikační architektura musí být řešeny při průběžné kooperaci s byznys manažery a klíčovými uživateli,
  • U každé architektury se řeší rovnováha mezi komplexností a přijatelnou jednoduchostí,
  • Architektura neodráží aktuální stav, ale respektuje i očekávaný vývoj v byznys i IT prostředí, např. předpokládaný vývoj aplikací, technologií atd.,
  • Architektura má sloužit jako efektivní nástroj dosažení konsenzu mezi vedením podniku a vedením a specialisty IT.
6. Doporučené praktiky
  • Před zahájením řešení všech zmíněných architektur je účelné jasně definovat, kde a jak budou architektury v manažerské práci a v jednotlivých rozhodovacích aktivitách využity , např. při formulování projektových záměrů, schvalování projektů apod.,
  • Je třeba vyčlenit specializovaný tým architektů , který bude disponovat heterogenními znalostmi z oblasti řízení, byznysu i IT.
7. “Promítnutí architektury IT služeb do dílčích IT architektur“ - klíčové aktivity

7.1. Návrh aplikační architektury - hodnotící kritéria
  • Stupeň pokrytí požadované funkcionality IT služeb aplikacemi . Jestliže se stane, že některá z funkcí aplikačních služeb není zajištěna žádnou aplikací, jedná se o fatální chybu (nepokrytá funkcionalita). Jestliže je daná funkcionalita zajišťována dvěma nebo více aplikacemi (duplicitní funkcionalita), nejedná se o fatální chybu, ale je to neekonomické, komplikuje to uživatelské rozhraní (uživatel může být zmaten, kterou z funkcionalit použít a bude si myslet, že se jedná o úmysl, protože každá z duplicitních funkcí by se měla využít v určité specifické situaci) a komplikuje to integraci aplikací. Jestliže některá aplikace obsahuje funkcionalitu, která není požadována žádnou IT službou, také se nejedná o fatální chybu, ale je to neekonomické, protože jsme nakoupili nebo vyvinuli funkcionalitu, kterou nikdo nepotřebuje. Nadbytečná funkcionalita je poměrně častým jevem, jestliže mezi aplikacemi IS je TASW. Je to dáno tím, že TASW je vyvíjeno pro velké množství zákazníků, jejichž požadavky na funkcionalitu se liší. Z uvedeného plyne, že cílem architekta by mělo být 100% pokrytí požadované funkcionality s minimem duplicitních a nadbytečných funkcí,
  • Počet aplikací. Je-li IS podniku řešen velkým počtem aplikací (stovky aplikací), komplikuje a prodražuje to správu, údržbu a integraci aplikací. Proto cílem architekta je složit požadovanou funkcionalitu z malého počtu aplikací,
  • Integrace aplikací . Toto kritérium je velmi důležité jak z hlediska byznysu, tak z hlediska IT. Lze ho rozdělit do třech dílčích požadavků :
    • datová integrace , tzn. požadavek, aby jeden datový objekt (například „informace o zákazníkovi“ byl v celé datové základně uložen pouze jednou, a to i v případě, že s ním pracuje více aplikací. Jestliže by se např. stalo, že informace o zákazníkovi by byly uloženy vícekrát, je vysoce pravděpodobné, že hodnoty různých výskytů budou lišit. Pak ale není jasné, který z údajů (např. adresa zákazníka) odpovídá realitě. Zajistit unikátnost uložených dat je někdy obtížné, a to zejména v případě TASW. Stane-li se, že dvě aplikace mají v datové základně tentýž objekt, musí architekt zajistit synchronizaci těchto duplicitně uložených údajů,
    • aplikace musejí nabízet svoji funkcionalitu i přes tzv. API (Application Program Interface) tak, aby již existující funkcionalitu mohly využívat i jiné aplikace,
    • integrace uživatelského rozhraní , tzn., aby principy komunikace v různých aplikacích byly stejné. Tím se zajistí, že uživatel se nemusí učit různé způsoby komunikace a ani nepoznám, že jednotlivé funkce jsou zajišťovány různými aplikacemi,
  • Jednotná technologická platforma pro všechny aplikace je požadavkem, jehož cílem je snížení nákladů jak na technologické zdroje, tak na správce těchto zdrojů (operační systémy, databázové systémy, servery apod.),
  • Náklady pořízení a provozu jsou kritériem, které zohledňuje požadavky byznysy na nízkou cenu IT služeb. Pro architekta to znamená vybírat takové aplikace, které vyhovují výše uvedeným kritériím a současně mají přijatelné náklady na pořízení a provoz.
7.2. Návrh softwarové architektury
  • Cílem softwarové architektury je navrhnout strukturu a vazby programových modulů aplikace. * /Softwarová architektura určuje :
    • zda aplikace bude provozována jako jedno nebo víceuživatelská – viz dále,
    • z kolika programových modulů se bude aplikace skládat,
    • jak budou moduly aplikace specializovány a uspořádány – viz dále jedno, dvou a třívrstvá architektura, lineární, hierarchická, vrstvená a síťová architektura,
    • jakou funkcionalitu bude každý z modulů zajišťovat,
    • pro každou funkci její vstupní a výstupní data,
    • algoritmus, který předepisuje způsob transformace vstupních dat na výstupní a způsob ošetření mimořádných stavů,
    • interní data modulu,
    • vazby na ostatní moduly aplikace a interface modulu (aplikační programový interface) na jiné aplikace,
    • vývojové prostředí modulu (programovací jazyk, CASE atd.),
    • provozní prostředí modulu (operační systém, databázový systém, middleware atd.).
  • Vývojové a provozní prostředí bývá stejné pro všechny moduly dané aplikace, ale není to kategorickou podmínkou.
  • To, zda je softwarová architektura dobře navržena, lze hodnotit podle následujících kritérií :
    • neduplicitní funkcionalita a znovupoužitelnost modulů aplikace. Jde o to, aby funkcionalita, která je potřebná ve více modulech (například kontrola správnosti rodného čísla v aplikaci zpracovávající evidenci a mzdy zaměstnanců) nebyla v systému řešena na několika místech, ale pouze jednou. Tím se jednak zajistí, že daná funkce funguje vždy stejně a jednak se snižují náklady vývoje a údržby,
    • správné dimenzování aplikace, tj. zda aplikace zvládne s požadovanou dobou odezvy zpracovávat požadavky plánovaného počtu uživatelů i při maximálně očekávatelném objemu dat. Na dobu odezvy má totiž vliv nejen výkon technologické infrastruktury, na které je aplikace provozována, ale také mnoho dalších faktorů ovlivněných samotnou aplikací (efektivnost algoritmu, vhodnost fyzického uložení dat atd.),
    • snadnost údržby a dalšího rozvoje aplikace. Například, zda na místech očekávatelných změn jsou změny realizovatelné pomocí změn hodnot parametrů,
    • shoda vývojového a provozního prostředí dané aplikace, jejíž softwarovou architekturu posuzujeme, s vývojovým a provozním prostředím ostatních aplikací IS,
    • náklady tvorby a provozu aplikace.
7.3. Návrh datové/informační architektury
  • Cílem návrhu datové architektury je navrhnout interně spravovanou datovou základnu podniku tak, aby dodávala podnikovým procesům všechny požadované informace a aby kvalita a integrita dat byly na požadované úrovni.
  • To, zda je datová architektura dobře navržena, lze hodnotit podle následujících kritérií :
    • počet duplicitního uložení týchž dat,
    • rychlost získání potřebných dat,
    • zabezpečení dat proti ztrátě, zničení a odcizení.
7.4. Návrh technologické architektury
  • Cílem návrhu technologické architektury je navrhnout technologickou platformu pro interně provozované aplikace tak, aby byla dostatečně výkonná a aby náklady na její pořízení, údržbu a provoz byly přijatelné.
  • To, zda je technologická architektura dobře navržena, lze hodnotit podle následujících kritérií :
    • míra jednotnosti pro všechny interně provozované aplikace,
    • dimenzování technologické infrastruktury s ohledem na nároky provozovaných aplikací,
    • škálovatelnost výkonu technologické infrastruktury,
    • počet a doba výpadků,
    • náklady technologické infrastruktury.
8. Poznámky, reference
  • Tato varianta úlohy je zaměřena na návrh služby pro interní použití v organizaci, nikoli návrh služby jako produktu firmy, který je prodáván zákazníkům.