Rik schrijft:
"ESB gedreven SOA". Bestaat er dan ook zoiets als "niet ESB gedreven SOA"? Volgens mij niet. Zelfs in een volledig geharmoniseerde en gestandardiseerde wereld zul je altijd berichten moeten routeren, gegarandeerd moeten transporteren en moeten orkesteren. Of zie jij een alternatief?
Ja, ik zie wel een alternatief.
Natuurlijk, dat routeren, transporteren, enzovoort is nodig. Maar is het nodig dat allemaal te integreren in één tool, namelijk de ESB? Die is duur om aan te schaffen, duur om te implementeren, en bovendien proprietary, wat in feite betekent dat het bedrijf in kwestie zich min of meer uitlevert aan de vendor.
Bovendien zijn heel veel van die "luxe" functionaliteiten van een ESB helemaal niet zo hard nodig, en worden ze zelden gebruikt.
Door dit alles worden die ESB-implementaties noodzakelijkerwijs company-brede projecten, en zoals we allemaal weten: die mislukken, zeker als ze niet 100% nodig zijn. En dat zijn die ESB-projecten niet, omdat er altijd een plan B is: een beetje halfwas invoeren, en de rest naar de toekomst schuiven. En plan C is: installeren, roepen dat je het gebruikt, maar in werkelijkheid gewoon de ouwe trouwe messagebroker blijven gebruiken.
Ik zie zeker twee alternatieven.
1. gebruik een mean&lean "ESB" voor de routering etc van het berichtenverkeer, en gebruik daarvan de functionaliteit op een dusdanige wijze dat je kunt switchen naar een ander tool. Een manier om dat te doen, is het gebruik van meer dan één ESB, maar dat stuit uiteraard nog wel eens op investeringsgrenzen.
2. gebruik een REST-route, en ga naar een ROA-architectuur. Dat kan ook, daar is nauwelijks extra tooling voor nodig, en kan incrementeel worden gedaan. Maar het sluit (in ieder geval op het eerste gezicht) veel minder goed aan bij de bestaande architectuur, en bovendien weten systeemarchitecten e.d. nit hoe ze dit moeten aanpakken.
Een extra argument voor deze alternatieve routes is dat de ver-SaaS-ing of ver-cloud-ing van de functionaliteit eraan komt, en dan zit een zware proprietary ESB ontzettend in de weg, zowel technisch als budgettair.
Niet doen dus, het zijn dinosaurussen.
maandag 29 september 2008
vrijdag 26 september 2008
SOA: hoe in te voeren?
Jonathan Mack op InfoQ, over hoe moeilijk het is om SOA in te voeren.
"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."
Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.
Conclusie: SOA, althans ESB gedreven SOA, werkt niet.
Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.
"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:
- Enterprise (top-down) SOA approach, which is an extremely high - risk approach with an initial price tag of a several million dollars. In addition, based on the size and complexity, such project can virtually never be accurately estimated.
- Grassroots (bottom-up) SOA approach - implementing elements of SOA (both services and infrastructure) as parts of existing business-driven IT undertaking. This approach typically does not succeed. On one hand, the scope of resulting services is limited to the specific business problem and might not be applicable (or even wrong) for the rest of enterprise. On another hand, the time and expense required to build the SOA layer can detract from other business needs of a project."
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."
Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.
Conclusie: SOA, althans ESB gedreven SOA, werkt niet.
Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.
vrijdag 19 september 2008
O'Reilly gelooft ook niet in het advertentie-model
donderdag 18 september 2008
Content delivery door Amazon AWS
Kijk, dit zat er in: content delevery via één API door AWS. Koppeling met het betaalsysteem FPS ligt natuurlijk vreselijk voor de hand.
Zie AWS blog en Werner Vogels.
maandag 15 september 2008
Google op zee
Google wil datacenters op zee. Om de golfenergie te gebruiken. En om minder belastingen te betalen. En misschien ook wel om minder last van wetten en regels en juridisch gezeur te hebben.
Onzin over cloud computing
De laatste tijd lees ik nogal eens van die verhalen waarin wordt gezegd da cloud computing er niet is of komt, omdat er nog steeds on-premise computing is en blijft. Staat op mijn lijstje om eens op te reageren, maar Anshu Sharma heeft het al gedaan. Hij heeft groot gelijk.
donderdag 4 september 2008
SaaS lock-in: een risico?
Vendor lock-in bij SaaS-oplossingen wordt de laatste tijd nogal eens als risico van SaaS geschetst. Terecht, want lock-in is altijd een probleem, bij een pakket, bij SaaS, en ook bij zelfgebouwde oplossingen.
Maar het lock-in risico bij SaaS wordt overdreven. Wel gelden vier regels:
1. Kies alleen SaaS-oplossingen waarbij je ondubbelzinnig eigenaar van de data bent en blijft.
2. Zorg voor een model (bijvoorbeeld een objectmodel) waarin de business beschreven is, en projecteer dat op het model van de leverancier. Dit is nodig voor conversies, voor koppelingen en voor de exit-strategie.
3. Kies alleen SaaS-oplossingen met goede interfaces. Niet alleen user-interfaces, maar ook APIs voor data-verkeer en integratie.
4. Gebruik die APIs vervolgens zo min mogelijk. De kracht van SaaS zit vooral in de lage kosten en investeringen. Gooi dat voordeel niet weg door niet echt noodzakelijke integratie zelf te bouwen, want daarmee lockt u uzelf in.
Kortom: lock-in is een beheersbaar risico. En de Pavlov-reactie van IT-ers om dan maar zelf iets te gaan bouwen, maakt het erger. Misschien wordt de vendor lock-in iets minder, maar de maatwerk lock-in wordt des te groter.
Maar het lock-in risico bij SaaS wordt overdreven. Wel gelden vier regels:
1. Kies alleen SaaS-oplossingen waarbij je ondubbelzinnig eigenaar van de data bent en blijft.
2. Zorg voor een model (bijvoorbeeld een objectmodel) waarin de business beschreven is, en projecteer dat op het model van de leverancier. Dit is nodig voor conversies, voor koppelingen en voor de exit-strategie.
3. Kies alleen SaaS-oplossingen met goede interfaces. Niet alleen user-interfaces, maar ook APIs voor data-verkeer en integratie.
4. Gebruik die APIs vervolgens zo min mogelijk. De kracht van SaaS zit vooral in de lage kosten en investeringen. Gooi dat voordeel niet weg door niet echt noodzakelijke integratie zelf te bouwen, want daarmee lockt u uzelf in.
Kortom: lock-in is een beheersbaar risico. En de Pavlov-reactie van IT-ers om dan maar zelf iets te gaan bouwen, maakt het erger. Misschien wordt de vendor lock-in iets minder, maar de maatwerk lock-in wordt des te groter.
woensdag 3 september 2008
Cloud browser
Google heeft Chrome uitgebracht, in beta. Chrome is een webbrowser, op het eerste gezicht een concurrent van Firefox, IE, Safari, Opera, etc. Maar er is een verschil: Chrome is vooral gericht op het ondersteunen van het runnen van webapplicaties.
En ik denk dat het Google niet zozeer gaat om het van de markt drukken van IE of zo, maar om het versnellen van het gebruik van webapps.
En ik denk dat het Google niet zozeer gaat om het van de markt drukken van IE of zo, maar om het versnellen van het gebruik van webapps.
donderdag 28 augustus 2008
voor de restliefhebbers
Dit verhaal van Bill de hÒra (daar heb ik dus het character palette bij nodig). En ook deze.
Zijn punt: REST is niet makkelijk, maar het kan in ieder geval de vereiste complexiteit aan. Dit in tegenstelling tot SOAP etc.
Dat laatste punt is wel waar: SOAP is inderdaad heel erg simpel, maar het lsot ook vrijwel niets op.
UML + DSL
Dit is een interessante ontwikkeling. Microsoft gaat toch iets met UML doen, en zelfs op een hoger abstractie-nivo dan de DSLs.
Ik kan me daar wel iets bij voorstellen (itt Steven Kelly), maar ik moet toch eerst even zien hoe dit werkt.
(via Jacob den Haan)
donderdag 21 augustus 2008
MDE en de silver bullit
Johan den Haan heeft de moeite genomen op mijn vorige post te reageren, en daar ben ik blij mee.
Hij schrijft:
"Ik denk zeker dat MDE de toekomst is. Waar ik voor pleit, wat ook in het InfoQ artikel naar voren komt, is een bredere aanpak dan alleen MDA of alleen DSLs. MDE , met DSLs als basis, heeft meer potentie. "
Ik ben het met hem eens. Wellicht zie ik meer in archtype domein modellen dan Johan, en Johan weer wat meer in "echte" DSLs, maar dat zijn minieme verschillen van inzicht. Dat gaat vooral over welke vorm een DSL moet of kan hebben, en hoe een DSL in MDE kan worden gebruikt.
Johan verder:
"Waar ik sceptisch over ben is alles wat model-driven in de naam heeft te zien als 'silver bullet'. Daarnaast denk ik dat het opzetten van een model gedreven ontwikkelstraat om enorm veel expertise vraagt, zowel op het gebied van software engineering als op het gebied van language engineering."
Inderdaad, silver bullets bestaan niet. En wat betreft die model driven ontwikkelstraat (ik ben wat minder scrupuleus als het gaat om het mengen van nederlands en engels, geloof ik :) ): inderdaad, dat is een probleem. Misschien is het zelfs wel een onmogelijke opgave.
Want om MDE (in ieder geval zoals ik dat zie) goed aan de praat te krijgen, moet aan een aantal voorwaarden zijn voldaan:
1. de generatie van executables (al of niet met leesbare code als tussenstation) moet 100% zijn. Zodra een aspect van een domein of architectuur op twee plaatsen in de stroom (bijvoorbeeld in een model en in programmacode) moet worden bewerkt, zal na verloop van tijd de bewerking alleen nog op de tweede plaats (stroomafwaarts dus) worden onderhouden. Het model wordt waardeloos en de model driven straat ook.
2. de MDE straat moet complexe domeinen aankunnen, en ook voldoende vrijheidsgraden bieden om hybride architcturen, verscheidene platforms, etc, etc aan te kunnen.
Deze twee punten vereisen dus een grote en ingewikkelde ontwikkelstraat, hoogstwaarschijnlijk slechts te bedienen door lieden die buitengewoon goed weten hoe het werkt, hoet zou moeten werken, enzovoort. Experts dus.
Maar om een aanpak als MDE (of welke nieuwe aanpak of tool voor software-ontwikkeling dan ook) met succes geïntroduceerd en geaccepteerd te krijgen, zijn er nog een paar voorwaarden:
3. de aanpak en de tooling moet redelijk bestand zijn tegen onoordeelkundig gebruik. Met andere woorden: een "foute" aanpak moet òf onmogelijk zijn, òf niet tot desastreuze resultaten leiden.
4. aanpak en werkwijze moeten te leren zijn door "gewone" software-ontwikkelaars. Liefst in een training van maximaal 5 dagen.
Vernieuwingen die een enorme expertise, training en discipline vereisen hebben de neiging te mislukken, zeker als de betrokkenen menen een simpeler alternatief (i.c. de conventionele werkwijze) te hebben. Dat laat de geschiedenis van de software-ontwikkeling volgens mij zien.
Het is duidelijk: voorwaarde 1 en 2 staan op zeer gespannen voet met 3 en 4. Ze zijn nauwelijks te combineren.
De conclusie:
MDE is alleen goed te gebruiken in situaties waarin de complexiteit van de opdracht, de vereiste snelheid van ontwikkeling, etc een aanpak als MDE noodzakelijk maakt. En de organisatie moet de consequenties (kosten tooling, eisen aan de experts, etc) dan voor lief nemen en niet toch een ogenschijnlijk goedkopere combinatie met een conventionele aanpak na te streven (met kletspraat over win-win-situaties enzo).
"Gewone" systeemontwikkeling voldoet hier maar zelden aan, dat is duidelijk. Grootschalige systeemontwikkeling, speciaal bij produktontwikkeling (product line engineering), daarentegen bieden wel mogelijkheden. En een van de effecten van SaaS en cloud computing zal zijn dat meer software op die manier gemaakt en onderhouden zal worden. Maar in de gewone systeemontwikkeling zie ik niet veel ruimte voor MDE.
Ben ik nou te cynisch?
Hij schrijft:
"Ik denk zeker dat MDE de toekomst is. Waar ik voor pleit, wat ook in het InfoQ artikel naar voren komt, is een bredere aanpak dan alleen MDA of alleen DSLs. MDE , met DSLs als basis, heeft meer potentie. "
Ik ben het met hem eens. Wellicht zie ik meer in archtype domein modellen dan Johan, en Johan weer wat meer in "echte" DSLs, maar dat zijn minieme verschillen van inzicht. Dat gaat vooral over welke vorm een DSL moet of kan hebben, en hoe een DSL in MDE kan worden gebruikt.
Johan verder:
"Waar ik sceptisch over ben is alles wat model-driven in de naam heeft te zien als 'silver bullet'. Daarnaast denk ik dat het opzetten van een model gedreven ontwikkelstraat om enorm veel expertise vraagt, zowel op het gebied van software engineering als op het gebied van language engineering."
Inderdaad, silver bullets bestaan niet. En wat betreft die model driven ontwikkelstraat (ik ben wat minder scrupuleus als het gaat om het mengen van nederlands en engels, geloof ik :) ): inderdaad, dat is een probleem. Misschien is het zelfs wel een onmogelijke opgave.
Want om MDE (in ieder geval zoals ik dat zie) goed aan de praat te krijgen, moet aan een aantal voorwaarden zijn voldaan:
1. de generatie van executables (al of niet met leesbare code als tussenstation) moet 100% zijn. Zodra een aspect van een domein of architectuur op twee plaatsen in de stroom (bijvoorbeeld in een model en in programmacode) moet worden bewerkt, zal na verloop van tijd de bewerking alleen nog op de tweede plaats (stroomafwaarts dus) worden onderhouden. Het model wordt waardeloos en de model driven straat ook.
2. de MDE straat moet complexe domeinen aankunnen, en ook voldoende vrijheidsgraden bieden om hybride architcturen, verscheidene platforms, etc, etc aan te kunnen.
Deze twee punten vereisen dus een grote en ingewikkelde ontwikkelstraat, hoogstwaarschijnlijk slechts te bedienen door lieden die buitengewoon goed weten hoe het werkt, hoet zou moeten werken, enzovoort. Experts dus.
Maar om een aanpak als MDE (of welke nieuwe aanpak of tool voor software-ontwikkeling dan ook) met succes geïntroduceerd en geaccepteerd te krijgen, zijn er nog een paar voorwaarden:
3. de aanpak en de tooling moet redelijk bestand zijn tegen onoordeelkundig gebruik. Met andere woorden: een "foute" aanpak moet òf onmogelijk zijn, òf niet tot desastreuze resultaten leiden.
4. aanpak en werkwijze moeten te leren zijn door "gewone" software-ontwikkelaars. Liefst in een training van maximaal 5 dagen.
Vernieuwingen die een enorme expertise, training en discipline vereisen hebben de neiging te mislukken, zeker als de betrokkenen menen een simpeler alternatief (i.c. de conventionele werkwijze) te hebben. Dat laat de geschiedenis van de software-ontwikkeling volgens mij zien.
Het is duidelijk: voorwaarde 1 en 2 staan op zeer gespannen voet met 3 en 4. Ze zijn nauwelijks te combineren.
De conclusie:
MDE is alleen goed te gebruiken in situaties waarin de complexiteit van de opdracht, de vereiste snelheid van ontwikkeling, etc een aanpak als MDE noodzakelijk maakt. En de organisatie moet de consequenties (kosten tooling, eisen aan de experts, etc) dan voor lief nemen en niet toch een ogenschijnlijk goedkopere combinatie met een conventionele aanpak na te streven (met kletspraat over win-win-situaties enzo).
"Gewone" systeemontwikkeling voldoet hier maar zelden aan, dat is duidelijk. Grootschalige systeemontwikkeling, speciaal bij produktontwikkeling (product line engineering), daarentegen bieden wel mogelijkheden. En een van de effecten van SaaS en cloud computing zal zijn dat meer software op die manier gemaakt en onderhouden zal worden. Maar in de gewone systeemontwikkeling zie ik niet veel ruimte voor MDE.
Ben ik nou te cynisch?
donderdag 14 augustus 2008
Waarom MDE zal falen volgens Johan den Haan
Op InfoQ trof ik dit artikel aan: 8 redenen waarom MDE zal falen. MDE falen? 8 redenen maar liefst?! Hoog te paard ging ik het stuk lezen, maar het is eigenlijk een vrij goed verhaal. De schrijver, Johan den Haan, weet waarover hij praat, en zijn opmerkingen zijn blijkbaar (mede) ingegeven door praktische ervaring.
De 8 redenen zijn ook meer 8 grote risico's, en in zijn schets daarvan heeft hij wel gelijk. Ik zal ze even nalopen.
1. De gangbare MDE-aanpakken en -tools zijn vrijwel uitsluitend gericht op het korte termijn doel van verhoging van produktiviteit voor developers: meer functiepunten per uur, en verder niks.
Ja, dat is zo, en dat is inderdaad een van de grote tekortkomingen van de gebruikelijke aanpakken. Links laten liggen dus, en richten op waar het in MDE echt over gaat (vorige week blogde ik daarover ook al).
2. in MDE concentreert men zich meestal op slechts één modelleringsdimensie. Architectuur bijvoorbeeld wordt er bij de MDA aanpak een beetje bijgefrommeld in de PSM.
Inderdaad, dat lijkt nergens op. Den Haan is hier nog veel te voorzichtig: je hebt zowel binnen het domein als binnen de weergave van de technische architectuur en implementatie verscheidene modelleringsdimensies nodig.
Naar mijn idee is dat te doen met een goede modeltransformatieaanpak, maar simpel is het niet. Bovendien: hoeveel modeldimensies moeten we aankunnen?
3. de gangbare tools richten zich op het maken van nieuwe artefacten (stukken code, getransformeerde modellen, etc) en laten de problemen van aanpassing van bestaande artefacten links liggen.
Den Haan heeft hier ongetwijfeld gelijk, maar ik denk dat hij hier de zaak wat complexer maakt dan strikt nodig is. Immers, als je afgeleide artefacten 100% kunt genereren, kun je ook zelfs voor een kleine wijziging de hele zwik van (tussen)modellen, code, enzovoort gewoon opnieuw maken. Daar zitten nadelen en beperkingen aan (zoals de veteranen uit de CBD-hoek weten), maar je komt er wel een eind mee.
4. MDE richt zich teveel op General Purpose Languages zoals UML. Dat is niet voldoende: je hebt voor deelterreinen specifieke talen nodig. Het bekende DSL-lied.
Ja, dat is zo, maar ik denk wel dat in ieder geval als het gaat om business domeinen de combinatie van "gewoon" UML, analyse patronen (archetypes) en een abstractiemechanisme waarmee specifieke modellen van meer generieke patronen kunnen worden afgeleid heel veel helpt. Je kunt dan natuurlijk zo'n analyse-patroon of een bepaalde afleiding als een DSL zien.
Zie ook hier en hier en hier.
5. Zelf ontworpen DSL's zullen een chaos creëren.
Ja, dat ben ik helemaal met Den Haan eens. Voor mij is dat ook een reden om meer van archetypes gebruik te maken. Die zijn geschreven in UML, en dus veel makkelijker te begrijpen en te integreren.
6. Niet volledig executeerbare modeltransformaties zijn een bedreiging. Ja, dat is zeker zo. He treurige gehannes met PIM en PSM in veel MDA tools is daarvan trouwens een voorbeeld (Den Haan noemt het niet).
7. Modellen kunnen meestal neit of slechts zeer moeizaam op modelnivo worden getest. Dat is natuurlijk een probleem, want de enige manier om te testen is dan; eerst alles uitgenereren (aangenomen dat dat kan), en dan testen. Maar dat maakt het natuurlijk erg onhandig om zo fouten en onvolledigheden in het model op te sporen.
8. Tooling is onvoldoende. Den Haan geeft als voorbeeld de debugger die in de modelleeromgeving meestal afwezig is. En ook hier heeft hij natuurlijk helemaal gelijk.
Den Haan's conclusie is slap:
"We’ve seen eight reasons why model-driven approaches can fail to make their promises come true. It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE."
De hamvraag is natuurlijk: als die 8 risico's er inderdaad zijn (en ik denk dat Den Haan daarin ruwweg wel gelijk heeft), heeft MDE dan eigenlijk wel kans van slagen? De titel van zijn artikel suggereert dat Den Haan daarover sceptisch is, maar hij geeft zelf geen antwoord op de vraag.
En ik doe dat ook even niet, want ik kom erop terug. :)
De 8 redenen zijn ook meer 8 grote risico's, en in zijn schets daarvan heeft hij wel gelijk. Ik zal ze even nalopen.
1. De gangbare MDE-aanpakken en -tools zijn vrijwel uitsluitend gericht op het korte termijn doel van verhoging van produktiviteit voor developers: meer functiepunten per uur, en verder niks.
Ja, dat is zo, en dat is inderdaad een van de grote tekortkomingen van de gebruikelijke aanpakken. Links laten liggen dus, en richten op waar het in MDE echt over gaat (vorige week blogde ik daarover ook al).
2. in MDE concentreert men zich meestal op slechts één modelleringsdimensie. Architectuur bijvoorbeeld wordt er bij de MDA aanpak een beetje bijgefrommeld in de PSM.
Inderdaad, dat lijkt nergens op. Den Haan is hier nog veel te voorzichtig: je hebt zowel binnen het domein als binnen de weergave van de technische architectuur en implementatie verscheidene modelleringsdimensies nodig.
Naar mijn idee is dat te doen met een goede modeltransformatieaanpak, maar simpel is het niet. Bovendien: hoeveel modeldimensies moeten we aankunnen?
3. de gangbare tools richten zich op het maken van nieuwe artefacten (stukken code, getransformeerde modellen, etc) en laten de problemen van aanpassing van bestaande artefacten links liggen.
Den Haan heeft hier ongetwijfeld gelijk, maar ik denk dat hij hier de zaak wat complexer maakt dan strikt nodig is. Immers, als je afgeleide artefacten 100% kunt genereren, kun je ook zelfs voor een kleine wijziging de hele zwik van (tussen)modellen, code, enzovoort gewoon opnieuw maken. Daar zitten nadelen en beperkingen aan (zoals de veteranen uit de CBD-hoek weten), maar je komt er wel een eind mee.
4. MDE richt zich teveel op General Purpose Languages zoals UML. Dat is niet voldoende: je hebt voor deelterreinen specifieke talen nodig. Het bekende DSL-lied.
Ja, dat is zo, maar ik denk wel dat in ieder geval als het gaat om business domeinen de combinatie van "gewoon" UML, analyse patronen (archetypes) en een abstractiemechanisme waarmee specifieke modellen van meer generieke patronen kunnen worden afgeleid heel veel helpt. Je kunt dan natuurlijk zo'n analyse-patroon of een bepaalde afleiding als een DSL zien.
Zie ook hier en hier en hier.
5. Zelf ontworpen DSL's zullen een chaos creëren.
Ja, dat ben ik helemaal met Den Haan eens. Voor mij is dat ook een reden om meer van archetypes gebruik te maken. Die zijn geschreven in UML, en dus veel makkelijker te begrijpen en te integreren.
6. Niet volledig executeerbare modeltransformaties zijn een bedreiging. Ja, dat is zeker zo. He treurige gehannes met PIM en PSM in veel MDA tools is daarvan trouwens een voorbeeld (Den Haan noemt het niet).
7. Modellen kunnen meestal neit of slechts zeer moeizaam op modelnivo worden getest. Dat is natuurlijk een probleem, want de enige manier om te testen is dan; eerst alles uitgenereren (aangenomen dat dat kan), en dan testen. Maar dat maakt het natuurlijk erg onhandig om zo fouten en onvolledigheden in het model op te sporen.
8. Tooling is onvoldoende. Den Haan geeft als voorbeeld de debugger die in de modelleeromgeving meestal afwezig is. En ook hier heeft hij natuurlijk helemaal gelijk.
Den Haan's conclusie is slap:
"We’ve seen eight reasons why model-driven approaches can fail to make their promises come true. It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE."
De hamvraag is natuurlijk: als die 8 risico's er inderdaad zijn (en ik denk dat Den Haan daarin ruwweg wel gelijk heeft), heeft MDE dan eigenlijk wel kans van slagen? De titel van zijn artikel suggereert dat Den Haan daarover sceptisch is, maar hij geeft zelf geen antwoord op de vraag.
En ik doe dat ook even niet, want ik kom erop terug. :)
Abonneren op:
Posts (Atom)