Het is opvallend dat er nog steeds vooruitgang wordt geboekt bij het verbeteren van case-tools (‘computer aided software engineering’). Helaas komt deze vooruitgang langzaam en laat op gang. Het is al sinds de jaren tachtig bekend dat we zitten te springen om software-tools waarmee we specificatie, ontwikkeling en onderhoud van applicaties kunnen integreren. Toch is het anno 1999 een nieuwtje als IBM het Rose-product van Relational integreert met zijn eigen ontwikkeltools. Prachtig, maar dat hadden ze tien jaar eerder moeten doen. Toch is het nog niet té laat.
In de jaren tachtig was case een onpraktisch concept. De lagere case-tools konden karaktergeoriënteerd zijn, maar de hogere case-tools moesten grafisch zijn. De PC veranderde de spelregels en zorgde ervoor dat grafische tools kosteneffectief werden. Terwijl karakterterminals geen graphics aankonden, kon de PC zowel compileren als diagrammen bewerken. Het leek dus een slim idee om het ontwikkelwerk van het target-systeem af te halen en op een PC-werkbank te zetten. Ook al omdat op die manier elk programma voor meerdere target-platforms ontwikkeld kon worden. Dit sprak ontwikkelaars bijzonder aan, maar grote leveranciers niet. IBM bijvoorbeeld was niet gelukkig met cics-applicaties (‘customer information control system’) die snel naar Tuxedo en Unix geport konden worden. Er zijn redelijke successen geboekt met ‘cross-system development’, met name de Microfocus Cobol ‘workbench’, maar het hadden er veel meer kunnen en moeten zijn.
Een belangrijk struikelblok was het ontbreken van een repository-standaard, waardoor verschillende onafhankelijke case-tools niet tot een enkele lifecycle-systeem geïntegreerd konden worden.
Als gevolg hiervan werden er veel case-tools ontwikkeld die een aantal case-functies integreerden met een eigen, interne repository, maar nooit de hele levenscyclus van een applicatie ondersteunden.
Een standaard repository zou de integratie van afzonderlijke, hoogwaardige deelsystemen zeker hebben gestimuleerd. Het zou in de nabije toekomst kunnen gebeuren met de nieuwe op XML gebaseerde standaard XMI, maar Microsoft, Oracle en de andere leveranciers zullen geen afstand doen van de controle die ze nu door middel van semi-geïntegreerde producten over hun klanten kunnen uitoefenen. Probeer maar eens een Oracle-ontwerp te herleiden met behulp van, zeg, System Architect!
Er zijn echter enkele nieuwe en dringende redenen om toch tot integratie over te gaan. Een van de redenen zijn de gegevenspakhuizen, die hun repositories moet integreren met ontwerptools en Olap-repositories. De belangrijkste invloedsfactor is echter de component-architectuur, een ontwikkeling die de huidige erp-trend zal vervangen. Denk aan het San-Francisco-project. De gebruikers van componenten moeten precies weten wat die componenten doen. Dit betekent dat functionele en technische specificaties op aanvraag beschikbaar moeten zijn; dit kan alleen met een repository.
Een ander gebied dat zich te langzaam ontwikkelt is het modelleren van bedrijfsprocessen. De tools zijn er, maar ze worden nog niet gebruikt. Slechts weinig case-tools beginnen op het niveau van de bedrijfsprocessen. De katalysator voor de ontwikkeling van tools voor bedrijfsmodellering is niet afkomstig uit de software-ontwikkeling, maar uit de bpr-exercities in het begin van de jaren negentig. Helaas worden deze tools nog niet genoeg gebruikt. Voor de real-time simulatie van processen zijn PC-producten verkrijgbaar, die nauwelijks worden gebruikt. Ze worden te duur gevonden, terwijl jaren van onnodige herontwikkeling kennelijk gratis zijn.
Ook werkstroombeheersystemen (wfm) hebben een grote invloed op de behoefte aan tools voor analyse van bedrijfsprocessen. Bpr-tools zijn zeer waardevol bij de ontwikkeling van wfm-systemen. Als een procesmodel als invoer aan een simulatietool kan worden gevoed en het ontwerp reageert op een verstandige manier, dan kunnen de resulterende bedrijfsregels automatisch doorgegeven worden aan een tool voor het ontwikkelen van wfm-systemen.
Ook hier is een gezamenlijke repository wenselijk, omdat de output van het procesontwerp kan worden gebruikt voor het genereren van werkstroomregels en als invoer voor case-ontwerptools, tools voor het kopieerbeheer van gegevenspakhuizen, enzovoort.
Een geïntegreerd hulpmiddel voor procesontwerp, wfm en applicatieontwikkeling (met name op basis van componenten) is niet onmogelijk, maar de ontwikkeling ervan wordt gehinderd door merkeigen subsystemen en het ontbreken van standaarden. Het koppelen van IBM’s case-tools aan Relational Rose is beter dan niets, maar ik had liever gezien dat het open was.
