Domino weblog

Category WebSphere
Bookmark :              

Op IBM Developerworks WebSphere loopt al een tijdje een serie over "Creating a new portal". Recent las ik een stuk van aflevering 6: "Administering and maintaining the portal."

Dit zesde deel gaat vooral over de organisatorische kant van de zaak. Welke soort mensen heb je nodig, welke rollen zijn er allemaal, wat moeten ze kunnen? Wat moet de organisatie willen, weten en kunnen voordat je met succes een portal-traject in kunt gaan? Aan welke voorwaarden moet worden voldaan? Een heel pakket aan voorwaardes en omschrijvingen passeert de revue, waarbij vooral deze mij opviel, over de bemanning van een "project office":

"Don’t kid yourself; you need people who understand organizational change to pull off a portal project. Let me make it clear: software developers won’t cut it for this, and neither will software development managers. You need a very specific type of person for this task-- the type that can get around oceans of people and meetings ad nauseam. Look into the ranks of the program and project managers or the change management consultants to staff the project office."

Soms is het als techneut wel eens goed, als iemand je vertelt dat je ook andere mensen nodig hebt om een groter traject af te ronden. Met techniek alleen redt je het niet! En ook niet met technici. De schrijvers zijn eerlijk: je hebt mensen nodig, die eindeloos kunnen praten en vergaderen. Reken vooral ook op een hoop extra 'red tape': stapels papier en bureaucratie dus. Dat is allemaal onderdeel van dit soort grote trajecten bij grote bedrijven. Er ligt wel een relatie tussen de grootte van het bedrijf en de mate waarin dit alles een rol speelt. Over grotere bedrijven zeggen ze:

"it means more red tape and stricter procedures to achieve similar goals (compared to a smaller team with a less complex installation). When defining your portal governance direction, be realistic in your expectations. Do not expect to get something in place within a few days or weeks, when you know it might take months to get agreement from all parties involved in some processes."

Bij een klant van me vertelde een collega-beheerder me laatst een anekdote die daar goed bij aansluit. Een grote klant vroeg hem: hoeveel tijd kost het om WebSphere Portal Server te installeren? De eerste inschatting: 10 dagen. Mijn collega dacht het ruim genomen te hebben: installatie van WPS duurt niet zo lang, maar even de mensen leren kennen, machines regelen, netwerk in orde maken, database organiseren, rekening houden met vertragingen hier en daar.. dat kost wel tien dagen. Bij de eerste besprekingen met de klant bleek dat hij ook overleggen en vergaderingen moest gaan doen met allerlei betrokkenen, en al gauw werd de eerste inschatting van 10 dagen, op advies van de klant zelf, bijgesteld naar 40. Om een lang verhaal kort te maken: het heeft uiteindelijk anderhalf jaar geduurd voordat de Portal in productie ging.

In de Lotus-wereld kennen we dit soort trajecten, op WPS na, eigenlijk niet. Toch denk ik dat we, als je verder kijkt dan alléén Notes/Domino, er rekening mee moet houden, dat je vaker met complexere omgevingen en installaties te maken gaan krijgen. WebSphere, DB2 of Oracle, Apache of IHS en dergelijke: we gaan het vaker zien. Lotus Connections is WebSphere-gebaseerd; Quickr kan op Domino maar ook op WebSphere, de Sametime Gateway draait op WebSphere. Dat heeft dus applicatieservers, webservers, database-servers en ldap-servers nodig - plus Domino, voor sommige features. Je hebt het dan nog lang niet overde complexiteit van Portal, waarbij je vaak met meerdere backends te maken hebt die allemaal mee moeten werken aan het Portal-traject! Maar je krijgt mogelijk wel te maken met verschillende beheer-groepen, competenties, afdelingen en dergelijke. Meer overleg, meer red tape. Voor op IBM Lotus gerichte ontwikkelaars maar met name ook beheerders, zeker iets om rekening mee te houden.