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 offshoring klinkt als ‘best of both worlds’ maar is oude wijn in nieuwe zakken. Het definieren van abstracte requirements is een goed startpunt, maar minder sterk wanneer dit betekent dat de details (bijv. business logica) alsnog op de traditionele geprogrammeerd moet worden, en nota bene door programmeurs aan de andere kant van de wereld! Veel krachtiger is het wanneer ook business logica in abstracte, visuele modellen kan worden vastgelegd en daarbij direct – dus ZONDER tussenstap van programmeren of codegeneratie – wordt uitgevoerd als een werkende applicatie/service (zie bijv. http://www.mendix.com). Dit overbrugt de traditionele communicatiekloof tussen business en ict, verkort de ontwikkelingstijd drastisch (en dus kosten) en biedt ook op de lange termijn flexibiliteit en kwaliteit. Op deze manier is er ook geen risico dat applicatie en model uit sync gaan lopen. Er geldt namelijk: het model = de applicatie. Kortom, de toegevoegde waarde van offshoring wordt door moderne model driven engineering-tools aanzienlijk minder. De business analyst is de programmeur van morgen!
Ik zie niks in model driven offshore. Model driven development in zichzelf is zeer productief en vereist dicht tegen de business aan te zitten. Met een goede MDA inzet vervalt juist de noodzaak tot offshoren, daarnaast ben je voornamelijk alleen nog bezig met requirements ipv programmatie. Ik zie het zelfs zover komen dat binnen een tijdsbestek van tien jaar ook nauwelijks een business analyst nodig is maar dat de business zelf het zaakje engineert als je dat vanuit een correcte visie en ‘denkkader’ kan doen, wellicht faciliteert ict dat denkkader.
De ict-industrie verkeert op dit moment in een productiviteitsdal. De snelheid die we met 4GL-omgevingen gewend zijn geweest worden tegenwoordig met .Net- en Java-ontwikkelstraten niet gehaald.
Model driven development is een van de belangrijkste innovaties om uit dit dal te komen (applicatie frameworks is een van de anderen). Maar aan een model driven invulling zoals hij door Derek Roos wordt gegeven (Mendix en aanverwante) kleven echter een paar belangrijke nadelen samengevat in het woord ‘proprietary’
Dit betekent dat:
1) Er vendor lock-in ontstaat.
2) Men voor de nieuwe features, innovaties, platform support, etc, afhankelijk is van het humeur van de leverancier.
3) De kennis van het tool niet breed beschikbaar is.
4) De applicatie vaak een 1-size-fits-all user interface heeft.
5) De uitbreidbaarheid van het tool vaak beperkt en onvriendelijk is.
Je zou kunnen zeggen dat dit de oude bekende 4GL-tools zijn, maar dan in een modern jasje. Als dit binnen de context van een gezocht oplossing acceptabel is dan kan het prima voldoen.
Een ander, en mijn ogen betere, benadering is om de het model/DSL en de executie van het model in eigen hand te houden. Door de inzet van een open model driven framework en de vertaling van het model/DSL naar source code op een gewenst (open) platform worden de geschetste nadelen vermeden.
Het inzetten van een open model driven framework is mogelijk, men dient dan echter wel met het volgende rekening te houden:
Veel open tools zoals bijv. Open Architecture Ware is een zogenaamde DSL tool. Dit betekent dat het prima ondersteuning biedt voor het defini?ren van je eigen domein specifieke taal en het defini?ren van transformaties naar code. Dit betekent echter ook dat je zelf je volledige model gedreven ontwikkelstraat moet inrichten inclusief taaldefinities, transformaties en runtime componenten. Dit vraagt om hoog nivo personeel die met dat abstractie / meta nivo om kunnen gaan. Verder moet er aan gedacht worden dat er al snel vijf of meer DSLs nodig zijn om een software systeem op het gewenste abstractie nivo te modelleren.
Natuurlijk is een tool als Mendix in zekere zin proprietary, er moet ergens geld mee verdiend worden. Er zijn echter heel wat maatregelen genomen om de bovengenoemde nadelen van 4GL tools te omzeilen:
1) Er zijn meerdere DSLs gedefinieerd die samen de applicatie modelleren.
2) Waar mogelijk zijn deze DSLs gedefinieerd op basis van open standaarden.
3) De runtime omgeving is volledig modulair en uitbreidbaar middels java code.
4) De user-interface kan volledig gecustomized worden en het is mogelijk om zelf widgets te defini?ren.
5) Er zijn integraties met bijvoorbeeld Backbase, hiermee gaat een wereld aan widgets open.
6) De modelleeromgeving kan modellen importeren uit business modeling tools als Bizzdesign.
Model Driven Offshore in een powerpoint presentatie klinkt als muziek in de oren, het tegendeel is echter waar. Communicatie tussen Nederlanders vakgenoten is al fout gevoelig, miscommunicatie ontstaat snel, met als gevolg dat druk op het project (lees kosten) snel kunnen oplopen cq het project kan falen. Feedback momenten, korte communicatie lijnen, en mensen die naast goed kunnen communiceren in het specifieke domein (bijvoorbeeld Nederlands, Verzekeringen, etc) en dit domein ook daadwerkelijk begrijpen zijn in Nederland in ruime mate aanwezig.
Onze ervaringen met offshoring naar India leert de kennis overdracht moeizaam verloopt. Daarmee zullen de totale kosten niet lager zijn, maar gelijk of zelfs hoger kunnen uitvallen door extra werk druk op project management, extra werk druk op testen en extra werk druk op communicatie. Als professional doen wij er van alles aan om miscommunicatie te voorkomen. We beschrijven in proza de behoefte. We stemmen ons woordgebruik af in een domein specifieke lijst van termen en definities. We werken de behoefte uit in smart requirements. We visualiseren deze requirements in modellen. We gebruiken model simulaties om vroegtijdig omissie te tackelen etc. Dan nog is de praktijk weerbarstiger, veranderd de behoefte door wetgeving, voortschrijdend inzicht etc. Er ontstaat met andere woorden opnieuw behoefte aan communicatie. Niet voor niets is vandaag aan de dag AGILE om die reden populair. Een methode om samen met de gebruiker snel de behoefte te formaliseren in een werkende applicatie. De combi goed voorwerk, en een Business Driven Power-tool zoals de Nederlandse innovaties van bvb Mendix, Uniface staat garant voor hoge effectiviteit, lage kosten en uitmuntende kwaliteit en vanzelfsprekend een uitstekende ROI. Binnen beide producten kunnen de business rules voldoende transparant op model niveau worden opgenomen. Met andere woorden heeft u de behoefte om snel te kunnen inspelen op de markt, zet dan in op een powertool en een professional. In praktijk blijkt de productiviteit van deze combi schrik niet een factor 10 hoger dan het traditioneel ontwikkelen van deze functionaliteit in .NET en JAVA. Kosten besparen, sneller kunnen reageren op de markt dat kan gewoon hier met Nederlandse innovaties.
Ik ben het eens met bovenstaande commentaren 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. Bij OutSystems hebben we al ruime ervaring met Model driven development gecombineerd met offshoring.
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!
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 onze TOC-aanpak toe om eerst het werkelijke probleem te bepalen; daarvan leid ik een zo gericht mogelijke oplossing af.
Door Kraanenburg wordt gesteld dat MDD tekort schiet in het ontwerpen van de business logica, 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 business logica 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 business logica 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.
In mijn opinie is “Model driven offshore” geen woordspeling, maar een tegenstrijdigheid. Als MDD toegepast wordt, dan moet het proces (incl. beschrijven business logica) 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.
Model Driven Architecture hoort de ontwikkeling van software minder arbeidsintensief te maken. Het vervolgens toch nog willen uitvoeren van het restandwerk 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 MDA verbetering met ingebouwde ‘patterns’ en betere modelleertalen voor het beschrijven van business logica. In dat geval wordt de oorspronkelijk MDA gedachte behouden.
De moeilijkheid van MDA is het simplificeren zonder daarbij teveel 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.