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á).

Faktor : Aplikační architektura
Aplikační architektura
Kód faktoru

Standardní kód faktoru v MBI.

:
F152
Autor

Jméno a příjmení autora

:
Podstatné charakteristik faktoru

Obsahové vymezení faktoru

1. Aplikační architektura - obsahové vymezení
  • Aplikační architektura slouží k řízení rozvoje a provozu aplikací a zejména je prostředkem dosažení potřebné stability informačního systému.
  • Dokument obsahuje seznam všech aplikací daného informačního systému a jejich vzájemných vazeb .
  • U aplikací může dále specifikovat řadu atributů potřebných k řízení (základní funkcionalita, dodavatel atd.). Návrh obsahu dokumentu je uveden v připojeném souboru, včetně masky základní tabulky.
2. IASW versus TASW/OSS
  • Při zařazování nové aplikace do aplikační architektury musí IT architekt rozhodnout, jakým způsobem bude nová aplikace vyvinuta, resp. získána. Přicházejí v úvahu dvě základní alternativy – individuální aplikační software (IASW) nebo typový aplikační software (TASW). Specifickým případem TASW pak je open-source software (OSS).
  • Při použití IASW je aplikace vytvořena na míru dle potřeb podniku, instalována na definované technologické platformě a poté pro uživatele daného podniku provozována :
    • Funkcionalita aplikace je navržena tak, aby optimálně podporovala činnosti podnikového procesu, pro který je určena. ** /Výhodou této alternativy je, že podnik může aplikací podpořit svoje specifické procesy a dosažení specifických cílů na trhu. Může tak snadněji než při TASW získat výhodu nad konkurencí, protože je jediným uživatelem daného software.
    • Nevýhodou naopak je, že vývoj aplikace tímto způsobem je pro podnik obvykle dražší a trvá déle než při využití TASW.
    • Z charakteristiky výhod a nevýhod jasně vyplývá, že IASW není výhodné volit pro aplikace, které podporují podpůrné vysoce standardizované procesy (např. e-mail nebo účetnictví).
3. Schéma vývoje, instalace a provozu IASW
  • Použití IASW je založeno na zcela odlišných principech , má tím i jiné výhody a nevýhody.
4. Schéma vývoje, instalace a provozu TASW
  • Aplikace je vytvořena a dále rozvíjena specializovaným výrobcem generalizací požadavků určité třídy podniků – např. bank, výrobců automobilů apod.
  • I když celkové náklady vývoje TASW jsou výrazně vyšší než v případě IASW, cena licence TASW je pro zákazníka obvykle nižší (Celková cena pro zákazníka je daná i náročností implementace včetně nákladů na přizpůsobení TASW, takže v případě, kdy je z TASW využita jen některá funkcionalita, nemusí být cena nižší, než vlastní vývoj), protože celkové náklady vývoje se rozpustí mezi více zákazníků.
  • Další výhodou je, že celková doba nasazení aplikace je kratší, protože se instaluje již hotový produkt.
  • Nevýhodou ale je, že podporovaný podnikový proces se musí přizpůsobit logice a možnostem TASW .
  • Na druhé straně přední výrobci TASW zabudovávají do funkcionality svých produktů nejlepší praktiky , které jsou v daném odvětví známy. Instalací TASW a přizpůsobením svých podnikových procesů tak může méně vyspělý podnik aplikovat zkušenosti a nejlepší praktiky lídrů na trhu.
  • Další nevýhodou TASW je, že podnik obvykle nevyužije veškerou funkcionalitu TASW, tzn., že de facto kupuje i to, co nepotřebuje.
  • Z charakteristiky vyplývá, že TASW je výhodné volit především pro vysoce standardizované aplikace jako je účetnictví, zpracování mezd, správa řízení dokumentů apod.
  • S rozvojem TASW vznikly činnosti, jejichž cílem je distribuce TASW od výrobce k zákazníkovi a úprava TASW dle potřeb podniku a jednotlivých uživatelů informačního systému.
5. Distribuce TASW
  • Kanál, kterým se TASW distribuuje od výrobce k zákazníkovi, je realizován sítí distributorů, dealerů, a systémových integrátorů.
  • Před tím, než je TASW nasazen u zákazníků z určitého teritoria, probíhá jeho lokalizace . Lokalizací se software a jeho funkcionalita upravuje dle platné legislativy, národního jazyka a kulturních zvyklostí v daném teritoriu.
6. Implementace TASW
  • Při implementaci lokalizovaného produktu v určitém podniku dochází k dalším úpravám – customizaci a integraci.
  • Customizace (je úprava produktu dle specifických potřeb daného zákazníka. Customizací se TASW přizpůsobuje podnikovým procesům a specifickým požadavkům uživatelů.
  • Upravují se např. datové struktury (např. účetní osnova), upravuje se vzhled obrazovek a výstupních sestav. Integrace softwarového produktu je proces, kterým se softwarový produkt propojuje s ostatními softwarovými komponentami informačního systému podniku (sdílení společných dat, využívání funkcionality jiných komponent apod.).
7. Personalizace
  • Dalším typem úpravy TASW je jeho personalizace. Personalizací mohou individuální uživatelé aplikace měnit chování a uživatelské rozhraní aplikace (volba komunikačního jazyka, volba způsobu zobrazení dat atd.).
  • Změny provedené personalizací aplikace se projeví jen v případě, když s aplikací komunikuje ten uživatel, pro kterého byla personalizace aplikace provedena.
8. Lokalizace, customizace a personalizace
  • Uskutečňují se především nastavováním hodnot parametrů TASW.
  • Vývoj TASW je tudíž obtížnější než vývoj IASW tím, že při návrhu aplikace analytici musejí dobře vytipovat, kde v aplikaci lokalizační, customizační a personalizační parametry nasadit. Rozsáhlé ERP systémy mají typicky tisíce lokalizačních, customizačních a personalizačních parametrů.
  • Všichni zákazníci výrobce TASW provozují tentýž software s tím, že jednotlivé instalace se mohou lišit :
    • nastavením lokalizačních, customizačních a personalizačních parametrů,
    • verzí provozovaného TASW, neboť když výrobce dodá na trh novou verzi TASW, nejsou zákazníci povinni tuto verzi u sebe instalovat,
    • existenci tzv. „softwarových záplat“, což jsou úpravy TASW nikoliv nastavením jiné hodnoty parametru, ale úpravou zdrojového kódu. Softwarové záplaty smí provádět pouze ten subjekt, který je k tomu dle softwarové licence oprávněn. Typicky to není zákazník, ale pouze systémový integrátor (a pochopitelně také vlastník TASW, tj. jeho výrobce).
9. Rozdíly v implementaci a užití TASW oproti IASW
  • Řeší-li podnik danou komponentu informačního systému nikoliv pomocí IASW, ale pomocí TASW, vykazuje řešení řadu odlišností:
    • jsou nižší nároky na detailnost specifikace požadavků, protože jednotlivé verze daného TASW vznikají generalizací požadavků širokého spektra zákazníků a tyto požadavky jsou prověřené,
    • je vyšší pravděpodobnost konfliktu interních a externích norem a standardů, protože TASW je vybudován na základě referenčního modelu byznys procesů - tento referenční model může být v rozporu s poníkovými normami a zvyklostmi,
    • existuje nebezpečí duplicitní funkcionality v aplikacích, protože funkcionalita různých TASW se může překrývat,
    • životní cyklus TASW aplikace je více standardizován, protože je na míru šit konkrétnímu TASW (formuláře pro customizaci, standardní kontrolní body při řešení projektu, standardizovaná školení atd.),
    • předpokládá značnou specializaci pracovníků dodavatele – dle jednotlivých modulů TASW, dle typů prací,
    • přináší vyšší nároky na komunikaci a řízení projektu,
    • dimenzování technologické infrastruktury je snadnější, protože se dá vycházet ze zkušeností ze stovek až tisíců podobných instalací téhož TASW,
    • TASW lze obvykle provozovat na několika různých platformách (různých operačních systémech, různých databázových systémech), zatímco IASW je obvykle vyvinuto jen pro jednu provozní platformu,
    • TASW má nižší nároky na testování (prověřená funkcionalita),
    • TASW je více flexibilní na změnu předvídatelných požadavků (parametrizace), ale méně flexibilní na specifické požadavky jednoho zákazníka (dodavateli TASW se nevyplatí realizovat požadavky, které vznáší pouze jeden zákazník),
    • TASW má standardní upgrade a je průběžně rozvíjen dodavatelem (úpravy dle změn legislativy, dle změn v použité provozní platformě, sofistikovanější funkcionalita).
10. Open-source software (OSS)
  • Specifickým případem TASW je open-source software (OSS). Jeho základní vlastnosti a odlišnosti od klasického TASW jsou následující:
    • aplikace je vytvořena virtuálním týmem vývojářů – dobrovolníků (softwarovou komunitou), kteří obvykle nemají nárok na odměnu,
    • aplikace je dodávaná v podobě zdrojových programů a zákazník si ji může přizpůsobit svým potřebám,
    • kód je zdarma a nesmí být prodán třetí straně (konkrétní podmínky se liší dle OSS licence), k OSS ale lze prodávat/nakupovat doprovodné služby,
    • neexistují garance kvality a opravy chyb ve stanovené lhůtě.
  • Z charakteristiky OSS vyplývá, že OSS je výhodný zejména pro standardizované aplikace , které nejsou kritické z hlediska kontinuity byznysu a konkurenceschopnosti.
  • Díky nízkým nákladům a faktu, že podnik není závislý na výrobci softwaru , tak jako v případě TASW, se tato varianta řešení stává stále oblíbenější.
  • Na www.SourceForge.net bylo v roce 2011 evidováno přes 304 000 OSS softwarů, z toho 3 600 softwarů pro ERP.
  • Je-li komponenta informačního systému podniku řešena pomocí OSS, pak řešení má oproti TASW tato specifika:
    • při využití OSS je postup projektu „mezivariantou“ mezi IASW a TASW - přizpůsobení OSS požadavkům podniku se realizuje méně pomocí parametrů a více úpravou kódu. Není ale třeba programovat celé řešení, ale pouze rozšíření a modifikace,
    • nakládání s OSS se řídí jinými licenčními pravidly,
    • odlišnosti v údržbě spočívají v jiné periodě upgradů – u OSS budou častější a menšího rozsahu, v případě TASW jsou méně časté a ve větších celcích.