De toepassing van model driven architecture/development samen met offshoring combineert de voordelen van een hoge productiviteit met de voordelen van lage arbeidskosten.
Het modelleren en genereren van applicaties heeft een nieuwe impuls gekregen door model driven architecture (MDA). MDA is ontwikkeld door de Object Management Group en definieert een raamwerk van modellen voor softwareontwikkeling. Het idee achter MDA is vertrouwd: eerst wordt het systeem op een hoog abstractieniveau gemodelleerd, vervolgens wordt het systeem volledig in modellen gespecificeerd op basis waarvan een complete, werkende applicatie wordt gegenereerd.
Omdat MDA in zijn zuivere vorm als academisch wordt ervaren, spreken we liever over model driven development. Kern is en blijft een modelgedreven benadering voor softwareontwikkeling. Bij de toepassing ligt de nadruk op het modelleren en neemt het belang van handmatig coderen af. Bovendien maakt de applicatiegenerator het mogelijk dat de software-engineer zich kan richten op de belangrijke delen van de applicatie en zich minder hoeft bezig te houden met de technische details onder water. Dit bewerkstelligt een aanzienlijke verbetering van de productiviteit en vereenvoudigt het applicatieonderhoud.
Eén van de tekortkomingen van model driven development is de businesslogica.
Het modelleren van structuur gaat goed. Op basis van deze structuurmodellen zijn ontwikkelomgevingen in staat om werkende applicaties te genereren, maar waar het vaak aan schort is het genereren van de businesslogica (de ‘business rules'). Dat is ook lastig voor de tool-leveranciers bij gebrek aan een duidelijke standaard voor het specificeren van businesslogica. In het verleden zijn hiervoor wel methoden ontwikkeld, maar het is nooit echt doorgebroken. Hoeveel van onze software-engineers in Nederland zijn bekend met predicatenlogica, Infomod of met OCL?
Dus wat doen we bij gebrek aan beter: we specificeren de businesslogica in Word-documenten en programmeren deze handmatig in C# of Java. En dat is arbeidsintensief en gaat natuurlijk ten koste van de productiviteit. Ah, maar wanneer iets arbeidsintensief is, dan doen we dat bij voorkeur in India. En zo is model driven offshore geboren en worden de voordelen van model driven development gecombineerd met de voordelen van offshoring.
Model driven offshore: een woordspeling of nabije toekomst?
Model Driven Architectuur is als paradigma met name gericht op het bereiken van eenwording van model en executie (‘what you model is what you run’) en daarmee het elimineren van ‘code krassen’. Dit betekent daarom ook dat per definitie de specificatie (requirements)-kant van systeemontwikkeling de kern wordt van alle activiteiten. Daarmee komt de ontwikkelaar ook per definitie dichter bij de business te staan, en idealiter wordt de business zelf de ‘ontwikkelaar’ van het systeem. Vanuit risico overweging moet men dit soort trajecten alleen aanpakken via een Agile methodiek (RUP, DSDM, Scrum). In de Agile wereld geldt immers: ‘User Involvement is imperative’.
Een fysieke offshore – afstand scheppen tussen Business en de ontwikkelaars is het introduceren van een extra projectrisico. Business logica is in dat verband te modelleren middels BPM en BRM concepten en we zien daarom dan ook veel onderzoek in de richting van combinaties van MDA met BPM/BRM. Een van de grote struikelblokken van MDD/MDA blijft het proprietary karakter van de beschikbare modelleer-tooling. Anders dan bij BPM (met BPMN) blijft een werkelijk ge?mplementeerde open standaard een onvervulde wens. Dus een groter risico bij offshore trajecten en dat moet je niet willen. Om al deze redenen is een doorbraak van Model Driven Offshoring niet alleen onwaarschijnlijk, maar ook onnodig. Zeker niet doen als de on site ICT organisatie geen CMMI level 2 heeft met goed ingerichte Requirements Management!
Een extra dimensie bij MDA/MDD is het testen. Omdat de applicatie gegenereerd wordt op grond van business logica en -rules zijn er geen functionele ontwerpen aanwezig om traditionele testtechnieken toe te passen. Het heeft geen zin om te testen of de business logica en -rules tot een goede applicatie geleid hebben. In dat geval wordt getest of het MDA/MDD proces goed gewerkt heeft, oftewel de MDA/MDD tool en het proces worden getest. Doel van testen is juist om te valideren of de business ook de toepassing krijgt waar hij op zit te wachten en of alles naar behoren werkt.
Om dit op te lossen moet gekozen worden voor een modernere testtechniek zoals exploratory testing. Belangrijk is dan dat de tester weet wat de klant van het eindproduct verwacht. Er is derhalve regelmatig klantcontact nodig. Alleen als er een situatie gecre?erd kan worden waarbij de business er geen probleem mee heeft om regelmatig contact met een offshore partij te hebben, dan is (deels) offshore testen bij MDA/MDD een mogelijke optie.