Common use of Architektonické principy Clause in Contracts

Architektonické principy. Základní architektonické principy, které musí být uplatněny při návrhu ICT řešení. • Bezpečnost a soulad s vnitropodnikovou legislativou • Provozovatelnost řešení • Ochrana dat jako klíčového aktiva Správy železnic • Znovupoužitelnost řešení • Nezávislost na dodavatelích • Nezávislost na technologii • Řízení identit • Nákup a vývoj • Business kontinuita jako zásadní činnost Navrhované řešení a procesy jím podporované musí být v souladu s legislativními a regulatorními nároky a vnitropodnikovou legislativou Správy železnic. V případě potřeby dodržovat interní předpisy budou tyto součástí zadávací dokumentace případně předány jiným způsobem oproti podpisu NDA. Řešení musí umožnit monitorování akcí uživatelů, zejména jejich práce s daty a dokumenty. Musí být zajištěna administrovatelnost a auditovatelnost integračních vazeb. Vývoj a test není realizován na produkčním prostředí. Před nasazením do produkčního prostředí je řešení prokazatelně otestováno. Nejsou realizovány integrace mezi produkčními a neprodukčními prostředími. Dohled je zajištěn na všech vrstvách řešení (HW, OS, DB, AS, aplikace, koncový uživatel). Musí být zajištěno napojení na centrální dohledovou konzoli. Služby poskytované do prostředí internetu budou procházet penetračním testem. Řešení je navržené takovým způsobem, aby bylo provozovatelné na službách a technologiích Správy železnic. Řešení je navržené takovým způsobem, aby bylo možné jeho převzetí do provozního prostředí Správy železnic a zajištěn jeho provoz týmy a procesy Správy železnic. Řešení je navržené takovým způsobem, aby umožnilo škálování. Data jsou důležitým aktivem Správy železnic s významnou hodnotou. Uživatelé řešení mají přístup pouze k datům, která nutně potřebují pro výkon své pracovní činnosti podpořené daným informačním systémem. Řešení musí umožňovat diferencovaný přístup k datům se zohledněním uživatelských oprávnění, životního cyklu dat a jejich klasifikace. Data se pořizují a získávají právě jednou pro všechna řešení Správy železnic. Řešení musí umožňovat logické oddělení dat pro současné využívání funkcionality různými subjekty (tzv. multitenant). V rámci Správy železnic se realizuje minimalizace počtu a rozsahu používaných technologií a aplikací. Snižováním počtu a rozsahu používaných technologií a aplikací snižujeme komplexitu správy technologického a aplikačního portfolia. Řešení je navrhované s opakováním ověřených jednoduchých návrhových vzorů a designových principů. Nasazování změn a nových řešení je seskupováno dle funkcionalit a cílových systémů do jednotlivých „release“. Termíny releasů jsou stanoveny jednotkou O22. Nasazované řešení nesmí ke svému provozu vyžadovat pravidelný nutný zásah administrátora (např. restarty, čištění logů, ..) V rámci Správy železnic usilujeme o minimalizaci počtu prostředí pro stejnou funkcionalitu. Řešení navrhujeme s ohledem na omezení či eliminaci rizika vendor-lock. U řešení převzatých do provozu je cíl převzetí schopnosti vytvořit build aplikace bez závislosti na dodavateli. Usilujeme o právo zásahu do zdrojových kódů a rozvoje řešení interními kapacitami Správy železnic nebo dalšími dodavateli. Výjimku mohou tvořit jen případy, kdy by takové požadavky byly ekonomicky výrazně nevýhodné a současně by byl důvod se domnívat, že tato práva budou nadbytečná.

Architektonické principy. Základní architektonické principy, které musí být uplatněny při návrhu ICT řešení. • Bezpečnost a soulad s vnitropodnikovou legislativou • Provozovatelnost řešení • Ochrana dat jako klíčového aktiva Správy železnic • Znovupoužitelnost řešení • Nezávislost na dodavatelích • Nezávislost na technologii • Řízení identit • Nákup a vývoj • Business kontinuita jako zásadní činnost VII.1.1Bezpečnost a soulad s vnitropodnikovou legislativou Navrhované řešení a procesy jím podporované musí být v souladu s legislativními a regulatorními nároky a vnitropodnikovou legislativou Správy železnic. V případě potřeby dodržovat interní předpisy budou tyto součástí zadávací dokumentace případně předány jiným způsobem oproti podpisu NDA. Řešení musí umožnit monitorování akcí uživatelů, zejména jejich práce s daty a dokumenty. Musí být zajištěna administrovatelnost a auditovatelnost integračních vazeb. Vývoj a test není realizován na produkčním prostředí. Před nasazením do produkčního prostředí je řešení prokazatelně otestováno. Nejsou realizovány integrace mezi produkčními a neprodukčními prostředími. Dohled je zajištěn na všech vrstvách řešení (HW, OS, DB, AS, aplikace, koncový uživatel). Musí být zajištěno napojení na centrální dohledovou konzoli. Služby poskytované do prostředí internetu budou procházet penetračním testem. VII.1.2Provozovatelnost řešení Řešení je navržené takovým způsobem, aby bylo provozovatelné na službách a technologiích Správy železnic. Řešení je navržené takovým způsobem, aby bylo možné jeho převzetí do provozního prostředí Správy železnic a zajištěn jeho provoz týmy a procesy Správy železnic. Řešení je navržené takovým způsobem, aby umožnilo škálování. VII.1.3Ochrana dat jako klíčového aktiva Správy železnic Data jsou důležitým aktivem Správy železnic s významnou hodnotou. Uživatelé řešení mají přístup pouze k datům, která nutně potřebují pro výkon své pracovní činnosti podpořené daným informačním systémem. Řešení musí umožňovat diferencovaný přístup k datům se zohledněním uživatelských oprávnění, životního cyklu dat a jejich klasifikace. Data se pořizují a získávají právě jednou pro všechna řešení Správy železnic. VII.1.4Znovupoužitelnost řešení Řešení musí umožňovat logické oddělení dat pro současné využívání funkcionality různými subjekty (tzv. multitenant). V rámci Správy železnic se realizuje minimalizace počtu a rozsahu používaných technologií a aplikací. Snižováním počtu a rozsahu používaných technologií a aplikací snižujeme komplexitu správy technologického a aplikačního portfolia. Řešení je navrhované s opakováním ověřených jednoduchých návrhových vzorů a designových principů. Nasazování změn a nových řešení je seskupováno dle funkcionalit a cílových systémů do jednotlivých „release“. Termíny releasů jsou stanoveny jednotkou O22. Nasazované řešení nesmí ke svému provozu vyžadovat pravidelný nutný zásah administrátora (např. restarty, čištění logů, ..) V rámci Správy železnic usilujeme o minimalizaci počtu prostředí pro stejnou funkcionalitu. VII.1.5Nezávislost na dodavatelích Řešení navrhujeme s ohledem na omezení či eliminaci rizika vendor-lock. U řešení převzatých do provozu je cíl převzetí schopnosti vytvořit build aplikace bez závislosti na dodavateli. Usilujeme o právo zásahu do zdrojových kódů a rozvoje řešení interními kapacitami Správy železnic nebo dalšími dodavateli. Výjimku mohou tvořit jen případy, kdy by takové požadavky byly ekonomicky výrazně nevýhodné a současně by byl důvod se domnívat, že tato práva budou nadbytečná.