Project scope - t he processes will have to cover the whole IT architecture Development Cycle

1. Project scope - the processes will have to cover the whole IT architecture Development Cycle A Initiation And Framework G Architecture Maintenance B Baseline Description C Target Architecture 2. Consider Views 3. Create Arch model Requirements 1. Create Baseline F Implementation 8. Conduct Gap Analysis 4. Select Services E Migration Planning D Opportunities And Solutions 5. Confirm Business Objectives 7. Define Architecture 6. Determine Criteria

2. ITA Processes project level (event-driven) enterprise level (process-driven) A. ITA services (poskytování informací a spoluúčast při rozhodování za účelem dodržení směrnic, pravidel) B. ITA updating (zajištění správnosti a aktuálnosti dat ITA = konzistence modelu ITA s realitou) C. ITA správa (zajištění chodu útvaru ITA) A-1. sw projects evaluation B-1. sw projects mapping C-1. harmonizace celého konceptu ITA přijímání a zapracovávání směrnic TMO B-1-1. assistance in business modeling spoluúčast při tvorbě a především včasné zaznamenávání údajů do ITA modelu o nově vzniklých artefaktech A-1-1. justify projects spolurozhodující podíl na feasibility projektu, posouzení PD, stanovení priorit a výběru varianty řešení C-2. vytváření a aktualiza- ce vlastních pravidel ITA tvorba vlastních pravidel vyplývajících z praktických potřeb chodu TM CZ B-1-2. assistance in conceptual modeling spoluúčast při tvorbě a především včasné zaznamenávání údajů do ITA modelu o nově vzniklých artefaktech A-1-2. consult mgmt. documents spoluúčast a poskytování informací pro ProjectCharter (plánování projektů) - nedělá se pro Ex. proj. C-3. realizace pravidel ITA realizace pravidel získaných z C1 nebo C2 (informování na kompetentní místa, = zajištění, aby pravidlo mohlo být uplatňováno v reálném provozu) B-1-3. assistance in prgm., gener.& tests spoluúčast při tvorbě a především včasné zaznamenávání údajů do ITA modelu o nově vzniklých artefaktech C-4. spoluúčast na tvorbě konceptu TMO „feedback“ z TM CZ směrem k TMO A-2. připomínkování spoluúčast při rozhodování o projektech, které nejsou SW delevelopment, ale např. rozvoje HW, tech. infrastruktury,... B-2. registrace nových systémů včasné zaznamenávání údajů do modelu ITA o nových systémech - týká se také rozvoje HW, tech. inftrastruktury,... C-5. informační služby konzultace, poradenství („ITA help-desk“)

3. IT Architectaktivity a komunikace všech „typů architektů“v SW Devel. projektech

4. ITA • co je a co není ITA: • Po tech. stránce se jedná o sadu modelových informací o systémech a komponentách v různých vrstvách. Analogie s vrstvami v GIS modelu města. Je to vícedimenzionální „model“ podniku, který má poskytovat užitečné znalosti k rozhodování. • ITA musí dobře popsat vztahy vyšších úrovní hierarchie systémů a vazby mezi prvky v různých vrstvách (napříč vrstvami). • Součástí dat ITA není např. knihovna reuse sw komponent z repozitáře. ITA se nezabývá takovými podrobnostmi, nejde pod úroveň aplikačních modulů a jejich funkčních rozhraní. ITA není model „všeho“. • co dělá a co nedělá IT architekt: • Zajišťuje aktuálnost a přesnost mezi modelem a realitou. IT Architekt mapuje/harmonizuje ITA aby byla užitečným obrazem reality. • Snaží se, aby údaje po něm požadované (viz. procesy A-1, A-2) byly aktuální a k dispozici již v okamžiku jejich potřeby a ne aby se musely teprve na místě hledat. (Proto jsou důležité procesy B-1, B-2). • Poskytuje „informační služby“ pro potřeby lepšího plánování, řízení, rozhodování, ... • Sám neprovádí žádné analýzy např. pro potřeby plánování a řízení a sám také nerozhoduje. Od toho jsou jiné role, útvary. • kdo je IT architekt • Na plný úvazek jedna ze tří osob, se kterými vedení IT RDM počítá. (pracovní název „Velký IT Architekt“). • Týká se hlavně procesů C-1, …, C-4. • V procesech A, …, B navrhujeme, aby velký architekt procesy zahajoval a podle druhu a složitosti projektu buď roli odpracoval sám nebo měl možnost přibírat specialisty a nebo i svoji roli delegovat. • V procesech A, …, B také delegovaný specialista, pro kterého bude ITA jen částí jeho pracovní náplně: • Správci domén, administrátoři atd. kteří byli požádáni o součinnost velkým architektem v případě potřeby. • Delegovaní správci domén nebo analytici, kteří byli jmenováni velkým architektem, aby jeho roli zastoupili. • K širšímu okruhu ITA ještě náleží specialisté a další kompetentní osoby, které potřebujeme pro naplnění procesů C-1 až C-4 (šíření informací na kompetentní místa, zjišťování informací, konzultace, ...). • tento přístup versus TOGAF • TOGAF bereme jako sadu nástrojů a technik, ze kterých si vybíráme co potřebujeme s ohledem na maximální jednoduchost a znovupoužitelnost již navržených procesů pro sw developmentu plus analogie s naší prací pro DWH. • TOGAF je mechanismus, který zajišťuje mimo jiné generování requestů na development na základě práce s ITA. V RDM je ale situace opačná. Requesty na development není třeba hledat, ale naopak je třeba je harmonizovat s požadavky ITA. • nedořešené otázkypři návrhu • Kolik budeme mít vrstev? Stačí 3 dle schématu TMO? • Kdo bude zajišťovat po technické stránce chod „báze znalostí ITA“? Použijeme k tomu připravovaný repozitář a navrhovaný útvar IT Project Office? • Struktura útvarů IT RDM je v souladu s vrstvou „business logic“(?). Lze tedy očekávat, že mapování této vrstvy nebude problém. Ale co další vrstvy? (datová a techická) Najdeme „specialisty“, kteří budou našim architektům k dispozici, aby nebylo mapování a vůbec nakládání s dalšími vrstvami podceňováno? Zabrání tomu mechanismus checklistů nebo je třeba přitvrdit?

5. Releasing Process RELEASING Requirement Management Configuration Management Deployment Management REQ. Mapping allocatedREQ. Configuration Documenting started deployment WP Stucturing, Modeling and Validation require-ments new release Services Mapping Configuration Planning Control of WP Realization Measurement REQ. Approval & Evaluation reporting, feedback reporting, feedback Systems Mapping Launch & Control of Deployment WP Deliver & Release Testing RE-RELEASING Release Problems WP Realization Problems REPORTING SUPERVISION

6. Srovnání s projektově orientovaným přístupem users level new requests new functionality system services level requirements for system services changed services zde je rovina softwarového projektu software app level requirements for sw applications SW system build WP level WP analysis WP implementation, testing U projektově orientovaného přístupu se od začátku do konce držíme v jedné rovině daného ICT projektu. U „Configuration Driven Development“ přístupu začínáme na vyšší rovině, postupně ale přejdeme na úroveň WP, která je typicky pro jeden WP team podrobnější než klasicky chápaný softwarový projekt a vrátíme se zpět.