Onder de loep: Java Enterprise Edition

Met de opkomst van de Java 2 Enterprise Edition (J2EE) van Sun is voor veel organisaties de vraag actueel of zij met deze architectuur aan het werk willen. Sommigen zullen misschien zelfs het gevoel hebben dat zij dat moeten, en dat er geen alternatieven zijn. De situatie voor veel organisaties is immers dat er telkens…

Met de opkomst van de Java 2 Enterprise Edition (J2EE) van Sun is voor veel organisaties de vraag actueel of zij met deze architectuur aan het werk willen. Sommigen zullen misschien zelfs het gevoel hebben dat zij dat moeten, en dat er geen alternatieven zijn.

De situatie voor veel organisaties is immers dat er telkens momenten aanbreken voor vernieuwing van bestaande systemen. De overwegingen die dan gemaakt moeten worden zijn niet altijd gebaseerd op concrete overwegingen en zijn vaak ook gevoelsmatig.

Wat zijn de concrete overwegingen?

  1. De ondersteuning voor bestaande technologie is te duur geworden.
  2. De bereidheid van het personeel om met de bestaande technologie te werken is aan het verminderen (ook een gevoelsmatig argument vanuit de medewerker bekeken maar zeker een concreet argument in termen van beschikbaarheid van personeel).
  3. De bestaande technologie is niet of te kostbaar in staat mee te gaan in veranderende eisen wat betreft functionaliteit en beschikbaarheid.
  4. Er is een wildgroei ontstaan van oplossingen die allemaal gebruik maken van verschillende technologische middelen, en vanuit beheersmatig oogpunt is deze situatie contraproductief geworden.

Vanuit beheersmatig perspectief zijn dit argumenten die niet altijd voldoende gevalideerd worden. Er is iemand die het roept, en het klinkt wel plausibel, en wanneer een guru in het veld ook zoiets roept is het al snel een waarheid gegoten in beton. De vraag stellen of het wel waar is wordt vaak zelfs niet gewaardeerd, en afgedaan als demotiverend. Wanneer een leidinggevende zijn positie dacht te versterken door de nieuwe tools te introduceren kan het stellen van de vraag zelfs nog vervelender consequenties hebben: de criticaster wordt uit de organisatie verwijderd!

Laten we echter uitgaan van een positief scenario en aannemen dat de organisatie tot de vernieuwende impuls is gekomen door een weldoordacht en beheerst proces. Wat zijn dan de gevolgen?

Er is als het ware een vacuüm ontstaan in de organisatie. De vraag is gesteld, het antwoord moet nog worden gevonden. Zodra bestaande IT bedrijven van dit vacuüm op de hoogte geraken moet de organisatie wel heel sterk in haar schoenen staan om de stortvloed van “deskundig” advies te doorstaan en daarbij de zinnen te bewaren. Consultants verschijnen uit alle hoeken en gaten, en wie daarbij in staat is als eerste een redelijk gedegen indruk te maken heeft het fundament gelegd voor een uiterst boeiend spel van veranderingsprocessen. Mensen met een andere boodschap worden niet echt gewaardeerd, men moet immers een keus maken, en telkens een andere weg inslaan zou nergens toe leiden. Kritiek in de beginfase is ook niet echt populair. De technische mensen raken er alleen maar van slag van, worstelend als zij zijn om nieuwe kennis te verwerken, en hun managers zijn niet in staat om de argumenten te beoordelen en denken alleen maar aan hoeveel het kost en hoe de overgang zo snel en goedkoop mogelijk te doen verlopen.

In dat vacuüm valt nu J2EE. Een technologie die nog steeds het aura om zich heen heeft van Java, namelijk het is nieuw, het is sexy, en vooral: het is cool. Ieder bedrijf wil wel iets meepikken van die uitstraling toch? Bovendien heeft het verhaal van J2EE een aantal onderdelen die verdomd interessant klinken: bestaande databases kunnen gewoon gebruikt worden, bonen op de server maken deze transparant beschikbaar in een multichannel omgeving: internet, WAP, voice-respons systemen. De leverancier van de applicatieservers leveren steeds meer ondersteuning voor andere “legacy” systemen als ERP en CRM systemen en de wereld voor een IT manager begint plotseling een stuk meer licht toe te laten.

Dat er aan het verhaal een aantal onderbelichte vraagstukken kleven is, zoals ik al zei, niet populair om te roepen. Wat zijn nu die onderbelichte vragen?

  1. Het is nieuwe technologie. Wat zijn hiervan de gevolgen voor stabiliteit, ondersteuning door tools, deskundigheid van de adviseurs?
  2. Het lijkt op wat we al deden, in feite kunnen we gewoon doorgaan met wat we al deden. Dat klinkt aantrekkelijk maar is het dat wel? Wat waren de oorzaken van problemen in het verleden? Zijn deze oorzaken nu echt verdwenen door het sexy aura van Java?
  3. De manier van toepassen van nieuwe technologie en tools is in het verleden altijd iets dat jaren nodig had om de heuristiek te ontwikkelen voor efficiënte toepassing. Deze heuristiek is er nu (nog) niet.
  4. We passen de nieuwe tools toe door zoveel mogelijk te doen wat we al deden en het aan de leverancier van de tools over te laten de voordelen van de technologie transparant voor ons beschikbaar te stellen. Is dit wel de manier om nieuwe mogelijkheden te benutten?
  5. Zijn de belangen van leveranciers in deze niet strijdig met die van de afnemers en maken we ons op die manier niet alleen maar nog meer afhankelijk van die leveranciers?
  6. Zijn er ook alternatieven, en in hoeverre sluiten die aan op J2EE?

Het stellen van vragen is iets dat we op school geleerd hebben als een belangrijke vaardigheid, laten we bij het toepassen van nieuwe technologieën hiermee vooral doorgaan.

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *