Pieter Wisse
Kurt Wayenberg en Jelle Wolthuizen zijn beide business consultant bij EDS Nederland. Hoewel zij tussen hun klanten en de ontwikkelaars van EDS bemiddelen over àlle relevante informatietechnologieën, gaat hun bijzondere interesse uit naar objectoriëntatie. In een gevarieerd gesprek noemden zij daarvoor talloze vaktechnische èn commerciële argumenten.
Vanuit België kwam hij naar de Nederlandse vestiging van EDS, pas zo'n anderhalf jaar geleden. Kurt Wayenberg geloofde erin dat objectoriëntatie rijp was voor operationele toepassingen in handel en industrie. Dus niet alleen maar voor grafisch werk, simulaties en dergelijke.
Hij vormde een klein team dat een compleet logistiek informatiesysteem ontwikkelde. Waarom maatwerk? De populaire pakketten voor logistiek beheer bevatten onvoldoende functionaliteit voor de opdrachtgever in kwestie. Mede dankzij objectoriëntatie ontstond extra toegevoegde waarde volgens planning in korte tijd en met een bescheiden budget.
Mits de opdracht zich ervoor leent, realiseren minder ontwikkelaars in kortere tijd een robuuster informatiesysteem. Hierdoor zou een bedrijf als EDS met objectoriëntatie overigens in een dilemma terecht kunnen komen. Erodeert met objectoriëntatie, kortweg OO, niet de hogere omzet per opdracht die bij traditionelere aanpak hoort? Een positief antwoord op zo'n vraag is kortzichtig. Er is met OO immers allerlei nieuwe informatievoorziening mogelijk. Opdrachtgevers zullen zeker op wat langere termijn hun uitgaven zeker niet verlagen, maar willen juist de reikwijdte van informatievoorziening vergroten. Voor hetzelfde geld kan er met OO méér. Zodra duidelijk is dat het rendement ervan hoger is, stimuleert OO ongetwijfeld verdere groei van toepassing van informatietechnologie. Daarmee groeit ook de markt voor dienstverlening. Van kannibalisatie van eigen marktaandeel is geen sprake.
Objectoriëntatie verhoogt dus de kwaliteit van dienstverlening. Daarom kiest EDS er strategisch voor. Om het dilemma te vermijden, moet groei op korte en middellange termijn vooral gebeuren met nieuwe opdrachten van nieuwe klanten. Daarvoor krijgt OO bij EDS van het topmanagement onmiddellijk volop de ruimte. Een duidelijk voorbeeld is de zgn co-sourcing: Als partner beheert EDS de automatiseringsafdeling van een opdrachtgever. Daarbij verlangt de klant dat EDS zijn informatievoorziening kwalitatief op een hoger niveau brengt. Dat vergt meestal een omvangrijke transformatie waarin OO een belangrijke rol kan spelen. Want daarmee is het mogelijk om snel en selectief vervangende toepassingen te ontwikkelen, bepaalde bestaande toepassingen te integreren en/of om totaal nieuwe toepassingen toe te voegen.
Vooral als gevolg van enkele acquisities groeide het aantal medewerkers van EDS in Nederland in twee jaar van 380 naar 1400. De verwachting luidt dat binnen enkele jaren zo'n 125 ontwikkelaars bij EDS in Nederland met OO aan de slag zijn. Thans zijn dat er plusminus 25. Daarvan is al niemand (meer) betrokken bij experimenten, onderzoek e.d. Zij werken allemaal aan concrete opdrachten waarvan het resultaat een operationeel werkend informatiesysteem moet zijn. EDS heeft het verkennend stadium alweer enige tijd achter de rug; OO hoort gewoon in de omzetcijfers.
Wereldwijd telt EDS circa 84.000 medewerkers. De jaarlijkse omzet nadert twintig miljard gulden. Het bedrijf biedt diensten op een breed spectrum aan. Opdrachtgevers kunnen er aan de ene kant terecht voor advisering. En aan de andere kant van het spectrum voor uitbesteding van bedrijfsactiviteiten met een sterk informatieverwerkend karakter. Daartussen ligt alles wat met ontwikkeling en beheer van informatiesystemen te maken heeft.
Juist vanwege de enorme omvang is EDS vergaand gedecentraliseerd. Kleine groepen kunnen zeer onafhankelijk opereren. Daar hoort uitgesproken omzet- en resultaatverantwoordelijkheid bij. Tegelijk kenmerkt de bedrijfscultuur zich door veel onderlinge communicatie. Zo is ook voor objectoriëntatie een zgn technology policy ontstaan. Dat omvat concrete aanbevelingen voor de keuze van gereedschappen. De aangereikte beleidslijnen zijn trouwens niet verplicht. Dat past niet bij decentralisatie. Ze moeten daarentegen door redelijkheid overtuigen.
Eén van de aanbevolen gereedschappen voor objectoriëntatie is VisualWorks, met daarin begrepen de programmeertaal Smalltalk. Daarmee heeft Jelle Wolthuizen alweer ruime ervaring opgedaan. Achtereenvolgens al bij eerdere werkgevers zoals CVI nam hij initiatief tot OO-projecten met steeds een succesvol, operationeel informatiesysteem als resultaat. Het moet concreet zijn, en praktisch. Met meteen opbrengsten. Dat levert ook nogeens het breedste draagvlak voor nieuwe projecten volgens objectoriëntatie. Sinds de overname van CVI door EDS gaat hij er op die manier onverminderd mee door.
Met VisualWorks bouwde, zoals gezegd, EDS kort geleden op maat een logistiek informatiesysteem. In dat kader kwam echter een algemene doorbraak tot stand door de spreekwoordelijke muur tussen enerzijds het logische objectenmodel en bijbehorende informatieverwerking, anderzijds de fysieke informatie-opslag met een relationele database. Daarmee is de overgebleven bottle-neck voor praktische toepassing van OO verdwenen.
Nu biedt VisualWorks reeds een voorziening voor de vertaalslag van (objectgericht) verwerkingsmodel naar (relationeel) opslagmodel en terug. Klakkeloze toepassing van die zgn object lens verslechtert de prestatie echter dramatisch. Stel dat informatie uit opslag voor verwerking nodig is. Dat vereist allereerst volledige (re)constructie van het objectgerichte model vanuit de relationele tabellen. Dat kost domweg tijd. Wat EDS toevoegde, is selectiviteit. Dat komt erop neer dat (re)constructie beperkt blijft tot de informatie waaraan daadwerkelijk voor verwerking behoefte is. De naam voor dit mechanisme luidt: lazy instantiation. Alle overige, dus overbodige informatie blijft van vertaling verstoken.
Voor de vertaalslag in omgekeerde richting, dat wil zeggen van verwerkings- naar opslagmodel, borduurde EDS eveneens voort op de standaardklassenbibliotheek van VisualWorks. In dit geval heeft uitbreiding betrekking op mogelijkheden om de verdichting van verschillende objecten naar relationele tabellen op maat in te stellen. Dat is zoiets als tuning. Een relevante groepering van objecten voor fysieke opslag kan de prestatie van het informatiesysteem eveneens gunstig beïnvloeden. Onafhankelijkheid van het type relationele database is gewaarborgd, omdat de lensuitbreiding (ook) op ODBC gebaseerd is.
Zoveel aandacht voor de vertaalslag tussen objectgericht respectievelijk relationeel model is om diverse redenen noodzakelijk. Voorop staat dat relationele databases volwassen zijn. Voor objectgerichte opslag zijn de beheersystemen helaas nog niet zover. Dat objectbases voor bepaalde toepassingen beslissend prestatievoordeel bieden, tonen experimenten reeds aan. Maar voor operationeel gebruik in bedrijfsprocessen zijn andere aspecten ook relevant. Bijvoorbeeld, is de opgeslagen informatie adequaat beveiligd?
Voor fysieke opslag volgens relationele technologie pleit voorts dat daardoor gestandaardiseerde koppelingen met pakketten voor kantoorautomatisering (spread sheets, tekstverwerking e.d.) mogelijk zijn. Ook zijn dankzij relationele opslag rapportages eenvoudig realiseerbaar. Daarvoor hoeft informatie vaak niet eens terùg door de object lens; met inzicht in de relationele tabellen heeft directe toegang met SQL voor algemene rapportages zelfs de voorkeur.
Dit neemt allemaal niet weg dat toepassing van OO in combinatie met relationele opslag tijdelijk moet zijn. Om de vruchten van OO volledig te plukken zijn consequent functionerende objectbases onontbeerlijk.
Gelukkig gaat de ontwikkeling van OO-gereedschappen snel. In de pioniersprojecten van nog maar enkele jaren geleden moest de ontwikkelaar in Smalltalk nog zelf zoiets als een SQL-interface maken. Die is nu gewoon standaard, zoals ook een object lens alweer standaard is, zij het dus nog onvoldoende toegerust op operationeel aanvaardbare prestatie. Steeds minder eigen toevoegingen, zoals EDS deed met lazy instantiation, zijn nodig om in de praktijk succes met OO te boeken.
Ooit ontstond verschil tussen enerzijds administratieve informatievoorziening, anderzijds geautomatiseerde procesbesturing. Bij EDS staan deze deelgebieden bekend als transaction processing, respectievelijk high-tech oplossingen. Reden voor hun divergentie was de noodzaak voor afwijkende technologieën. Onder invloed van OO is convergentie mogelijk; met dezelfde technologie kan de ontwikkelaar systemen voor administratieve informatievoorziening èn procesbesturing ontwerpen en bouwen. Het valt te verwachten dat vervolgens ook het onderscheid tussen transactie- en procesgericht vervaagt. Dat sluit naadloos aan op een trend als business process re-engineering.
Zolang er gespecialiseerde ontwikkelaars zijn, verschilt hun optimale voorbereiding om produktief volgens OO te werken. Omdat high-tech oplossingen een fundamenteler model in termen van objecten vergen, duurt de voorbereiding voor zulke ontwikkelaars langer. Nadat zij/hij een mentor toegewezen gekregen heeft, brengt de aanstaande ontwikkelaar minstens twee maanden oefentijd door. Daarin zijn diverse cursussen gepland. Verder maakt zij/hij enkele werkstukken in de vorm van programmatuur. Gedurende deze periode is de medewerker nadrukkelijk niet-produktief. Dat komt in toenemende mate tijdens de volgende maanden. Daarin verleent de ontwikkelaar vooral hand-en-span diensten voor meer ervaren collega's. Na alles bijelkaar ongeveer zes maanden voorbereiding kan de ontwikkelaar zelfstandig functioneren.
Aan de kant van de transaction processing ontvangt de aanstaande ontwikkelaar allereerst enkele weken formele cursussen mèt gerichte training. Daarna volgt meteen produktief werk, zij het aan eenvoudige transacties. Met de overgang naar werk aan complexe transacties is daar de voorbereiding voltooid.
Aan interne kandidaten voor OO heeft EDS geen gebrek. Er is domweg geen probleem om mensen voor bijbehorende veranderingen te motiveren. Naast uiteraard een stevige basis met kennis en vaardigheden op het gebied van de informatica, moeten kandidaten vooral beschikken over abstractievermogen. Anders zijn ze niet in staat de omslag naar de objectgerichte denkwijze te maken. Het blijkt telkens weer dat juist de denkwijze zo ànders is dan waaraan traditionele ontwikkelaars gewend zijn. Daarom kost de omslag ook zoveel tijd en inspanningen. Van OO-medewerkers wordt tevens volharding verlangd. Zij werken immers niet slechts tijdens een bepaalde fase aan de realisatie; daarentegen doorloopt een ontwikkelaar de totale realisatiecyclus. Dit vereist open communicatie met haar/zijn collega's die voor andere delen van hetzelfde informatiesysteem eveneens de totale cyclus doorlopen. Daarom tellen contactuele vaardigheden zwaar, evenals het vermogen een echte teamspeler te zijn.
Een team dat volgens OO een informatiesysteem realiseert, moet klein zijn. Niet meer dan vijf mensen. Dat is vooral noodzakelijk om onderlinge communicatie te waarborgen. Met strikt gescheiden, achtereenvolgende fasen is communicatie nog formaliseerbaar. Met de nadruk op totale realisatiecyclus verdwijnt zulke formaliseerbaarheid. Dankzij informele, intensieve communicatie resulteert met OO een beter informatiesysteem. Dit geldt overigens niet alleen voor de onderlinge communicatie van de ontwikkelaars. Wezenlijk is de communicatie met de opdrachtgever. Dat is dankzij OO beter mogelijk tijdens de gehele cyclus, met alle voordelen voor de kwaliteit van het eindresultaat van dien.
Het is gelukkig ook haalbaar om zelfs complexe informatiesystemen met kleine teams te maken. Het geïntegreerde ontwikkelgeredschap werkt immers bevrijdend. Dat komt omdat voor allerlei aspecten (vrijwel) kant-en-klare voorzieningen bestaan. Neem bijvoorbeeld de grafische interface voor het beeldscherm. Het geestdodende werk kan de ontwikkelaar (grotendeels) overslaan. Dat betekent niet alleen enorme tijdwinst, maar bevordert haar/zijn motivatie. Zij/hij kan meteen aan werk voor wat telt als de toegevoegde waarde voor de opdrachtgever. Een typisch OO-project duurt eerder enkele maanden dan jaren. Een realisatiecyclus van drie tot zes maanden is heel normaal.
Juist OO levert een groot deel van het informatiesysteem dus kant-en-klaar. Dit verlaagt de drempel voor ontwikkelaar aanzienlijk om met haar/zijn specifieke aandeel eens helemaal opnieuw te beginnen. Toch blijkt dat een frisse start vaak per saldo tot een beter resultaat in kortere tijd leidt. De ruimte voor verbeterd ontwerp loont.
Wanneer, al dan niet na enkele pogingen van meet af aan, het basisontwerp stabiel is, ondersteunt OO bij uitstek verdere ontwikkeling op evolutionaire wijze. Het objectbegrip wijst vanzelf de weg naar afbakening van activiteiten. Zo kan de functionaliteit van een informatiesysteem geleidelijk groeien dankzij uitbreiding danwel toevoeging van objecten.
Zijn er dan helemaal geen obstakels voor toepassing van OO? Inderdaad kennen OO-gereedschappen nauwelijks meer intrinsieke beperkingen waardoor ze onderdoen voor andere informatietechnologieën voor systeemontwikkeling. Toch zijn er in de praktijk weleens redenen om aan OO voorbij te gaan of, tenminste, de keuze ervoor uit te stellen. Zo kan in een organisatie een oudere technologie gevestigd zijn die zich slecht met OO verhoudt. Denk bijvoorbeeld aan hiërarchische of netwerkdatabases. Omwille van continuïteit blijft zo'n andere technologie, met alles erop en erom, vaak de voorkeur genieten. Het is natuurlijk de vraag of een organisatie daarmee haar isolement niet versterkt. Een ander argument tegen OO betreft soms de kosten van hardware. Objectgerichte programmatuur vergt op de werkplek een stevige personal computer. Het lijkt er echter op dat zelfs de nieuwste besturingssystemen voor personal computers nog hogere eisen aan hardware stellen. Langs de weg van invoering van een nieuw besturingsprobleem verdwijnt dat obstakel binnen afzienbare tijd. Dan kost de ontwikkelprogrammatuur geld; VisualWorks is verhoudingsgewijs prijzig. Direct met geld hebben ook licentiekosten te maken. Wie programmatuur draait die met VisualWorks werd ontwikkeld, is voor het gebruik van een run-time versie van Smalltalk een bedrag aan de leverancier van dat ontwikkelgereedschap verschuldigd.
Inmiddels zijn er talloze aanbieders van OO-gereedschappen. Dat heeft betrekkelijk snel geleid tot inspanningen voor standaardisatie. Dat gaat onder de noemer van afkortingen zoals OMG, CORBA, SOM en DSOM. De resultaten daarvan zijn echter beperkt praktisch bruikbaar. Er zijn eigenlijk uitsluitend enkele standaards in het technisch vlak bereikt. Op logisch niveau is er geen eenduidigheid. Het resterende, maar verhoudigsgewijs enorme probleem laat zich toelichten aan de hand van het verschil tussen syntax en semantiek. Het is vrij simpel een zin te construeren die syntactisch correct is. Dat is echter allerminst een waarborg voor begrip van de zin. Daarvoor moeten deelnemers aan communicatie tevens op semantisch niveau relevante afspraken kennen. Dat is heel wat ingewikkelder. Ook voor OO moeten modellen zowel qua vorm als qua inhoud afgestemd zijn. Wat de inhoud (semantiek) betreft, ligt dat dus nog altijd moeilijk. Het is zelfs de vraag af zulke standaards praktisch mogelijk zijn.
Zulke afstemmingsproblemen zijn niet typisch voor OO. Zij gelden voor elke technologie. Bij keuze vóór of juist tégen OO zijn relatieve voor- en nadelen relevant. In hoog tempo ontwikkelt de verhouding zich ten gunste van OO. En ook de oorspronkelijke aarzeling die opdrachtgevers tegenover OO hadden, verdwijnt inmiddels snel.
Het is niet zo dat OO andere technologieën compleet zal verdringen. Het staat echter vast dat OO voor ontwikkeling en beheer van informatievoorziening een vooraanstaande positie verdient ... en op wat langere termijn beslist ook krijgt.
Het vraaggesprek voerde ik samen met Joop Kuijs, hoofdredacteur Informatie.
© 1993, webeditie 2002.
Sterk verkorte versie in: Informatie, jaargang
38, februari 1996.