Metodika přechodu na Open Source. Příručka pro management organizací a správce ICT

Transkript

1 Metodika přechodu na Open Source Příručka pro management organizací a správce ICT Poradenské centrum pro podporu implementace opensource software Praha 2008 v. 1.1

2 Informace obsažené v tomto materiálů zohledňují názory a zkušenosti tvůrců. Vzhledem k rychlému vývoji informačních technologií se nedá zaručit nadčasovost uvedených informací. V případě, že v textu jsou jmenovány produkty, firmy nebo značky to neznamená, že jsou doporučovány nebo protěžovány. Konkrétní nasazení vždy záleží na uživateli, jeho možnostech a dispozicích. Institut pro informační společnost nenese žádnou zodpovědnost za škody způsobené instalací, testováním nebo jiným užíváním uvedených produktů a návodů. Obchodní známky užité v tomto dokumentu jsou vlastnictvím příslušných organizací. Institut pro informační společnost není ve spojení s uvedenými organizacemi. Institut pro informační společnost, o.s., je neziskovou organizací, která v České republice působí od roku Mezi hlavní cíle Institutu pro informační společnost patří iniciování a podpora vzájemné spolupráce mezi oborovými subjekty, tvarování a zlepšování podmínek pro rozvoj informační společnosti, pomoc znevýhodněným skupinám a boj za ochranu duševního vlastnictví a proti počítačovému pirátství. IPIS upřednostňuje osvětovou a vzdělávací činnost před represí. Institut pro informační společnost, o.s. Poradenské centrum opensource Freyova Praha 9 Tato metodika vznikla pro účely projektu, který je spolufinancován prostředky Evropského sociálního fondu a státním rozpočtem ČR. 2

3 Obsah 1. Úvod Zkratky a použitá terminologie Typografické konvence Cílová skupina Cíl dokumentu 5 2. Stručný přehled 7 3. Metodika 9 4. Manažerská příručka Přehled migrace Lidské zdroje Užitečné postřehy Technická příručka Referenční architektura Generická architektura Základní referenční architektura Funkční skupiny Primární skupiny Podvojné skupiny Resumé referenčního modelu Pracovní stanice Servery Aplikace pro primární skupinu Kancelářské balíky Poštovní aplikace Kalendář a groupware Webové služby Správa dokumentů Databáze Aplikace podskupiny Operační systém Uživatelská rozhraní Bezpečnost Virtuální osobní sítě Řízení Backup a recovery Jiné služby 48 3

4 6. Migrace aplikací přehled Scénář č. 1 Windows Plánování migrace Oblasti působnosti Obecné požadavky Migrace prostředí operačního systému Migrace aplikací na straně serveru Image maps na straně serveru Migrace pracovní stanice na OSS Scénář č. 2 Unix Scénář č. 3 Mainframe Scénář č. 4 Tenký klient Přílohy Užitečné odkazy a literatura 92 4

5 1. Úvod 1.1. Zkratky a použitá terminologie Ve většině případů je zkratka uvedena v plném znění při prvním použití. Seznam všech použitých zkratek je pak uveden v příloze tohoto dokumentu. Termíny Opensource software a Free Software mají svá specifika a zastánce. V tomto dokumentu je při použití termínu Open Source Software nebo zkratky OSS myšleno užití software dle vlastností, které jsou zahrnuty jak v OSS, tak Free Software. Pro detailní rozbor těchto termínů je možné navštívit stránky a nebo Administrátorem je pro účely tohoto dokumentu myšlen jedinec nebo skupina osob Typografické konvence Názvy produktů jsou uvedeny kurzívou: Název produktu Ukázky programového kódu jsou uvedeny také kurzívou: Nějaký kód 1.3. Cílová skupina Tento dokumentu byl vytvořen především pro manažery a řídící pracovníky firem, neziskových organizací nebo státních institucí Cíl dokumentu Účelem této metodiky je poskytnout návod administrátorům, jak postupovat při rozhodování o možném přechodu na technologie postavené na OSS. Zároveň popisuje v širších souvislostech, jak by takový přechod měl být realizován. Záměrem bylo připravit materiál praktický pro administrátory s důrazem na srozumitelnost. V žádném případě se nejedná o učebnici nebo referenční příručku k určitému výrobku. Důraz byl kladen na strukturu dokumentu, která se dá snadno přepracovat tak, aby budoucí aktualizace v důsledku změn a přirozenému vývoji v uvedených produktech byly snazší. Pokud má tento dokument plnit svůj cíl i v budoucnu je zcela nevyhnutelné jej udržovat v aktuálním stavu. Jakékoliv připomínky, návrhy a vlastní zkušenosti nám můžete posílat prostřednictvím ové adresy poradenstvi@vasemoznosti.cz. 5

6 Cílem tohoto materiálu není informovat čtenáře v obecné rovině o přínosech OSS, licenční politice atp. Tyto informace mohou být nalezeny na stránkách Poradenského centra pro podporu implementace opensource software ( a po dohodě konzultovány v rámci poradenské činnosti Institutu pro informační společnost. 6

7 2. Stručný přehled Tato metodika je určena IT manažerům, managementu, ale i řadovým uživatelům, kteří uvažují o přechodu na Open Source software (OSS). Materiál obsahuje návod postavený na znalostech a zkušenostech tvůrců a jsou v něm zohledněny připomínky a výsledky testování různých subjektů, které mají konkrétní zkušenost s přechodem na otevřenou platformu. Postupy byly ověřeny v rámci fungování Poradenského centra pro podporu implementace opensource software, které provozuje Institut pro informační společnost. Existuje mnoho důvodů, proč přejít na OSS řešení. Mezi hlavními jsou například otevřenost vůči dalším úpravám software v případě růstu nároků organizace, vysoká úroveň bezpečnosti a zabezpečení, eliminace nucených změn z důvodu politiky komerčního dodavatele řešení, pořizovací náklady na software. Všechny tyto výhody je možné vyčíslit do podoby úspor, kterou implementace a provoz open source technologií představuje. Tento dokument doporučuje: před začátkem přechodu mít zcela jasno v důvodech, proč migrovat na nové řešení mít zajištěnou aktivní podporu ze strany správy IT, případně uživatelů pracovník odpovědný za změnu by měl být s přechodem plně ztotožněn mít vypracovanou expertízu a tým pro přechod na OSS začít přechod na systémech, které nekontrolují kritické funkce organizace ujistit se, že každý krok při přechodu je možné řídit a hodnotit Jakákoliv změna v ITC systémech představuje příležitost upravit vnitroorganizační procesy a pracovní toky. Je nutné mít pře započetím migrace mít ujasněno: jak bude zajištěna vzájemná součinnost jednotlivých částí systému jak bude zajištěna podpora pro mobilní uživatele jak bude zajištěna podpora a bezpečnost pro vzdálené uživatele jak vybudovat sytém, který je udržitelný a řízený (v souladu s např. ISO atp.) Zvláštní pozornost je třeba věnovat nastavení bezpečnostních pravidel již na začátku procesu plánování migrace. Nasazení OSS v oblasti serverů je obecně velmi rozvinuté i zdokumentované. Migrace serverů na OSS může být obecně provedena bez jakýkoliv dalších dopadů na uživatele a obyčejně je to prvním krokem, ke kterému se organizace uchylují. 7

8 Umístění OSS na pracovní stanice představuje pro většinu organizací výrazné úspory. V případě přechodu na OSS na pracovní stanicíce je potřeba věnovat pozornost funkčnosti propojení se stávajícími aplikacemi a tzv. groupware. V situacích, kdy dochází k nahrazování proprietárního software, který má na starosti automatizaci v rámci kancelářských operací, je nutné zajistit, aby šablony a funkce produkovaly požadované úkony a výstupy. Problematika maker v takových případech musí být obyčejně řešena skripty. Aplikace, které nemají OSS alternativu, mohou být spouštěny prostřednictvím tenkých klientů. S postupem času je nabídka OSS aplikací pro pracovní stanice stále širší a kvalitnější.. Tento dokument souží jako metodika pro kompletní přechod na OSS, avšak v situacích, kdy jsou užívány tisíce pracovních stanic, je nutné počítat s delší prodlevou v realizaci. Kombinace nasazení OSS a komerčních aplikací bývá v takových případech nezbytná. Některé procesy je možné svědomitě svěřit OSS aplikacím. Rozhodnutí by měla být dělána s vědomím nadčasovosti, aby v budoucnu nemohlo dojít k závislosti na konkrétní technologii nebo proprietárním formátu. OSS technologie jsou revoluční, protože z marketingového hlediska mění produktově orientované organizace na sektor služeb. OSS software je možné instalovat bez nákladů na pořízení. Důležité je však vzít v potaz otázku podpory. Přestože dnes existuje řada organizací, které se věnují poskytování podpory, je důležité znát odpověď na otázku podpory. Spoléhat se v této záležitosti na komunitu by bylo velmi nezodpovědné a pro fungování organizace svazující. Naopak sdílení know how a technologií v rámci skupiny organizací může výrazně snížit náklady na implementaci a správu IT. 8

9 3. Metodika Testování nebo zkoušení přechodu by mělo obsahovat následující: Fáze sběru dat a definice projektu Popis výchozí situace Architektura systémů Popis záměru Aplikace a asociované datové zdroje Použité protokoly a standardy Hardware Fyzické prostředí (rozmístění sítí, propustnost) Lidské zdroje (požadavky na znalosti) o Architektura systémů Aplikace a asociované datové zdroje Použité protokoly a standardy Hardware Fyzické prostředí (rozmístění sítí, propustnost) Lidské zdroje (požadavky na znalosti) Popis plánu, jak se dostat od výchozího stavu k záměru Zhodnocení nákladů a klíčových faktorů nutných k úspěšné migraci na OSS Návrh testovací fáze, která má ověřit funkčnost záměru, testování Úprava realizačního plánu podle výsledků testování Realizace Monitoring odchylek oproti plánu a zapracování provozních zkušeností Obsah prvního bodu výše uvedeného postupu je popsán dále v tomto materiálu v kapitole Scénář popsán detailněji s návodem jak přejít na OSS za určitých okolností. Tento návod pochopitelně nemůže být vyčerpávající, protože nemohou být pokryty veškeré možné modelové situace, které mohou v praxi nastat. Vybrána byla různá cílová prostředí (1.2) a zjednodušeny byly příklady výchozího stavu (1.1). Cílové prostředí je diskutováno v třetím oddíle tohoto dokumentu. Definované cílové prostředí umožnilo připravit scénář přechodu od zjednodušeného výchozího stavu. 9

10 V případě potřeby může být metodika v budoucnu doplněna o nové kapitoly, které by popisovaly jiné modelové situace podle aktuálních dispozic. Nové kapitoly tak mohou být napsány na základě konkrétních úspěšných případů migrace. Rozhodování o přechodu na OSS se neobejde bez systematického posouzení (2. bod) nákladů a přínosů. Z tohoto důvodu tato metodika obsahuje také tabulku nákladů, která ukazuje, jak jednotlivé scénáře mohou být nákladné a co obnáší přechod na OSS. Protože jsou úspěšné případové studie o nasazení OSS málo publikované, je součástí přílohy několik studií o nasazení OSS. Tato metodika se tak stala sborníkem úspěšných příkladů a zkušeností celé řady subjektů, které se přechodem na OSS intenzivně zabývají. Velké množství vstupních situací a cílových záměrů představuje obrovské množství kombinací řešení, které mohou být na organizaci aplikovány. Metodika je kvůli přínosu pro praxi napsána v duchu toho co se dělalo a jak, než aby popisovala, co by mohlo být uděláno. Prostor, který vzniká pro případné dotazy, by měl být vyplněn například poradenstvím buď IPIS nebo libovolného subjektu, který se otázkou migrace seriózně zabývá. Ve specifických případech pochopitelně může být žádoucí zachování určitých proprietárních systémů, to však záleží již na rozhodnutí realizátora. 10

11 4. Manažerská příručka 4.1. Přehled migrace Většina činností a úkonů, které musí být v rámci přechodu na OSS provedeny, jsou v podstatě totožné s těmi, které se týkají přechodu na jakýkoliv jiný proprietární software. I v případě nákupu tzv. krabicového software je třeba zajistit propojení a provést určité úkony, které zajistí správné zavedení nového software nejen po stránce technické, ale především organizační, aby investované prostředky byly efektivně využívány a přirozeně vedly ke zlepšení chodu organizace. Jakékoliv změny tak musí být nadčasově promyšleny a naplánovány bez ohledu na licenční politiku, kterou se dané řešení řídí. Tato příručka není návodem ani vyčerpávajícím seznamem úkonů pro projektového manažera. Vycházíme z předpokladu, že odpovědný administrátor disponuje potřebnými zkušenostmi vést projektově řízený přechod na jiná technologická řešení. Níže uvedené body jsou sumářem kroků, které musí být vzaty v potaz, aby přechod proběhl hladce. Některé aktivity mohou samozřejmě probíhat paralelně, avšak to již záleží na konkrétní volbě přístupu, který pro migraci zvolí projektový manažer. Také je nutné vzít v potaz, že skutečný realizační plán se sestavuje samozřejmě na základě konkrétního výchozího a cílového stavu a dispozic, které organizace zrovna má. řada administrátorů se tak může rozhodnout, že problematiku OSS budou pouze sledovat jako příležitost, kterou mohou za určitých okolností využít (např. jakmile organizace expanduje atp.) Více o nadčasovém přístupu administrátorů je napsáno níže v kapitole Nadčasový přístup Vytvoření týmu s odpovídajícími znalostmi a manažerskou podporou. Manažerská podpora je v tomto bodě klíčová, protože všechny organizace mají sklony k rezistenci ke změnám bez ohledu na řešení. Tato podpora musí být dostatečně silná, aby bylo možno realizovat pilotní odzkoušení na reprezentativním vzorku systémových operací. Následně se dá vytvořit kompletní plán, který bude zohledňovat netechnické atributy, které změna v organizaci vyvolá. Počet pozitivních by měl pochopitelně převažovat nad negativními Pochopení cílového prostředí bez ohledu na platformu a znalost možností, které existují a jsou k dispozici. Tento bod může zahrnovat nejen odborné konzultace, ale také nábor nových lidí nebo zvyšování kvalifikace a znalostí stávajících pracovníků. Tento bod již 11

12 obnáší citelnější investici, proto je nutný souhlas vedení organizace. Názor, že software, který je zdarma, může být implementován bez nákladů, je naprosto zcestný a nebezpečný! Příprava na migraci je příležitostí k revizi stávající architektury a systému pracovních toků. Návrhem možné architektury s ohledem na efektivní řízení je možné se dočíst dále v tomto dokumentu, kde jsou popsány i výhody, které určitý přístup má, a také náklady/problémy, které nese Pochopení OSS: Problematika licencí by měla být zvládnuta (některé organizace mají ze zákona povinnost evidovat software). Pro účely účetnictví, evidence, ale i nastavení odpovědnosti v organizaci je vhodné mít zavedený Software Management, který eliminuje např. používání nelegálního software z nevědomosti nebo nedbalosti a chrání organizaci před konsekvencemi porušení autorských práv. Znalost produktových možností. V rámci distribuce OSS mohou může existovat i několik programů, které plní určitou funkci. Migrační tým by měl znát pro a proti jednotlivých produktů tak, aby byl schopen vybrat nejvhodnější softwarový nástroj. OSS je šířen v různých distribucích, ve kterých může být podstatný rozdíl. Některé z distribucí mají poradenské zázemí, které poskytují komerční firmy. Také přístup k aktualizacím a úpravám software je různý. Některé distribuce zahrnují pouze řádně otestovaný, ale starší software, jiné obsahují novinky, které však mohou mít chyby, které jsou odstraňovány až s postupem času. Administrátoři musí mít ujasněno, jakou úroveň podpory očekávají. Komerční podporu mohou získat buď od vývojáře aplikace nebo od třetí strany, která se poskytováním podpory živí. Toto je zásadní rozdíl od komerčního software, u kterého se uživatel vázán na podporu pouze u autorizovaných firem, které mají přístup ke zdrojovému kódu. Problémem se tak může stát, pokud proprietární software zastará a výrobce jej už dále nevyvíjí nebo neposkytuje k němu podporu. Administrátoři mohou řešit problémy i v rámci vývojové komunity, avšak tento způsob není zcela nejefektivnější, avšak v případě kvalitního personálního obsazení IT může mít své příznivce Audit stávajícího systému. Tato data jsou užitečná nejen pro účely migrace, ale především odhalí skutečné náklady na provoz stávajícího ICT řešení. Data jsou výchozím 12

13 podkladem pro plán migrace, protože vytváří vztažnou soustavu, vůči které se mohou porovnávat náklady a přínosy s pojené s realizací cílového záměru. Audit by měl zahrnovat: Softwarový audit Název aplikace, číslo verze, zodpovědná osoba Počet instalací / počet licencí / počet uživatelů Operační systém / jiné OS, na kterých může být aplikace provozována Jiné aplikace, které jsou nutné k zajištění chodu této aplikace Hardwarové požadavky / použitý hardware Jaké protokoly jsou použity pro komunikaci s dalšími aplikacemi Jaké formáty souborů jsou podporovány / požadovány Jaké jsou používané jazyky, měny, znakové sady a jiná specifická nastavení Datový audit jaká data jsou požadována, kým jsou užívána, jak je s nim i nakládáno Determinace problémů, které jsou mimo kontrolu administrátora, avšak jsou vytvářeny interními procesy za použití ICT Popis požadavků na uchování dat (zálohy a archivace) o Data, která nemusí být uchovávána a jsou zbytečná o Data, která musí být uchována a již jsou v otevřeném formátu nebo mohou být do něj snadno převedena. Zohledněn musí být čas/náklady převodu. o Data, která musí být uchována, ale jsou v proprietárním formátu, který nemůže být snadno převeden do otevřeného formátu. Tato data mohou požadovat, aby byly zachovány některé proprietární aplikace. V závislosti na požadavek přístupnosti těchto dat by měl být stanoven minimální počet kopií aplikací k otevření, který musí být zachován do budoucna. Popsány musí být také specifické hardware požadavky, je-li to nutné. Bezpečnostní požadavky Jaký je používán stávající systém pro přiřazování loginu a hesla jaká je politika pro aktualizaci hesla Jsou používány jiné systémy autentifikace než pouze uživatelské jméno a heslo Je regulacemi (zákonem nebo interně) omezeno používání konkrétních 13

14 nástrojů (např. internet, ) atp. Jaké bezpečnostní zařízení je používáno, které vyžaduje speciální hardware Vytvoření detailního plánu pro přechod, který je postaven na informacích získaných viz výše. Plán musí obsahovat: Náklady výchozího (stávajícího) prostředí v horizontu cca 5 let s relevantními odhady Náklady alternativních prostředí včetně ceny za migraci za stejné časové období SWOT analýza stávajícího a cílového prostředí, doplnění o alternativy Konzultace s experty. Je nutné zjistit veškeré dopady a důsledky migrace. Dřívější zapojení expertů znamená dřívější odhalení problémů, které stojí úsilí a tedy peníze. Experti by měli testovat i pilotní model. Experti zároveň vnesou vnější pohled na organizaci, což ji posune vpřed po stránce efektivity. Je důležité vytvořit help desk, aby mohly být rozptýleny obavy a fámy, které se mohou během migrace vyskytovat. Intranet je vhodným nástrojem, který poskytne uživatelům nejen informace, ale i prostor pro vzdělávání. Tato sekce zapadá do knowledge managementu firmy Zahájení pilotních projektů začíná ihned po dokončení plánu migrace. Pilotní projekty by měly běžet v reálném prostředí, ale s omezenou skupinou uživatel. Testování v rámci pilotáže by mělo poskytnout: Data pro upřesnění nákladovosti jednotlivých řešení Reakce uživatelů na nová řešení Evaluace a úprava cílové architektury a migračního plánu Určení metody a rychlosti přechodu na nové řešení Je velmi pravděpodobné, že nový a starý systém budou muset po nějakou dobu fungovat současně. Protože výměna posledního PC může být až za dlouhou dobu, nebo se nikdy nestane, je mimořádně důležité zajistit ko-existenci obou systémů tak, aby nebyl narušen chod organizace. Výměna může probíhat následujícími způsoby: Big Bang rychlý přechod, kdy všichni uživatelé mění starý systém za nový ve stejném čase. Prakticky to znamená připravit nové řešení během víkendu nebo v době svátku. Výhoda tohoto přístupu tkví v tom, že administrátor nemusí udržovat duální systém a uživatelé nemusí přepínat mezi novým a 14

15 starým systémem. Nevýhodou je velmi vysoké riziko a požadavky na zdroje v době změny. Tento přístup je použitelný pouze u malých organizací. Tento přístup velmi pravděpodobně bude představovat spoustu problémů, které budou muset být za chodu řešeny. Vzniklé chyby pak nejsou chybou například OSS řešení, ale chybou projektového manažera. Fázový přesun ve skupinách uživatelé přecházejí na nový systém ze starého ve skupinách. Je velmi pravděpodobné, že při přechodu funkční skupiny najednou se minimalizují problémy spojené s sdílením dat a jiné spolupráce ve skupině. Míra rizika a management zdrojů může být ovlivněn volbou správné velikosti skupiny. Je možné provést např. záměnu hardware (pracovních stanic) za nově připravené. Stávající stanice pak budou přeinstalovány, a pak předány další skupině uživatel. Individuální přechod uživatelé přecházejí na nové řešení jednotlivě. Tento přístup je velice zdlouhavý a nevhodný pro větší organizace, avšak je ideálním přístupem pro pilotní fázi Zapojení všech administrátorů. Je samozřejmé, že migrace bude představovat zaškolení personálu i techniků (školitelů) Sledování zpětné vazby ze strany uživ\tel a opravy problémů, které se objevily. Některé požadavky uživatelů mohou být natolik zvláštní, že nemohly být předvídány nebo identifikovány v průběhu pilotního odzkoušení. Je nutné s tímto bodem počítat a vyčlenit pro realizaci dostatek zdrojů. V kterékoliv části realizace může nastat situace, že migrace není proveditelná. Tyto situace mohou nastat, pokud nebylo provedeno otestování a kompletní nahrazení kritických aplikací nebo alternativní řešení by bylo příliš nákladné Lidské zdroje Tato příručka není také příručkou řízení lidských zdrojů, přestože administrátoři a projekt manažer se bude muset s pravidly řízení lidských zdrojů potýkat. Personalisté by měli být zapojeni do projektu již ve fázi příprav, protože je nutné, aby motivovali pracovníky ke změně. Důraz by měl být kladen na přínosy, které zaznamenaly jiné organizace, co přešly na OSS řešení. Stěžejní je dobrá informovanost pracovníků o aktuálních postupech a konzultace jejich 15

16 potřeb. Jednou z možností, jak efektivně komunikovat změnu a získávat zpětnou vazbu je sdílený intranet, který je možné snadno aktualizovat. Přístup ke školení je velmi důležitý. Zatímco některé organizace ponechávají rozhodnutí o nutnosti zaškolení na pracovnících, jiné účast na školení vyžadují. Je nutné si uvědomit, že při přechodu na jakékoliv nové řešení nejde o jen o znalost nové technologie nebo její intuitivní znalost, ale především o nová pravidla administrace, sdílení dat nebo jiné spolupráce. V případě nových technologií je třeba počítat s faktem, že dokumentace k většině opensourcových technologií je v angličtině, což může znamenat překážku u některých uživatelů. Náklady na překlady a lokalizaci software spolu s tvorbou nebo překladem nutných dokumentací a příruček k proškolení pracovníků jsou součástí nákladů na migraci na open source řešení. Vyřešit je nutné také problém s aktualizací, aby se software nebo dokumentace nemusel po každé aktualizaci znova upravovat, což by zvyšovalo náklady na správu systému a snižovalo výhodu, kterou by měl open source software přestavovat. Moderní uživatelská prostředí Gnome a KDE poskytují výběr řady jazyků a významnější aplikace jsou obyčejně lokalizovány, avšak nápověda bývá obvykle pouze v angličtině. Přechod na nové řešení představuje klasické reakce lidí na změnu v pracovních procesech, se kterými je třeba počítat: Strach z neznámého Nová OSS platforma bude pro většinu lidí zcela novou zkušeností, proto se budou proti této změně bránit, jelikož strach z neznámého je přirozený a OSS je pro ně něco nového. Na druhé straně existuje skupina osob, pro kterou bude změna novou výzvou zkusit si něco nového a právě této skupině by mělo být OSS řešení představeno jako prvním. Schopní lidé s nadšením poskytnou nejen zpětnou vazbu v době příprav, ale také budou vytvářet pozitivní prostředí pro změnu působením na ostatní. První skupina uživatelů je zaškolena v průběhu pilotního testování. Jakmile si osvojí nové procesy mohou být nápomocni při motivaci a zaškolení svých kolegů. V každém případě je nutné mít připravené školící materiály a stálý přístup k intranetu pro pomaleji se učící personál. Tentýž proces je možná aplikovat na systémové pracovníky s rozdílem, že rozsah znalostí musí být mnohem širší. Strach z neznámého u systémových pracovníků by měl být překonán již v úvodní fázi příprav. Systémoví pracovníci budou plnit funkci podpory, u které budou jiní uživatelé později hledat odpovědi na své dotazy. Pokud by systémoví pracovníci nebyli zcela ztotožnění s funkčností navrženého řešení, pak by nemohli přesvědčivě radit s přechodem a chodem OSS. 16

17 Kariérové obavy U řady ambiciózních zaměstnanců může nastat situace, kdy se budou obávat, že nestandardní řešení, kterým z hlediska zažitého fungování ICT světa OSS bezesporu je, jim bude činit problémy v dalším kariérovém postupu. Tento skrytý problém není radno podceňovat, protože dokud nebude OSS všeobecně akceptován jako standard či výhoda, lidé mohou být vůči učení se něčemu novému rezervovaní. V dnešní době je možné pozorovat nepsaný trend, že open-sourcoví specialisté jsou hodnoceni lépe než jejich kolegové pracující s komerčními produkty. Sebevědomí Lidé, kteří znají současný systém a procesy velmi dobře, mohou ztratit o OSS řešení zájem v případě, že zjistí, že nové řešení je od stávajícího odlišné. Tito lidé jsou přirozenou podporou v organizaci, protože mohou pomáhat řadovým pracovníkům s problémy, do kterých se během plnění pracovních povinností mohou dostat. Tito lidé by však neměli být začleněni do týmu pro pilotní odzkoušení ani mezi první proškolené pracovníky, protože jejich přesvědčení musí být náležitě opečováváno Užitečné postřehy Během přechodu na OSS se objeví řada okolností, které je dobré mít na paměti: Představení nových aplikací ve známém prostředí Spousta OSS aplikací bude funkční i v proprietárním operačním systému, což vytváří pracovníkům možnost plynule se seznámit s novými aplikace ve známém stávajícím prostředí. Jako příklad takových aplikací je možné jmenovat prohlížeč Firefox, software Apache, OpenOffice nebo Thunderbird. Tento přístup může pro uživatele znamenat méně drastický proces bez nutnosti složitého přeškolování a další změny mohou být také snadněji komunikovány v návaznosti na dobrou zkušenost, kterou budou uživatelé s novými aplikacemi mít. Také nesnáze, které mohou vyvstat v souvislosti s novými formáty a potřebou konverze budou daleko lépe řešeny, pokud po přechodnou dobu paralelně poběží stávající aplikace. Problémy s makry a šablonami je také možno řešit v daleko méně hektickém období, kdy změny v souvislosti s přechodem nebudou ještě tak znatelné. Tento přístup znamená, že výběr nových aplikací by měl být podmíněn existencí verze pro stávající operační systém. Přestože existuje např. ový klient s pokročilými funkcemi (Evolution), pro účely přechodu může být vhodnější volbou Thunderbird, který existuje i na komerční platformě. 17

18 Začít změnu se snadnými programy Změny, které jsou dělány na první úrovni, nebudou vyrušovat uživatele. To znamená, že změny na straně serveru nemusí být vůbec pozorovány a přitom vytvoří dobrou komunikační platformu pro představení plánovaných změn na straně pracovních stanic. Řada OSS změn na straně serveru, kterých si uživatel vůbec nevšimne, je zcela kompatibilní s komerčním řešením. Typickými příklady, kdy stávající řešení může být nahrazeno OSS ekvivalentem bez ohrožení kompatibility, jsou DNS servery, DHCP servery, databázové servery atp. Detailněji jsou tato nahrazení popsána dále v tomto dokumentu. Některé aplikace jako např. Samba, které nemohou být požity v OSS prostředí umožňují souběžné fungování proprietární i OSS platformy. Časné nasazení těchto aplikací může být prospěšné, protože zefektivní rozdělení přechodu do snadněji zvládnutelných etap. Nadčasový přístup V případě, že změny spojené s přechodem budou dělány minimalisticky bez ohledu na budoucí vývoj, mohou nastat komplikace při pokročilejších fázích přechodu. Je nutné mít na paměti: Nově připravované webové aplikace se musí správně zobrazovat jak ve starých, tak i nových OSS prohlížečích. K dispozici je spousta nástrojů pro verifikaci webových aplikací, které testují správné zobrazování aplikace. Odpadá tak problém nutnosti používat specifické prohlížeče obsahu. Tento požadavek by měl být dodržován bez ohledu na to, zda jsou aplikace vyvíjeny pracovníky příslušné organizace nebo externím dodavatelem. Makra a skripty v dokumentech by měly být nahrazeny jinými technikami, které by zajistily podobnou funkcionalitu. Tato změna je zároveň změnou k dobré praxi, že eliminací maker se výrazně snižuje riziko infikování souborů jednoduchým virem, který může mít za následek ztrátu, zneužití nebo jiné poškození dat a systému. Používání rozšířených OSS formátů, které se staly standardy (např. pdf). Je zcela zbytečné používat pro dokumenty, které nejsou určeny pro další editaci, proprietární textové formáty, které jsou navíc náchylnější pro šíření virů, obsahují také metadata o chování uživatele, která mohou být snadno čtena jinými. Ani vymazaný text tak není skutečně smazaným, což může vést k úniku některých informací o historii dokumentu atp. Zároveň používáním proprietárního software pro tuto formu dat se zbytečně buduje budoucí závislost na konkrétním nositeli práv k danému formátu. 18

19 V případě psaní dokumentu ve spolupráci s dalšími osobami je vhodné používat ten nejnižší obecný formát, ve kterém se dá pracovat, protože se tak sníží závislost na pořízení nového software v rámci pracovní skupiny. Navíc se zjednoduší přechod na OSS řešení díky lepší kompatibilitě se staršími verzemi. Je vhodné používat tzv. open standard protocols, za které jsou považovány protokoly bez patentové ochrany, a které jsou šířeny s OSS. Existují různé sady těchto protokolů, které jsou rozšířeny v závislosti na geografickém území a mohou obsahovat drobné odlišnosti (např. OSOSS nebo SAGA). Nově vyvíjené systémy by měly být na tzv. 3-tier architektuře detailněji viz další kapitola. Aplikační kód by měl být nezávislý na lidských zásazích a metodách přístupu k datům. Aplikace by měly být budovány modulárně, aby např. webové rozhraní podporovalo OSS webové prohlížeče atp., což umožní přechod ve fázích a také sníží riziko kolapsu v době přechodu. Tradiční monolitické aplikace jsou z hlediska budoucího vývoje nepraktické. Všechny nové aplikace by měly být přenositelné (multiplatformní), což představuje využívání standardizovaných jazyků jako Java, Python nebo Perl, a také multiplatformních knihoven a GUI nástrojů jako wxwindows nebo FOXtoolkit. Nové aplikace by neměly vyžadovat přítomnost dalších proprietárních aplikací nebo specifických jazyků a APIs. Proprietární čtečky pošty, které užívají proprietární formáty na úschovu pošty nebo komunikují se servery prostřednictvím proprietárních protokolů, by měly být nahrazeny dostupnými alternativami pro uchovávání adresáře nebo kalendáře. 19

20 5. Technická příručka 5.1. Referenční architektura Generická architektura Jednou z cest jak popsat schéma architektury je tzv. 3-tier model. Tento model se sestává ze tří hlavních funkcí, které plní aplikace, když jsou používány člověkem. Nejedná se tedy o funkce vyvolané čistě serverovou či batch aplikací. Obr. č. 1 ukazuje jak jsou předávány informace mezi třemi částmi modelu. Toky informací by v ideálním případě používaly otevřené standardy. Jednotlivé části fungují nezávisle, což znamená, že aplikace se stará pouze o svou vlastní logiku, zatímco další funkce jsou ponechány standardním komponentům. Díky tomuto přístupu může být aplikační kód jednodušší a také může mnohem snadněji fungovat v jiném prostředí. Přístup k datům Kód aplikace Lidské rozhraní Souborové systémy Logická struktura Periférie Obr. č. 1 Tento 3-tier model může být dále rozvíjen jako n-tier, protože komponenty mohou být dále členěny, a tak je realizován za pomocí objektové nebo komponentní technologie. Spousta klient-server aplikací v minulosti používala 2-tier model, kdy aplikační kód a lidské rozhraní byly spojeny v jedno. V případě migrace to přináší více problémů něž u modelu 3- tier. Důvodem jsou požadavky na určitá uživatelská rozhraní, která vyžadují změny, avšak 2-tier aplikace mají lidská rozhraní zakomponována do logické struktury aplikace. Komunikace mezi třemi částmi 3-tier modelu se obvykle realizuje prostřednictvím protokolů, což umožňuje, aby jednotlivé části byly provozovány na zcela odlišných počítačích. Protože některé části mohou být rozděleny, vniká prostor pro skutečně variabilní architekturu, podle požadavků organizace. Z pohledu pracovní stanice, na které musí obvykle běžet alespoň minimální kód 20