Pro správnou implementaci korporátního systému pro správu obsahu potřebujeme ve fáze analýzy a v prvních fázích implementace systému rozkrýt následující faktory:

  • Typ obsahu. Jaké dokumenty společnost ukládá, v jakých formátech?

  • Kvantita obsahu. Počty dokumentů, průměrný počet stran a velikost, přírůstky.

  • Automatické generování ID. Na základě čeho lze určit ContentID, aby dával lepší smysl?

  • Uživatelé. Jací uživatelé budou se systémem pracovat? Odkud budou přicházet?

  • Autentizace. Jak se budou uživatelé autentizovat? Jaký systém bude zdrojem pro autentizaci?

  • Konzumenti. Bude třeba přístup pouze pro čtení (např. web) pro určitou skupinu uživatelů?

  • Autoři. Definice skupiny, která bude mít plný přístup do systému (vytváření dokumentů). Tato skupina je důležitá, jelikož se od ní obvykle odvíjí sizing.

  • Integrátoři. Partneři třetích stan. Jak budou do systému přispívat nebo z něj číst?

  • Weboví správci. Pokud bude systém publikovat obsah i na webu, kdo bude zodpovědný za správu a design webové části a šablon?

  • Administrátoři. Kteří uživatelé budou systém spravovat? Jaké bude rozdělení mezi nimi?

  • Autentifikace. Kteří uživatelé budou lokální (globální) a kteří externí (MSAD, LDAP)?

  • Rozdělení serverů - hardwaru. Pro lepší škálování a také z bezpečnostních důvodů (organizační struktura) je potřeba jednotlivé úkoly rozdělit mezi servery. Obvykle se vyčlení server pro přispívání, schvalování (stagging) a spotřebu obsahu (consumption).

  • Úložný prostor. Kam budou instance fyzicky dokumenty ukládat? Jaká technologie bude použita? Je potřeba vyhovět nějakým legislativním normám?

  • Vysoká dostupnost. Bude zákazník požadovat zdvojení hardwaru kvůli pokrytí výpadků?

  • Testovací prostředí. Je třeba si předem ujasnit, že pro implementaci je potřeba odděleného prostředí. Pro performance testy pak úplná kopie (hardware, software, architektura).

  • Distribuovanost. S ohledem na organizační strukturu (např. pobočky) je možné nasadit tzv. proxy content servery – servery s vlastním obsahem i metadaty, ale se stejným rozhraním.

  • Počet instancí. Je možné vytvořit více instancí content serveru na jednom fyzickém hardware. Lze tím řešit určité bezpečnostní otázky i problémy dimenzování.

  • Škálování. Více content server instancí může sdílet stejná data i metadata. S tím, jak firma bude růst (data migrována), je potřeba dimenzovat určitý počet instancí. Kde se očekávají největší nárůsty dat? Kde budou uživatelé nejvíce přistupovat (vyhledávat)? S problémem škálování úzce souvisí další faktor.

  • Počet položek obsahu. Při návrhu rozdělení serverů je vhodné počítat cca s milionem položek obsahu (content items) na jeden content server. Jaké jsou předpoklady pro jednotlivé vyčleněné servery? Jaké přírůstky?

  • Databáze. Jakou DB použít? Využít vlastnosti fulltextového vyhledávání databáze?

  • Firewall. Kde budou umístěny firewally? Jaké protokoly kde povolit? Které kanály zabezpečit? Které protokoly otevřít pro content servery (např. SMTP)?

  • DMZ. Do DMZ typicky patří webový server. S ohledem na typ nasazení a organizační strukturu, které servery umístit do DMZ?

  • Webový server. DMS systémy obecně nabízejí dvě úrovně integrace s webem – určitý způsob převodu dokumentů včetně struktury na webový server s využitím workflow, nebo integrace s portálovými a jinými aplikacemi třetích stran. Jaká bude zvolena úroveň? Bude se správa obsahu převádět do korporátní webové prezentace (první varianta)? Pokud ano, kde bude umístěn webový server? Jaké budou na něj kladeny požadavky? Bude použit portál (druhá varianta)? Je portál součástí dodávky? Jaké jsou požadavky na portál (funkční, nefunkční)? V případě dodávky od třetí strany – je jasně definovaná hranice, co bude dodávat DMS a co portál (např. s ohledem na transformace dokumentů a jiné faktory)? Jaké budou použity technologie pro integraci s portálem?

  • Aplikační server. Na jaké servery umístit (webové) aplikace a portály, které budou mít přístup na obsah?

  • Load-ballancing. S ohledem na faktor škálování, kde umístit load-balancery?

  • Publikování do HTML. DMS mají moduly (např. Oracle Content Publisher) pro automatickou konverzi a publikování dokumentů pomocí šablon do statických HTML, XHTML, WML nebo XMLsouborů. Ty mohou být poté publikovány na internetu pomocí libovolného webového serveru. Přeje si zákazník toto využít? Kteří uživatelé budou za co odpovědni (web designéři, grafici)? Kdo/kdy dodá šablony webu a šablony dokumentů? Jak bude provedena integrace s webovým serverem (nakopírování souborů) – možnosti jsou obvykle přímé sdílení a FTP.

  • Kopie HTML přes content server. Mezi CS a webový server lze „vklínit“ ještě jeden CS, který bude představovat kopii publikovaných dokumentů na webu (aktuální stav), ve které lze vyhledávat či procházet historii. Je potřeba mít pohled na publikované dokumenty a jejich historii?

  • Transfer dokumentů mezi servery. S ohledem na faktor rozdělení serverů je potřeba dokumenty mezi servery přesouvat (např. server pro pořízení obsahu → server pro konzumaci → server pro archivaci). Každý server může mít jiný typ ukládání dat. Pro tyto účely existuje v DMS modul (Oracle Archiver). Jaká bude pro přesun dokumentů politika? Na základě čeho se bude transfer iniciovat (čas, akce)? Jakým protokolem bude přenos probíhat (přímo, HTTP(S))?

  • Převod dokumentů na share. DMS systém umí kopírovat/přesouvat/transformovat dokumenty z repozitářů do sdílených složek. Je potřeba dokumenty zpřístupnit přes sdílené složky? Pouze kopie? Jaké dokumenty? Kdy akci provést? Archivovat nebo jen přesouvat? Jaká bude politika? Následné zabezpečení?

  • Bezpečnostní model. Je potřeba vytvořit takový model, aby byl bezpečný, ale i snadno pochopitelný pro uživatele. Typicky by měl být zachycený na jednu stranu A4, protože jinak hrozí riziko nepochopení uživatelů a následné fatální chyby v bezpečnosti. Oracle UCM nabízí dva modely – standardní a rozšířený (account-based) model.

  • Standardní model. Je potřeba nadefinovat skupiny a oprávnění na jednotlivé prostředky (RWDA). Jaké budou skupiny, role, prostředky? Jaký bude celkový počet skupin?

  • Rozšířený model. Pokud nestačí standardní koncept role-skupina-uživatel-prostředek, je potřeba využít rozšířeného modelu. Typicky je to v situacích, kdy máme více vrstev (například pobočka + oddělení v pobočce) a potřebujeme definovat větší počet bezpečnostních skupin (groups). Potřebuje společnost použít rozšířený model?

  • Vyhledávání. Standardní instalace umožní vyhledávání v metadatech automaticky, lze také nastavit databázi tak, aby bylo vyhledávání v metadatech fulltextové. Další dvě varianty jsou použít pro fulltext resp. metadata specializované enginy Verity K2 nebo FAST InStream.

  • Konverze do PDF. Content Server dokáže pomocí modulů PDF Converter a Inbound Refinery při vložení dokumentu automaticky konvertovat na PDF. Použit musí být software třetí strany: Acrobat Distiler, PostScript Printer a instalace programů (na serveru), které jsou použity pro otevírání dokumentů a tisk (např. MS Office). Je požadován převod do PDF? Jaké typy dokumentů (přesný výčet)?

  • Konverze do HTML. V Oracle UCM jsou dvě možnosti konverze. Výše popsaný Content Publisher (obvykle na dedikovaném hardware) exportuje do HTML při zachování formátování v pravidelných intervalech včetně možnosti vytvoření navigace a přístupného webu. Naproti tomu komponenta Dynamic Converter je schopna na požádání vygenerovat HTML reprezentaci na asi 200 typů dokumentů a je určena spíše na umožnění otevření různých typů dokumentů přes web. Je potřeba publikování na webu? Jaké jsou očekávání (včetně hlediska vzhledu)? Kterou technologii zvolit? Zákazník by měl dodat ukázkové dokumenty a měl by být proveden test konverze. Bude požadováno kromě HTML také WML nebo cHTML (comact – PDA)?

  • Konverze do XML. Oracle UCM nabízí pokročilé moduly pro konverzi strukturovaných dat do XML za použití modulu XML Converter a produktů Oracle OutsideIn a FlexionDoc/SearchML. Tato funkčnost obvykle není dodávána při pilotu nebo prvním nasazení a konsolidaci korporátního dokumentačního systému. Očekává zákazník konverzi do XML? Jaké jsou datové zdroje? Jaké se předpokládají výstupy? Budou probíhat i transformace?

  • Další konverze. Jsou požadovány další konverzní procesy (CAD, TIFF)? Jaké jsou předpoklady?

  • Workflow. V Oracle UCM rozeznáváme tři typy workflow: základní (uživatel je iniciátorem), kriterijní (proces se spustí automaticky na základě pravidel) a pod-workflow (rozdělení do logických celků). Jaké jsou ve společnosti toky dokumentů? Kdo je iniciuje? Jaká jsou pravidla pro spouštění? Pro každý workflow je třeba projít neschválení v každém review stepu. Očekává se paralelismus některých toků?

  • Položky metadat. Kromě vestavěných položek (content type, title, author, security group, primary file, content ID, revision, release date…) je možné (a typické pro DMS) rozšiřovat metadata o vlastní typy i položky. Podle čeho chce zákazník konkrétní typy dokumentů vyhledávat? Podle čeho kategorizovat? Jaké faktory hrají roli (demografické, typové, navigační)? Jaké položky jsou výčtového charakteru? Které položky závisí najiných (např. kraj-město)? Při návrhu je nutné jisté obezřetnosti – čím méně metadat máme, tím lépe. Každý nový typ nebo pole musí mít jasně opodstatněný (a zdokumentovaný) význam.

  • Zálohování. Je zálohování součástí dodávky? Jaká jsou očekávání pro zálohovací scénář? Jaká bude použita technologie a metodika (jak pro metadata, tak pro dokumenty samotné)? Využít vlastnost replikace na (geograficky) oddělené servery? Jaké budou scénáře pro obnovu dat? Jak se bude testovat?

  • Možnosti DMS jako archivu. ECM systém lze použít i jako jakýsi „archiv“ pro jiné systémy, jako je například SAP, ze kterých lze neaktuální data „odlévat“ a systému tak ulehčit. V ECM se tato data objeví včetně různých reportů a jiných dokumentů, které by firma mohla potřebovat. Jaké společnost používá jiné systémy? Jaké mají možnosti integrace z hlediska archivace jinam?
Vypracováno z těchto zdrojů:

Tento zápisek vznikl převodem z mého starého blogu. Ne všechny texty byly takto převedeny, kompletní archiv již není k dispozici.