Ud af Lotus Notes – vores erfaringer
I mange virksomheder bliver ældre Lotus Notes-applikationer ikke lukket endeligt ned, selvom de er blevet erstattet af nye applikationer. Usikkerhed om, hvordan den information, der er gemt i applikationen, skal håndteres, afholder nemlig virksomhederne fra at tage skridtet fuldt ud. Dette medfører såvel compliance-udfordringer som licensomkostninger. I denne artikel beskriver vi nogle af vores erfaringer med nedlukning af Lotus Notes.
Domino og Lotus Notes er en teknologi og platform, som har tjent – og stadig tjener – mange virksomheder godt. Ikke desto mindre har mange de senere år erstattet Lotus Notes-applikationer med andre platforme og applikationer. En endelig udfasning af Domino/Lotus Notes besværes dog af, at de gamle applikationer ikke lukkes endeligt ned, men i stedet holdes i live for at bevare informationen i dem.
Eftersom Domino/Lotus Notes-platformen er særdeles fleksibel, har virksomhederne fået bygget applikationer til mange anvendelser og ofte i stort antal. Som følge heraf er applikationerne vidt forskellige og ofte ikke særligt veldokumenterede. Informationen, lagret i applikationerne, er derfor også organiseret vidt forskelligt, og ofte drejer det sig om meget store, inhomogene mængder. Både de store mængder, forskelligheden og den manglende dokumentation komplicerer arbejdet med at overskue informationsmængden og med at udtrække den på hensigtsmæssig vis.
Lotus Notes besidder nogle tekniske træk, som gør platformen særligt fleksibel og bredt anvendelig. Imidlertid gør de samme træk det kompliceret at overskue informationen lagret i applikationen. I det følgende beskrives to af disse træk: Lotus Notes-dokumenter og Lotus Notes’ view-struktur.
Lotus Notes-dokumenter
De fleste forbinder ordet ”dokument” med en fil indeholdende information. Det kunne være en Word-fil, en PDF-fil, en regnearks-fil, en billedfil osv. Men et Lotus Notes-dokument er ikke en fil, men ligner på væsentlige punkter en e-mail. Ligesom en e-mail har et Lotus Notes dokument et body-felt med tekst i og muligheden for vedhæftning af filer.
Teksten i body-feltet er i sig selv information, som typisk vil skulle bevares. Teksten stammer ikke fra en fil, som åbnes og vises af en applikation, således som Word åbner og viser en Word-fil. Teksten stammer derimod fra et Rich Text-felt i Lotus Notes-databasen. Skal teksten bevares et andet sted uden for databasen, skal det bevares som en fil, der ved åbning viser præcis det, man ville have set, hvis Lotus Notes databasen stadig fandtes og viste denne information. Der er forskellige tilgange til at løse det problem, og en ofte brugt metode er at danne PDF-filer ved hjælp af en til formålet leaset eller købt teknologi. En konvertering, som dette jo er, udfordrer dokumentets integritet, idet det er selve indholdet, der behandles. Konverteringen skal derfor foregå i en kontrolleret og dokumenteret proces. (Læs evt. mere om dokumenters integritet her).
Teksten fra body-feltet i Lotus Notes kan bevares ved at danne PDF-filer i en konvertering, som foregår i en kontrolleret og dokumenteret proces.
De eventuelle vedhæftede filer er jo allerede filer, men for dem kan konvertering til PDF være relevant, hvis de er i et format, som ikke har en holdbarhed, der svarer til den horisont, filerne skal bevares i.
Her forudsættes helt grundlæggende, at PDF er et godt valg. Det er det også ofte. PDF findes imidlertid i mange typer og versioner, og i hver enkelt situation må det nøje overvejes, hvilken type og version der er bedst egnet. Nogle gange er PDF ikke det rigtige valg. Sagt meget firkantet skal det valgte format være holdbart lige så længe, som dokumentet skal bevares. (Dette involverer så mange væsentlige overvejelser, at det må behandles i en separat artikel.)
Vedhæftede filer udgør dog også en anden type udfordring, idet det meget ofte vil være relevant at bevare filernes relation til den tekst, de var vedhæftet. Dette har Strator medvirket til at løse for såvel e-mails som Lotus Notes-dokumenter. Det er blevet løst på forskellige måder afhængigt af, hvordan dokumenterne fremover skulle bruges, hvor de skulle opbevares, og hvilken eventuel funktionalitet til at angive relationer, der heri måtte være til rådighed.
Lotus Notes-applikationers view-struktur
Med god grund kaldes mange Lotus Notes-applikationer i daglig tale for ”databaser” i virksomhederne. Stærkt forenklet er mange Lotus Notes-applikationer ”bare” forskellige visninger af data fra Lotus Notes-databasen.
Disse views, som det hedder i database-sprog, er grundlæggende en velformateret visning af resultatet af en søgning på angivne kriterier. Viewet viser således de til enhver tid eksisterende dokumenter, som opfylder kriterierne. Disse kriterier baserer sig på metadata om dokumenterne i Lotus Notes-databasen.
Det betyder, at Lotus Notes applikationer, teknisk beskrevet, er en veltilrettelagt samling af dokumenter med metadata, som på sirlig vis er kædet sammen med views således, at de forskellige views viser forskellige delmængder af dokumenterne med forskellig forretningsmæssig relevans.
Lotus Notes-applikationer er teknisk beskrevet en veltilrettelagt samling af dokumenter med metadata, som på sirlig vis er kædet sammen med views således, at de forskellige views viser forskellige delmængder af dokumenterne med forskellig forretningsmæssig relevans.
De fleste dokumenthåndterings- og arkivsystemer har en arkitektur, i hvilken hver delmængde af dokumenter tildeles en dokumenttype, som afgør, hvilket sæt af metadata der er på dokumentet. I princippet har samtlige af disse metadata således relevans for dokumentet og for dets visning og øvrige brug i systemet.
Sådan har de Lotus Notes-applikationer, Strator har medvirket til at nedlægge, ikke været, om end der ikke burde være noget teknisk til hinder for det. Måske har der været en anden tradition og et mindre fokus på de informationsvidenskabelige dyder, end der er ved den typiske implementering af dokumenthåndteringssystemer.
Lotus Notes-applikationerne er således blevet grundlæggende anderledes derved, at alle metadatafelter eksisterer på alle dokumenter. Hvorvidt felterne er udfyldt og benyttes, afhænger af, hvilke views de indgår i. I praksis ses, at metadata, der i princippet repræsenterer det samme forretningsmæssigt, optræder på to forskellige måder i to forskellige felter afhængigt af, hvad to forskellige views forudsætter. (Eksempel: Et metadatafelt hedder Måned og har værdien ”Juli”, og et andet metadatafelt hedder Månedsnummer og har værdien ”7” – men begge dele repræsenterer det samme, nemlig juli måned.)
Fordi brugen af applikationen over tid typisk har ændret sig, og nye views og metadata derfor er lagt til senere (eller pga. dårlig arkitektur allerede fra starten), ser man ofte nogle uoverensstemmelser i disse metadata stammende fra inkonsistens i applikationens struktur. (I eksemplet: Et dokument har Måned ”Juli”, men Månedsnummer er ”4” eller mangler.)
Hvis de forskellige metadata og logikken i views er veldokumenteret, er det relativt enkelt at få indsigt i informationen i applikationen og udpege de centrale views samt metadata pr. delmængde af dokumenter. Hvis dette mangler, er det heldigvis muligt at analysere konfigurationen af applikationen og udlede centrale dele af logikken, men som det fremgår af forklaringen ovenfor, kan analysen være kompliceret og efterlade nogle tvivlsspørgsmål. Det værste, der kan ske, er, at dokumenter mistes i forbindelse med, at en applikation nedlukkes. Derfor er det et ufravigeligt krav, at alle dokumenter kommer med (eller at der er taget aktivt stilling til, at visse ikke skal med). Faren ved denne type af opgaver er altid, at man ved, hvad man ser – men man ved ikke, hvad man ikke ser.
Faren ved ekstraktion af dokumenter i forbindelse med nedlukning er altid, at man ved, hvad man ser – men man ved ikke, hvad man ikke ser.
De forskellige views viser delmængder af dokumenterne. Det er som allerede fortalt ovenfor kriterierne i et view, der er afgørende for, hvilke dokumenter der vises. Men dertil kommer, at adgangsbegrænsninger også vil indvirke på, hvorvidt et dokument vises eller ej.
For at sikre at man forholder sig til alle dokumenter i databasen, er det derfor aldeles nødvendigt at komme ”om bag ved” både views og adgangsbegrænsninger. Det, der således kan ses, skal sammenholdes med, hvad der vises i de forskellige views. Der kan være dokumenter med inkonsistente metadata, som i eksemplet ovenfor, og der kan også være dokumenter, der ikke vises i noget view og derfor er helt usynlige for brugerne. Det er muligt, at disse blot skal kasseres, men det må i hvert fald ikke finde sted i uvidenhed om deres eksistens.
Lotus Notes-applikationernes struktur kan således gøre det lidt komplekst at danne et overblik over indholdet og hvilke metadata, der er centrale for hvert dokument. Det kan efter Strators erfaring klares relativt smertefrit ved at analysere grundigt og tilgå det meget struktureret.
Oprydning og arkivering
Applikationer, der som den typiske Lotus Notes applikation har haft et langt liv, vil ofte have en stor og inhomogen mængde dokumenter. Det skal altid overvejes hvor, hvor længe og i hvilket format dokumenter skal gemmes. Enkelte af disse overvejelser er allerede berørt ovenfor.
Det er imidlertid også væsentligt at overveje, hvad der skal gemmes. Det er muligt at udtrække og gemme alt, men der er situationer, hvor det er bedre at rydde mere eller mindre grundigt op.
Der kan være dele af dokumenterne, som skal over i et fungerende system, hvor det skal spille en aktiv rolle for brugerne. For disse dokumenter er det værdifuldt at rydde grundigt op og tildele gode metadata i forbindelse med migreringen til det nye system.
Skal dokumenterne arkiveres uden for aktiv brug, bør det overvejes, om der er dokumenter, som ikke må opbevares længere (fx pga. GDPR), og i givet fald må der gøres en indsats for at identificere dem, så de kan blive kasseret. Derudover er det faktorer som overblik over bevaringstid og genfinding, der kan afgøre, hvilken oprydnings-indsats der er passende.
Ud af Lotus Notes
Det sker, at legacy-applikationer ikke bliver endeligt nedlagt, selvom de ikke benyttes længere. Det synes at være et særligt udbredt fænomen for applikationer på lige præcis Domino/Lotus Notes-platformen. I artiklen har vi berørt nogle særlige forhold, der gør sig gældende for Lotus Notes-applikationer – dels dokument-begrebet og dels view-strukturen. I Strator tror vi, at disse kan være medvirkende årsager, idet de komplicerer ekstraktion og fortsat bevaring af dokumenterne.
Men kender man til og forholder sig til disse forhold, kan det sagtens lade sig gøre på fuldt forsvarlig vis og med en rimelig indsats at få lukket platformen endeligt ned og derved overkomme compliance-udfordringer og eliminere licensomkostninger.
God arbejdslyst.
