Experts twijfelen over model-driven offshore

Op het Topic Development is er een discussie ontstaan over modelgedreven softwareontwikkeling. Op sommige vlakken schiet dit tekort, daar zijn de experts het over eens, maar een echte oplossing geven ze niet. Wel wordt model driven offshore genoemd, maar ze zijn het niet eens of dit nou een woordspeling of nabije toekomst is.

De toepassing van model driven architecture/development samen met offshoring combineert de voordelen van een hoge productiviteit met de voordelen van lage arbeidskosten. Dat is althans de mening van expert Kees Kranenburg, portfolio & competence manager bij Atos Origin. "Het modelleren en genereren van applicaties heeft een nieuwe impuls gekregen door model driven architecture (mda). Omdat mda in zijn zuivere vorm als academisch wordt ervaren, spreken we liever over model driven development (mdd). Kern is en blijft een modelgedreven benadering voor softwareontwikkeling. Eén van de tekortkomingen van mdd 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. Dat is ook lastig voor de tool-leveranciers bij gebrek aan een duidelijke standaard voor het specificeren van businesslogica. Dus wat doen we bij gebrek aan beter: we specificeren de businesslogica in Word-documenten en programmeren deze handmatig in C# of Java. Dat is arbeidsintensief en gaat natuurlijk ten koste van de productiviteit. Wanneer iets arbeidsintensief is, dan doen we dat bij voorkeur in India. Zo is model driven offshore geboren en worden de voordelen van mdd gecombineerd met de voordelen van offshoring."

Tony van Büüren van Heijst, senior presales, OutSystems

"Ik vind dat de combinatie van agile en een agile-ontwikkelplatform kunnen helpen de productiviteit te verhogen. Dit sluit offshoring echter niet uit. Agile-projecten kunnen goed zowel onshore, nearshore als zowel offshore plaatsvinden wanneer de juiste tools en methoden worden gebruikt. Mdd is dus prima te combineren met offshoring."

Jos Warmer, partner, Ordina

"Model driven offshoring betekent dat de modellen, die het dichtst bij de business liggen in Nederland gemaakt worden, dus optimale communicatie met de business. Vanuit de modellen wordt code gegenereerd die de architectuur van de applicatie bepaalt. Wat niet in modellen gevangen kan worden, wordt vervolgens op een offshore-locatie ontwikkeld. Dit is het arbeidsintensieve deel, precies datgene waarvoor offshore interessant is. Doordat de offshore-ontwikkelaars alleen code kunnen toevoegen aan de uit de modellen gegenereerde code, blijft de architectuur van de applicatie honderd procent gegarandeerd. Daarmee is mdd tevens een instrument om controle te krijgen op de kwaliteit van de applicatie en de door de offshore-partner geschreven code. De opgeleverde applicatie kan, omdat hij voldoet aan een duidelijke en bekende architectuur, zowel in Nederland als op de offshore-locatie onderhouden worden. Dat geeft flexibiliteit in de uitvoering, en daarmee meer toekomstmogelijkheden. Jazeker, model driven offshoring heeft absoluut toekomst!"

Alexander Vermeulen, informatieanalist, Caesar Groep

"Model driven offshore is wat mij betreft een woordspeling. Wat zijn we als ict'ers toch goed in het bedenken van oplossingen. Vaak gaan we voorbij aan het werkelijke probleem, liever gaan we lekker oplossingen realiseren. Maar of die ook werkelijke het probleem oplost? Ik pas dagelijks de aanpak toe om eerst het werkelijke probleem te bepalen; daarvan leid ik een zo gericht mogelijke oplossing af. Er wordt gesteld dat mdd tekort schiet in het ontwerpen van de businesslogica, waardoor uitschrijven en programmeren arbeidsintensief blijft. Daarop volgt de snelle oplossing: dan maar uitbesteden naar het buitenland. De kern van het probleem is simpelweg dat de gekozen mdd-oplossing niet in staat was de businesslogica eenduidig vast te leggen. In plaats van dit probleem op te lossen, wordt gekozen voor iets dat mij een uitvlucht lijkt. Het is arbeidsintensief, dus offshoren dan maar! Het probleem blijft. Een mdd wordt pas een goede oplossing als het in staat is ook de businesslogica te definiëren en dat kan mijns inziens niet offshore uitgevoerd worden, want de business (de mensen hier dus) is nodig om de logica te specificeren."

André Weber, manager teststraat (Test factory), Capgemini BAS

"In mijn opinie is model driven offshore geen woordspeling, maar een tegenstrijdigheid. Als mdd toegepast wordt, dan moet het proces (inclusief beschrijven businesslogica) dermate professioneel zijn dat de applicatie automatisch gegenereerd kan worden. Hiervoor is veel klantkennis nodig. Vervolgens blijft geen arbeidsintensief werk over dat te offshoren is. De praktijk kan weerbastiger zijn, maar dan moet je jezelf afvragen of mdd toegepast kan worden. Als mdd niet toegepast wordt, dan is offshoring weer een goed middel. Een extra dimensie bij mdd of architecture is het testen. Omdat de applicatie gegenereerd wordt op grond van businesslogica en -rules zijn er geen functionele ontwerpen aanwezig om traditionele testtechnieken toe te passen. Het heeft geen zin om te testen of de businesslogica en -rules tot een goede applicatie geleid hebben. In dat geval wordt met een tool getest of het mdd-proces goed gewerkt heeft. 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 mdd of architecture een mogelijke optie."

Ben Ootjers, consultant Microsoft solutions, Unisys

"Mda hoort de ontwikkeling van software minder arbeidsintensief te maken. Het vervolgens toch nog willen uitvoeren van het restantwerk in een offshore-land lijkt dan strijdig met dit uitgangspunt. Immers, als het ontwikkelen toch niet duur is dan ga je ook niet investeren in een betere mda-aanpak. Er kan beter gezocht worden in de richting van verbetering met ingebouwde ‘patterns' en betere modelleertalen voor het beschrijven van businesslogica. In dat geval wordt de oorspronkelijk gedachte behouden. De moeilijkheid van mda is het simplificeren zonder daarbij te veel detail te verliezen. Als er teveel detail verloren gaat dan is er nog veel codeerwerk nodig. De complexiteit van mda daalt naar verloop van tijd door toename van kennis en kan daarna weer worden uitgebreid. De volgende stap met DSL-tools is een goede, maar ik verwacht dat het nog enige tijd (en kennisverspreiding) zal vergen voordat hier meer mee gedaan wordt. De mda-manier van werken is echter communicatie-intensief en dat in combinatie met offshore werken is eerder het toevoegen van een extra complexiteit dan het ei van Columbus."

Sherry Bibiana, managing consultant, Tomt

"Model driven architectuur is als paradigma vooral gericht op het bereiken van eenwording van model en executie (‘what you model is what you run') en daarmee het elimineren van ‘codekrassen'. Dit betekent daarom ook dat per definitie de specificatiekant 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. Businesslogica 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 en 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. Om al deze redenen is een doorbraak van model driven offshoring niet alleen onwaarschijnlijk, maar ook onnodig."