Tijdens Software Automation staat het ontwikkelen van applicaties met behulp van componenten in het middelpunt van de belangstelling. Twee gerenommeerde deskundigen, Ron Tolido, manager Technology Consulting bij Cap Gemini en Jacques Vandenbulcke, hoogleraar aan het departement Toegepaste Economische Wetenschappen van de KU Leuven, zijn uitgenodigd om hun visie te geven op het onderwerp. In een tweespraak laten zij verkennen zij de thema’s die de gemoederen in de wereld van de componentware bezig houden.
Vandenbulcke: "Het bedrijf van de toekomst is vooral een wendbare organisatie. Bedrijven moeten oppassen straks de gevangene te zijn van hun al te starre informatiesystemen. Maatwerksoftware noch (monolitische) pakketten zijn geschikt om de informatiesystemen snel aan te passen aan de veranderende eisen van de markt. Componentensoftware houdt het midden tussen maatwerk- en standaardsoftware en heeft de voordelen van beide in zich, zonder de nadelen mee te sleuren. Door middel van geprefabriceerde standaardcomponenten kun je oplossingen assembleren op maat van een organisatie. Door hergebruik kan een IT-afdeling snel inspelen op de ‘instant’ behoeften van een organisatie.
Tolido: "Het denken in modulaire componenten is een klassieker op het gebied van software engineering. Het streven naar hergebruik ook. Anno 1998 is de roep om flexibele, snel aanpasbare en uitbreidbare systemen groter dan ooit en is het hard nodig om echte productiviteitssprongen te maken. In de complexe wereld van Internet en gedistribueerde verwerking kun je dan niet om componenten heen. Geen componenten echter zonder standaards. Niet iedereen in de componentenwereld geeft het graag toe, maar de echte doorbraak is begin jaren negentig in gang gezet door Microsoft. Terwijl de rest van de wereld zich bezighield met de complexe theorie van objectoriëntatie bracht Microsoft Visual Basic uit; een taal die door de ‘kenners’ honend opzij werd geschoven omdat zij op een taal voor beginners, Basic, was gebaseerd en bovendien niet volledig objectgeoriënteerd was. Het hoongelach verdween toen bleek dat er een enorme, wereldwijde markt ontstond van ‘Visual Basic Custom Controls’ (VBX), in feite de voorlopers van de huidige ActiveX-componenten van Microsoft. Deze VBX-componenten blijken zeer eenvoudig in gebruik, zijn goedkoop en leveren enorme productiviteitsverbeteringen op. Microsoft heeft zo een standaard neergezet. De ‘anti Microsoft’-gemeenschap zet met JavaBeans – wel een beetje laat – de tegenaanval in. Maar de basisconcepten blijven hetzelfde."
Is ‘component’ eigenlijk niet gewoon een nieuw woord voor ‘object’? Of is een component eigenlijk zelfs gewoon maar een verzameling functies?
Vandenbulcke: "Een component is absoluut niet gelijk aan object. Het woord component wordt vaak misbruikt. Er bestaat hierover veel verwarring. Een component is een autonoom afleverbare pakket van diensten, die al dan niet kan zijn geconcipieerd met het oog op hergebruik. Een component bestaat uit een verzameling van één of meer objecten met variabelen en methoden, en duidelijke interfaces om eenduidig de functionaliteit aan te roepen."
Tolido: "De algemeen gangbare definitie van een component is: een coherente verzameling van data en bijbehorende operaties, van buitenaf in te stellen en aan te roepen, eenvoudig te combineren met andere componenten en aanpasbaar door het inpluggen van andere componenten of het invullen van triggers die door de componenten worden geactiveerd. Een component is, algemeen gesteld, simpeler en platter dan een object. Een component kun je visueel oppakken en manipuleren in Visual Basic, Delphi of VisualAge voor Java. Als er al moet worden geprogrammeerd, dan gebeurt dat met een eenvoudige scripting-taal of 4GL, vooral bedoeld als glueware, de lijm om de verschillende componenten met elkaar te combineren. Objectoriëntatie heb je eigenlijk alleen nodig het voor het bouwen van (complexe, high-performing) componenten, niet voor het gebruik ervan. Ik denk dat er veel meer ontwikkelaars zijn die componenten gebruiken dan zelf bouwen. Dat geeft dan gelijk het relatieve belang aan van ‘echte’ OO-programmeertalen als C++ en Java. Zelfs hardcore OO-adepten geven steeds meer toe dat de complexe structureringsprincipes van OO vaak alleen maar averechts werken en dat de plattere manier van het werken met componenten veel effectiever is."
Wat zijn de voordelen van het werken met componenten voor de systeemontwikkelaar? Vergt het een andere werkwijze? Zijn er ook voordelen voor de gebruiker?
Vandenbulcke: "Voor de ontwikkelaar is het een voordeel dat hij zich volledig kan toeleggen op het inrichten van de specifieke functionaliteit van het IT-systeem. Hij kan daarvoor immers gebruik maken van de specificaties of code, die door anderen zijn geschreven. Deze manier van werken stelt natuurlijk wel een aantal eisen. We moeten leren ontwikkelen met het oog op hergebruik en door middel van hergebruik van componenten. Anders gezegd: ervan uitgaande dat componenten kunnen worden hergebruikt, zullen we ze ook als zodanig moeten kunnen identificeren. Organisaties zouden hiertoe hergebruikteams moeten inschakelen.
Het ontwikkelen door middel van componenten heeft nog heel wat andere effecten op ontwikkelaars. Wat te denken van het documenteren, testen en certificeren van componenten en het vraagstuk van het intellectuele eigendom. Het begroten van zowel tijd als kosten voor het ontwikkelen van componenten vergt een heel andere methode dan we gewend zijn. Hetzelfde geldt voor het evalueren van de prestaties van de ontwikkelaars. Het voordeel voor de gebruikers ligt erin dat zij sneller betere en flexibeler systemen tot hun beschikking krijgen."
Tolido: "De voordelen voor de ontwikkelaar zitten in een sterk verhoogde productiviteit: je hoeft niet voor de zoveelste keer het wiel opnieuw uit te vinden. Je hebt daarentegen een vliegende start, want je bent meer bezig met het samenvoegen, uitbreiden en aanpassen op basis van componenten. Componenten werken bovendien normstellend: ze geven de contouren van de oplossingsrichting, zodat daarover niet meer hoeft te worden gediscussieerd. Ontwikkelaars die wel eens met componenten werken, hebben gemerkt dat ze voor relatief weinig geld de beschikking krijgen over software die ze zelf nooit zo goed, en zeker niet zo goedkoop en snel, hadden kunnen ontwikkelen. Overigens moeten ontwikkelaars wel leren producten van anderen te gebruiken. Het ’tandarts-effect’ ligt hier op de loer: wanneer je overstapt naar een andere tandarts, dan vraagt deze per definitie welke prutser voor hem aan het werk is geweest.
De gebruikers kunnen aan de buitenkant niet zien dat ze met een op componenten gebaseerd systeem te maken hebben. Dat het prettig is betere systemen sneller opgeleverd te krijgen, lijkt me een open deur. Interessant is wel dat het werken met frameworks van componenten invloed heeft op de communicatie tussen de IT-afdeling en de gebruikersorganisatie. Het framework bevat immers al de contouren van de uiteindelijke oplossing en is daarmee vanaf het begin van het project tastbaar aanwezig. Dat is overigens ook een voorwaarde om de voordelen van de componenten optimaal te benutten. Nog al te vaak wordt in eerste instantie het ideale systeem verzonnen om pas later te kijken of er componenten zijn waarmee het systeem gebouwd kan worden. Dat is zonde van de tijd.
Wat zijn de dominante leveranciers? De traditionele 4GL-leveranciers, of komen er hele nieuwe spelers op?
Vandenbulcke: "Ik maak onderscheid tussen modelleringstools en ontwikkeltools. Enkele modelleringstools zijn Rational, Select, Paradigm Plus en Object Team. IBM. Microsoft, Javasoft, Compuware, USoft, Platinum, Software AG, Forte, Sterling Software zijn voorbeelden van leveranciers die ontwikkeltools leveren. Daarnaast komen er nieuwe spelers op deze markt, zoals Software AG met Bolero. Dan zijn er bedrijven die met behulp van deze modellerings- en ontwikkeltools componenten bouwen. Daarvan bestaat inmiddels een aanzienlijke lijst. Voorbeelden zijn IBM met zijn partners in het kader van het San Francisco Framework, EDS, Andersen Consulting, Case Consult, Business Architects International en CMG.
Tolido: "Je moet een onderscheid maken tussen tools waarmee je componenten bouwt en tools waarmee je componenten gebruikt. Ik ben geneigd de 4GL-leveranciers vooral in die tweede categorie, gebruik, te positioneren. Ik zie vooral een positie weggelegd voor open producten waarmee je makkelijk componenten van anderen kunt integreren en beheren. Met de visuele tools van leveranciers als Microsoft, Inprise (Delphi, Jbuilder) en IBM (VisualAge voor Java) kun je heel snel met Activex- of JavaBeans-componenten aansprekende resultaten bereiken. Ook op het gebied van serieuze, bedrijfskritische toepassingen. De traditionele 4GL-leveranciers zoals Compuware en Oracle hebben nog wat werk te doen om hun producten aan te passen. Ze moeten concurreren met nieuwe spelers als NatSystems en Forté. Voor het bouwen van componenten kwalificeren zich in principe heel veel tools. Er is in ieder geval ook plaats voor 3GL’s en OO-programmeertalen zoals C++ en Java. Een hele interessante, nog wat onderbelichte markt wordt gevormd door de hulpmiddelen voor het ‘componentiseren’ van legacy-applicaties: het bouwen van component-interfaces om bestaande, inflexibele systemen heen. Ga er maar vanuit dat vooral de grote pakketleveranciers, zoals Baan, SAP en Peoplesoft, hun producten steeds meer in de vorm van frameworks van componenten gaan aanleveren.
Er lijken zich twee componentenstandaards af te tekenen: die van Microsoft (ActiveX/Com) en die van ‘de rest van de wereld’ – IBM, Sun, Oracle – (JavaBeans). Welke standaard is de beste? Welke gaat winnen?
Vandenbulcke: "Het zijn onbelangrijke vragen. Componenten moeten geschikt gemaakt worden om met de middleware uit de voeten te kunnen. Het betekent dat de interfacecode moet kunnen worden gegenereerd om de componenten te laten werken in, zowel in een Dcom-omgeving als een omgeving waarin bijvoorbeeld een Corba-implementatie wordt gebruikt. Dergelijke producten zijn overigens nu reeds op de markt."
Tolido: "De discussie is niet zo vreselijk cruciaal. Wel moet men een standaard kiezen als lijmmiddel om alle componenten met elkaar te laten communiceren. Het antwoord is ondertussen bijna klassiek. Zoals zo vaak heeft Microsoft niet de mooiste en meest doordachte producten; maar ze werken wel. Bovendien is altijd veel steun vanuit de software-industrie. Vanuit het andere kamp komen de meer evenwichtige en politiek correcte producten. Maar het duurt allemaal een stuk langer vanwege de overlegcultuur die ermee gepaard gaat. Ik acht overigens met name IBM in staat van het JavaBeans/Corba-initiatief een succes te maken. Als IBM slaagt, ontstaat een tweede serieuze standaard voor componentoriëntatie. Er zijn ondertussen trouwens steeds meer leveranciers die met hun producten beide standaarden ondersteunen en je ziet dan ook al serieuze, hybride mengvormen ontstaan.
Wat bepaalt of ‘component’ niet het zoveelste modewoord zal worden in de IT-industrie?
Vandenbulcke: ‘Component’ is ontegenzeggelijk een modewoord. Maar het is geen loze kreet, aangezien componentensoftware één van de middelen is die de IT-afdeling de organisatie kan aanreiken om beter, sneller en flexibeler op de omgeving te kunnen reageren. Maar de beschikbaarheid van goede componentensoftware alleen is onvoldoende. Er is veel meer nodig. Ik denk dan vooral aan een nieuw management dat vooruitkijkt, redeneert op langere termijn, effectiviteit minstens zo belangrijk acht als efficiëntie, en zich realiseert dat informatica niet zozeer een kostenpost is, waarop moet worden bezuinigd, maar een opportuniteit die moet worden benut en uitgebouwd."
Tolido: "Een modewoord? Ik zou zeggen: in ieder geval een brede, wereldwijde markt van componenten en vooral frameworks van componenten: brede, samenhangende oplossingen voor een compleet bedrijfsdomein. Verder lijkt het me extreem belangrijk dat we betere tools krijgen voor het componentiseren van bestaande, legacy-applicaties. Pas als we zo’n tussenstap met enig succes kunnen maken, zullen componenten op werkelijk brede schaal kunnen doorbreken. Dat componenten here to stay zijn, is voor mij overigens duidelijk: nogmaals, voor het ontwikkelen van een serieuze applicatie voor een gedistribueerd netwerk als Internet kun je straks eenvoudigweg niet meer zonder.
Cok de Zwart, freelancemedewerker Computable
