Domino weblog

Meerdere tiers
Het eerste wat opvalt, is dat je bij Portal te maken hebt met een multi-tier omgeving. Domino doet alles op één server: adresboek, data, applicatie-ontwerp, mail enzovoorts. In een portal-omgeving is dat meestal verspreid over meerdere machines: natuurlijk de portal-server zelf, maar ook een LDAP-server, een relationele database-omgeving, een SMTP-server en waarschijnlijk ook nog data afkomstig van andere applicaties of servers. Onder zulke omstandigheden moet je eigenlijk ook het netwerk en de hardware gaan noemen, dat worden aparte factoren van belang.

..Dus ook meer mensen..
Dat betekent dat je, vergeleken met een doorsnee Domino-omgeving, ook te maken hebt met meer mensen. Iemand is verantwoordelijk voor LDAP; iemand anders voor de database-omgeving; een ander gaat weer over de SMTP-servers; dan heb je nog de netwerkbeheerders, de hardware-mannen enzovoorts. Al die mensen (of afdelingen), en nog meer, heb je vroeger of later nodig. Ze moeten accounts voor je maken, machines opleveren, databases maken, firewalls openzetten, gegevens aanleveren, dingen voor je regelen...

..En meer tijd.
Dit alles kost tijd. Meer coördinatie, meer overhead, meer vergaderingen en overlegmomenten. Al de betrokken beheerders hebben hun eigen verantwoordelijkheden en (change management-) procedures waar ze zich aan moeten houden; ze hebben hun eigen prioriteiten. Vermoedelijk zijn er méér mensen die om hun aandacht vragen, je kunt er niet vanuit gaan dat die mensen allemaal dedicated voor je klaarstaan. Er kan ook nog eens sprake zijn van strijdige belangen en prioriteiten, dat maakt het allemaal niet eenvoudiger.

"Even gauw" iets regelen, dat lukt lang niet altijd! Zelfs al willen alle betrokkenen je zo goed mogelijk helpen: reken erop dat dingen die heel triviaal lijken, toch veel tijd kunnen kosten. Leer dus geduld oefenen, berusting, bezit je ziel in lijdzaamheid, ga mediteren, schrijf haiku's..

De Domino-cowboys
Hoewel dit alles bij een Domino-project ook kan spelen, is het risico hierop toch veel kleiner. Je hebt als Domino-beheerder bijna alle 'tiers' bij elkaar op één doos; over het algemeen kun je daardoor sneller schakelen. Voor mensen die dat niet gewend zijn, kan het daarom soms lijken of die Domino-beheerders als een soort 'cowboys' hun beheer doen: ze handelen soms sneller dan de organisatie gewend is.

Domino, onzichtbaar?
Daar komt bij, dat mensen uit andere delen van de (beheer-) organisatie niet altijd evenveel inzicht hebben op wat er op een Domino-omgeving gebeurt. Omdat er minder mensen bij betrokken zijn, is die kennis-verspreiding ook kleiner. Een belangrijk nadeel daarvan is, dat Domino min of meer 'onzichtbaar' kan worden in een (ICT-) organisatie. Het is dan ook belangrijk dat je, als Domino-mensen, ervoor zorgt dat het management goed doordrongen is van de nuttige dingen die Domino allemaal voor uw organisatie doet..of kan gaan doen.

UI
Domino regelt, zoals hierboven al aangegeven, veel zaken op één machine of omgeving. Dat betekent dat bijna alle configuratie gedaan kan worden in de Domino Directory, met wat extra mogelijkheden in de notes.ini. En logging, dat staat in log.nsf.

In Portal gaat het anders. Er is een overvloed aan xml- en properties-files, waarin van alles geconfigureerd kan of moet worden. Die properties zitten soms ook verstopt in jar-files, zodat je eigenlijk WinRAR nodig hebt om makkelijk overal bij te komen.

Voor veel zaken is een UI-equivalent te vinden in de WebSphere Application Server Administration console (meestal terug te vinden op http://localhost:9090/admin, als je server1 hebt draaien); veel Portal-specifieke zaken regel je meestal wel rechtstreeks in de Portal Administration interface. Maar, je ontkomt er niet aan dingen in files op het filesysteem te configureren. Leuk als je op Unix of Linux draait, dan heb je wel wat vi-vaardigheden nodig! Er zijn tenslotte nog allerlei batch-files meegeleverd met Portal, die allerlei zaken voor je kunnen configureren. Die hebben allemaal weer hun eigen syntax en parameters; dat ga je niet allemaal onthouden.

En logging? Dat kan op meerdere plekken staan: D:\WebSphere\AppServer\logs, of D:\WebSphere\PortalServer\logs; dan kan het in systemerr.log staan, of in systemout.log, of in wps.log, of...

Daarmee is het voor Domino-beheerders lastiger om je weg te vinden dan je wellicht gewend bent. Er zijn meerdere plaatsen om zaken te regelen en te controleren; het kost tijd om uit te zoeken waar precies wat staat. En: één typefoutje kan je met de handen in het haar brengen! Eén typefoutje in zo'n XML-file kan je complete portal te gronde richten.. toegegeven, dat kan met Domino ook, maar het risico is wat kleiner.

Documentatie, google..
Met portal werken zonder documentatie is mede door wat ik hierboven schreef, feitelijk niet te doen. De Information centers zijn onmisbaar; net zoals de Lotus Knowledgebase, en google.

Structuur!
Het betekent ook dat je veel gestructureerder moet werken. Kun je, zeker als ervaren beheerder, bij Domino min of meer 'uit de losse pols' werken voor veel dagelijkse werkzaamheden: doe het in Portal maar niet! Je werkt aan de hand van de procedures die IBM gedocumenteerd hebt, en die volg je, stap voor stap. Ook de ervaren WAS-mannen en portelaars werken zo, heb ik gemerkt. Want je mist zo makkelijk één setting, één vinkje, één configuratie in een properties file, één stap van de vele. En dan werkt het niet. Dus: bereid je voor, lees je documentatie voor zover mogelijk, bepaal je procedure en hou je daaraan.

Voorbereiden: ook de andere tiers
Dat heeft dus ook betrekking op de andere tiers: database, directory enzovoorts. Je kunt er niet vanuit gaan dat alles wel goed geregeld zal zijn. Portal vraagt soms om dingen die men niet gewend is; en uitzoeken daarvan en (achteraf) regelen kan veel extra tijd kosten. Opnieuw geldt hier: lees de documentatie, bereid je voor, deel de nodige documentatie met andere betrokkenen en controleer (of liever, laat controleren) of aan alle noodzakelijke randvoorwaarden voldaan is.

Lotus Collaborative components
Ach, even Sametime en QuickPlace in een portal hangen.. het is Lotus-techologie, dat ken je allemaal, dus wat kan je gebeuren! Nou.. best veel. Opnieuw, je hebt te maken met meerdere machines, netwerk en firewalls, configuratie-bestanden op de Portal-server. Je hebt te maken met SSO-issues, LTPA-configuraties, LDAP-schema's die moeten matchen, versie-gevoeligheden enzovoorts. Opnieuw: de Lotus Knowledge Base is je vriend, want uit je hoofd wordt het allemaal erg lastig. Verkijk je daar dus niet op; het kan wel allemaal Lotus zijn, maar dat betekent niet dat het net zo eenvoudig is als Domino-beheer.

Zomaar wat impressies die ik hier opgedaan heb. Herkenbaar? Leerzaam? Ik hoor het graag!