Het is logisch dat een eenduidige definitie van een component een allereerste vereiste is bij cbd . Veel belangrijker is het ‘software engineering’-proces, meent Daan van der Mijden. Hoe komen we tot componenten? Hoe identificeren we ze, hoe hergebruiken we ze en niet in het minst: hoe beheren we ze?
In het artikel ‘Losjes gekoppelde applicaties’ in Computable (11 juni 1999) beschrijft Aernout van Veluwen de noodzaak van een goede definitie van een component. Natuurlijk heeft hij gelijk. Het is een open deur intrappen om aan te geven dat we met zijn allen wél moeten weten waar we het over hebben. Dat geldt bij de supermarkt, bij het kopen van een huis en zeker ook bij het produceren van IT-systemen; niet alleen nu, maar al ruim dertig jaar.
Veel belangrijker is het ‘software engineering’-proces. Hoe komen we tot componenten? Hoe identificeren we ze, hoe hergebruiken we ze en niet in het minst: hoe beheren we ze? En dat alles op een gecontroleerde, herhaalbare wijze. Als je dat niet helder hebt val je in de standaard valkuil. Je denkt een ‘component based’ applicatie te ontwikkelen, maar eindigt met maatwerk. Je hebt dus op de ouderwetse wijze een applicatie geproduceerd, zelfs al heb je cbd-methoden en -technieken toegepast.
Je komt ook niet zomaar tot een component. Een component is een generalisatie van functionaliteit die zich in diverse contexten heeft bewezen. Componenten ontdek je door projecten en applicaties te analyseren, te evalueren. Dat is een investering die je moet maken. Door analyse van meerdere applicaties ontdek je dat diverse projecten gelijksoortige problemen op specifieke wijze hebben opgelost. Daaruit haal je generieke oplossingen, ontwerppatronen en componenten. Maar dan ben je er nog niet. Je hebt enkel aan de achterkant de componenten geïdentificeerd en – middels een goede beheerorganisatie – de componenten generiek gemaakt en met gebruik van een goed bereikbare infrastructuur beschikbaar gemaakt voor andere projecten. Nu moet je er nog voor zorgen dat je een ‘software engineering’-proces hebt waarin architectuurmodellering en component-acquisitie integraal is opgenomen. Deze iteratieve acquisitiestap zorgt voor de aanschaf en integratie van componenten. Dit kunnen – vanzelfsprekend – zowel ‘eigen’ als componenten van derden zijn. De boodschap luidt dan ook: Zorg eerst voor je ‘software engineering’-proces en de integratie met de beheeromgeving. Val niet in de valkuilen van de cbd-hype.
Tot slot wil ik nog een tip geven aan de beginnende ontwikkelaars van componenten. Start met infrastructuur-componenten. Maak bijvoorbeeld een ‘database abstraction layer’ en gebruik dit als een component. Creatie en hergebruik van bedrijfscomponenten is van een hele andere orde. Dan moet je het hele proces, inclusief beheer, goed onder de knie hebben.
Daan van der Mijden
projectmanager
Eindhoven
