Onlangs propageerden de auteurs in hun artikel ‘SDF-II: Objecten en Componenten met kennis’ de combinatie van kennistechnologie en component based development. Cbd zou volgens hen een grotere flexibiliteit bij systeemontwikkeling bieden. Dat geldt wellicht bij het ontwikkelen van nieuwe applicaties. Maar kan cbd ook de gewenste flexibiliteit brengen in legacy-systemen? Chris Nap en Jaap Snoep over de vraag welke specifieke eigenschappen van legacy-systemen verbeterd dienen te worden en op welke wijze cbd daarbij van nut kan zijn.
De veel genoemde voordelen van ontwikkelen op basis van componenten (‘component based development’, cbd) zijn: onafhankelijkheid van taal- en ontwerptechnologie,
herbruikbaarheid, inperking van de complexiteit door verhoging van de inzichtelijkheid,
betere onderhoudbaarheid, grotere flexibiliteit, en verkorting ’time-to-market’.
We lopen deze voordelen stuk voor stuk na om vast te stellen wat het nieuwe is van cbd.
Taal- en ontwerptechnologie
Bedrijven beschikken in toenemende mate over een heterogeen samengestelde IT-architectuur. Zowel intern, denk aan platforms, besturingssystemen, databases, pakketten, maatwerk, ontwikkeltools en communicatiestandaards, als extern. Bedrijven en particulieren communiceren immers op steeds meer verschillende manieren met elkaar. Vaak wordt een deeloplossing voor een benodigde functionaliteit geïntroduceerd. Zo’n deeloplossing, bijvoorbeeld deinstallatie van een pakket, biedt op korte termijn soulaas, maar doet de heterogeniteit toenemen.
Men kan streven naar standaardisatie door bestaande en nieuwe systemen onder één architectuur te brengen. Bijvoorbeeld de internet-architectuur. Er dienen zich echter altijd nieuwe ontwikkelingen aan, die niet in één keer de bestaande architecturen zullen vervangen.
Het antwoord van toolleveranciers op de toenemende heterogeniteit was tot voor kort dat zij met de eigen ontwikkeltools ‘glueware’ meeleverde om de nieuwe applicaties te kunnen laten communiceren met andere applicaties. De ‘glueware’ was dus leverancierspecifiek, aangezien men voor de communicatie met andere software daarvan afhankelijk was. Hierin is echter verandering gekomen met de komst van Corba en tot op zekere hoogte ook met Dcom. Corba en Dcom bieden mogelijkheden tot communicatie tussen applicaties/componenten, onafhankelijk van de gebruikte ontwikkeltool. De tool dient slechts één van beide of beide communicatiestandaarden te ondersteunen. Weliswaar zijn het altijd nog twee standaarden, maar het aantal is fors ingeperkt.
Het is op deze ontwikkeling dat cbd inspeelt. Cbd gaat uit van applicaties of componenten, die met elkaar kunnen communiceren onafhankelijk van de gebruikte taal- en ontwerptechnologie. Alles wat Corba of Dcom praat, kan met elkaar communiceren. Hiermee biedt cbd met name op het niveau van de totale systeemarchitectuur van een bedrijf het voordeel van een grotere flexibiliteit. Deze componenten kunnen bestaan uit nieuw maatwerk, uit pakketten of uit bestaande legacy applicaties, indien zij geschikt (gemaakt) zijn om via de afgesproken communicatiestandaard te communiceren. cbd heeft meerwaarde door de bestaande heterogeniteit als gegeven te accepteren en hierop voort te borduren.
In de methode is ingebed dat vanaf het beginstadium van ontwikkeling (nieuw of herontwerp) reeds wordt nagedacht over de diensten, die een specifieke component aan een andere component kan bieden.
Geldig, maar niet nieuw
Kijken we naar de overige voordelen van cbd, dan zijn deze geldig, maar niet nieuw.
Herbruikbaarheid van reeds ontwikkelde componenten wordt als voordeel van cbd geclaimd. Eenmaal ontwikkelde componenten zouden op diverse plaatsen en op diverse momenten herbruikbaar zijn. Als ‘pakketoplossing’ zijn hiervoor zeker mogelijkheden. Echter, verschillende situaties vereisen vaak weer een iets andere functionaliteit. Bijvoorbeeld wanneer een bedrijfsproces van het ene bedrijf overgeheveld wordt naar een ander bedrijf. Bij aanpassing van een component is dan al vaak geen sprake meer van ‘plug and play’. Ook in te kopen componenten zullen vaak net niet bieden wat men zoekt. De grootste kans voor hergebruik van componenten ligt binnen bedrijven zelf, die componenten of bouwstenen als een bibliotheek van halffabrikaten voor eigen ontwikkeling en levering in de vorm van projecten aan klanten gebruiken. Vaak zijn deze halffabrikaten met behulp van dezelfde tool ontwikkeld en bieden zij niets nieuws in de vorm van cbd.
Zaken als inperking van de complexiteit door verhoging van de inzichtelijkheid, en betere onderhoudbaarheid zijn zeker voordelen, maar niet nieuw. Met oude regels voor het modulair opzetten van applicaties en het bouwen van heldere interfaces wordt hetzelfde resultaat bereikt. Deze regels zijn juist belangrijk bij cbd-ontwikkeling. Cbd mag nooit een dekmantel zijn om nieuwbouw te ontwikkelen, wanneer de betreffende ontwikkelaars een voorgaand systeem niet-modulair hebben opgezet. Men zal componenten ontwikkelen die wederom moeilijk onderhoudbaar en moeilijk uitbreidbaar zijn.
Grotere flexibiliteit en verkorting van de time-to-market is te bereiken wanneer vanuit het oogpunt van de taal- en ontwerptechnologie onafhankelijkheid verschillende ‘stukjes van de legpuzzel opnieuw aan elkaar gepast worden’ wanneer een nieuw puzzelstukje toegevoegd wordt. Hier gaat het dus om de eerder genoemde flexibiliteit op het niveau van de systeemarchitectuur.
Het kan echter noodzakelijk zijn om individuele componenten aan te passen. Cbd biedt hiervoor op zichzelf geen middelen. Generatie van programmatuur vanuit specificaties biedt in dit opzicht de grootste flexibiliteit. Ook generatie van programmatuur kennen we al langer dan cbd. Ontwikkelen op basis van componeten (architectuur-niveau) en generatie van programmatuur (component-niveau) bieden gezamenlijk de beste flexibiliteit en de kortste ’time-to-market’.
Legacy-systemen
De tweede vraag die we willen beantwoorden is welke specifieke eigenschappen van legacy-systemen verbeterd moeten worden om de flexibiliteit van deze systemen te vergroten. In het voorgaande constateerden we dat het in principe mogelijk is legacy-systemen in een cbd-architectuur in te passen. Los van de vraag of cbd toegepast wordt, kan het nodig zijn een aantal maatregelen te treffen om de flexibiliteit van de legacy-systemen te verbeteren. Die maatregelen liggen dan in de sfeer van het verbeteren van de structuur en modulariteit, het verbeteren van de inzichtelijkheid door het genereren van documentatie, het gebruik van generatoren of van workbenches, indien generatoren niet compatibel zijn met de gebruikte tools.
Cbd kan hierbij een meerwaarde bieden door bestaande applicaties of delen daarvan om te vormen tot componenten, die via Corba of Dcom met andere componenten kunnen communiceren. Steeds meer toolleveranciers leveren hulpmiddelen om applicaties die ontwikkeld zijn met tools van een vorige generatie ‘in te pakken’, zodat zij via Corba of Dcom kunnen communiceren.
Het is de moeite waard te onderzoeken in hoeverre (delen van) legacy-applicaties als stukjes van de puzzel in een nieuwe cbd-architectuur opgenomen kunnen worden. Hierbij dient de kwaliteit van de legacy-applicaties onderzocht te worden: wat is de functionele kwaliteit (is de applicatie ergonomisch in zijn gebruik, wat is de kwaliteit van de opgeleverde informatie, sluit de functionaliteit aan bij de bedrijfsprocessen), wat is de technische kwaliteit (hoe onderhoudbaar en flexibel is het systeem), wat is de exploitatiekwaliteit (hoe is de prestatie, wat is het aantal verstoringen, hoe is het gebruik van de resources).
Een kosten/baten-analyse dient uit te wijzen wat meer voordelen biedt: pakketten, nieuwbouw volgens cbd, herstructurering of uitbreiding van functionaliteit van legacy-applicaties of een mix van al deze mogelijkheden.
Mixen
De toegenomen flexibiliteit door cbd komt vooral tot uiting op systeemarchitectuur-niveau. De flexibiliteit van de individuele onderdelen is echter nog steeds afhankelijk van de gebruikte tools en de vakkennis van de ontwerper/programmeur. Ontwikkelen op basis van componenten biedt, in aanvulling op bestaande tools en kennis, mogelijkheden legacy-systemen te verbeteren en een plaats te geven in een nieuwe, meer flexibele architectuur. Wanneer de structuur van legacy-systemen verbeterd wordt, bestaan er vaak mogelijkheden delen van legacy-systemen te hergebruiken. De optimale oplossing is vaak een mix van hergebruik, pakketten en nieuwbouw in een architectuur, die op componenten gebaseerd is.
Chris Nap en Jaap Snoep, Pink Roccade Atribit.
