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.