“Standaarden zijn niet abstract genoeg”
Soley omschrijft MDAals een manier om de onvermijdelijke verzameling legacy-systemen die bedrijven nu hebben, in de toekomst bruikbaar te houden door op model-niveau (in UML) een architectuur te definiëren waarin die systemen blijvend een rol spelen. “Architecturen houden het nu 18 tot 24 maanden vol. Ik wil daar 20 jaar van maken”, zegt Soley tegen zijn gehoor. Een centraal platform-onafhankelijk model moet worden omgezet naar de verschillende middleware-technologieën (Corba, XML, Java, Soap, et cetera), waardoor platformspecifieke modellen ontstaan. Een aantal van die omzetprofielen (‘mappings’) is al klaar; aan andere wordt nog gewerkt. Het aantal standaarden in de IT-wereld blijft maar groeien. Bent u daar niet teleurgesteld over geraakt? “Nee, ik denk dat het eenvoudiger zou zijn als er minder standaarden waren. Maar die veelheid aan standaarden ontstaat om twee redenen. De ene is dat een leverancier zijn klanten wil insluiten. Maar de meest gebruikelijke reden is toch dat gebruikers nu eenmaal uiteenlopende eisen stellen. En dan is het te billijken dat er op een bepaald gebied gewoon meer standaarden ontstaan. Het goede nieuws is dat in onze wereld UML heeft gewonnen. Er zijn geen andere modelleringsstandaarden meer. Al die leveranciers die OMT, Booch, IDFX en al die andere standaarden ondersteunden, zijn op UML overgestapt. We hebben één manier om modellen neer te zetten, we hebben één metamodel – de Meta Object Facility – nu hebben we de kans de gebruiker een duurzame manier te bieden om een architectuur weer te geven. Is MDA een puur OMG-initiatief? “De meeste standaardengroepen hebben een werkwijze waarbij een leverancier zijn specificatie als standaard aanbiedt. De OMG werkt zo niet. Wij ontwikkelen eerder samen een requirements-document. Bedrijven kunnen specificaties aanbieden die aan die eisen voldoen. Daarom is de standaardenset van de OMG veel coherenter. We hebben een kern van integratiestandaarden rond UML en Corba. We hebben ‘pervasive service’-standaarden die nu nog als Corba-standaarden zijn gespecificeerd, maar die over een jaar algemene modellen worden voor het bereiken van bijvoorbeeld transactionele integriteit. En we hebben een hele serie verticale standaarden voor de gezondheidszorg, de financiële sector, transport en noem maar op. Als je kijkt naar de bedrijven die al producten leveren die MDA ondersteunen – IBM, Borland, Compuware, Computer Associates, Rational, Iona en veel kleine leveranciers. Die standaarden zijn door een brede range bedrijven opgepikt. Maar het gaat ons uiteindelijk om de gebruikers die de standaard gebruiken, zoals Wells Fargo en Ericsson. Het probleem is van alle tijd. Ik herinner me een systeem dat oorspronkelijk was geschreven voor een IBM 1400, dat draaide op een emulator voor de IBM 360, die weer in een emulator op een IBM 370 draaide. Dat is niet bepaald een goeie engineering-aanpak. Als we zo bruggen zouden bouwen, zouden ze op en neer stuiteren. Hoe volwassen is MDA nu eigenlijk? Het is een grote set standaarden en sommige daarvan zijn klaar en andere zijn nog maar in een beginstadium. De kern is UML, een zeer volwassen standaard. De volgende stap is de profielen. Het profiel voor Corba is zo’n 7 maanden oud en dat werkt in de praktijk al. Maar het profiel voor webdiensten zit nog in de adoptiefase, omdat webdiensten zelf nog niet uitgekristalliseerd zijn. Voor J2EE is het profiel helemaal klaar. Voor bedrijfsapplicaties ook. Het profiel voor ‘message oriented applications’ is net twee weken oud, dus nog niet volwassen. Maar je zult dit jaar veel boeken over MDA zien verschijnen en dat lijkt me een goede graadmeter. In de realiteit gaat het natuurlijk om meer dan alleen de specificaties. Je hebt boeken, training, consulting en gereedschappen nodig. Maar het komt; Microsofts Visual Studio.Net ondersteunt MDA. In de loop der tijd is het beeld ontstaan van een tegenstelling tussen Microsoft enerzijds en de OMG die de daarmee concurrerende standaarden beheerde. Is er iets veranderd? “Niet echt. Microsoft is nu zo’n tien jaar lid van OMG, dat realiseren mensen zich niet. Het is nooit de doelstelling van OMG geweest om Microsoft op enigerlei wijze tegen te werken. Maar het is waar dat sommige bedrijven OMG-lid zijn geworden om Microsoft tegen te werken, omdat Microsoft niet altijd bestaande standaarden ondersteunt. Dat is mijn zaak niet. Als een bedrijf denkt dat standaarden ontwikkelen iets is dat Microsoft pijn doet is dat hun probleem. Microsoft heeft nooit de Corba-standaard ondersteund en zal dat waarschijnlijk ook nooit doen. Dus het leek op een strijd. Wij steunden wel de Com-standaard van Microsoft, want wat wij gebruikers willen geven is end-to-end standaarden om systemen aan elkaar te knopen. OMG heeft al sinds 1995 standaarden gepubliceerd die Com ondersteunen. Wij hebben nooit strijd geleverd met Microsoft. Het is wel duidelijk dat delen van Microsoft hebben geprobeerd strijd te leveren met delen van OMG. Mensen richten zich nu eenmaal op Microsoft vanwege hun positie in de IT-wereld. Maar Microsoft ondersteunt OMG-standaarden zoals UML en XML. Ook UML gaat over het verhogen van het abstractieniveau. Zal de IT ooit een fase bereiken waarin leken systemen kunnen ontwikkelen? “We hebben dat al twintig jaar, maar hebben het steeds spreadsheets genoemd. Complex kon het nooit worden en ik denk ook niet dat we ooit leken zullen zien die complexe applicaties afleveren. UML geeft je de mogelijkheid dingen met elkaar te verbinden zoals in die spreadsheets. Maar net zoals je ook geen leken een brug wilt laten bouwen, wil je leken geen grote complexe toepassing laten bouwen. Je kunt stellen dat met puur UML complete toepassingen zijn te bouwen, via zogeheten ‘precise action semantics’. Maar dat zijn in feite gewoon programma’s en iemand moet gewoon uitschrijven wat dat programma precies doet en dat kan niet in een natuurlijke taal. Standaarden als Corba en XML zullen blijven en er komen alleen maar meer standaarden bij. Zullen mensen in de toekomst nog zo veel tijd moeten besteden aan het voldoen aan standaarden of verdwijnen ze achter de abstracties? “Ze zullen niet uit het zicht verdwijnen, maar ze zullen minder tijd kosten, vanwege de gereedschappen en producten waarin ze zitten. De achterkant van de medaille is dat je niet altijd bezig kunt zijn met de hogere abstractieniveaus. Je moet uiteindelijk toch de draadjes aan elkaar knopen, je met de techniek bezighouden. Ik heb al meer dan 25 jaar geprogrammeerd; vertel mij niet dat ik nooit naar de bits hoef te kijken. Het nadeel van MDA nu is dat het je niet in staat stelt om op het niveau van modellen te debuggen. Als er in het programma een fout zit, word je toch terug geworpen naar een wereld waarmee je niet bezig was toen je de applicatie ontwierp. Ik moet dus weten of de verbinding via IIOP of via Soap tot stand moet komen, ik moet weten of het gegevensformaat XML of CDL is. Ik moet weten of het programma gecompileerd is uit Cobol of C++. Opeens doen al die dingen er dan weer toe. Het was voor mij een openbaring toen het met Lisp opeens mogelijk werd het debuggen op hetzelfde abstractieniveau te doen als het programmeren. De gereedschappen komen er wel maar zijn nog lang niet zo ver. Als een programma faalt, wil ik in een UML-model kunnen zien waar de code niet deugt. Dat is geen triviale uitdaging.