Op SaaSblogs dit stuk over de nadelen van SaaS. Vanuit de klant en vanuit de leverancier.
Het interessantst is, lijkt mij, het veronderstelde risico dat als de leverancier kopje onder gaat, de klant zijn gegevens kwijt is.
Mij lijkt dat niet nodig. De klant moet een copie van zijn gegevens krijgen wanneer hij dat wil. Dat is op zichzelf niet voldoende, want hij moet ook nog iets aankunnen met die gegevens. Daarom moeten ze voldoen aan een beschrijving die de gegevens begrijpelijk maakt, en liefst ook portable naar een andere omgeving.
Dit is één van de punten waar SaaS een model-gedreven benadering (MDA, MDD, MDE, MDSD, of hoe je het ook noemt) nodig heeft.
Posts tonen met het label SaaSaaS. Alle posts tonen
Posts tonen met het label SaaSaaS. Alle posts tonen
vrijdag 26 oktober 2007
maandag 1 oktober 2007
BPM en de architectureluur
Een vraag:
"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.
De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."
Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.
Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.
Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.
Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.
Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.
Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.
In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.
Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.
Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.
Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.
"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.
De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."
Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.
Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.
Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.
Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.
Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.
Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.
In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.
Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.
Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.
Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.
donderdag 30 augustus 2007
Functionaliteit uit de muur
Wat is de consequentie van SaaS?
Goed beschouwd dit: IT, althans de gangbare business-functionaliteit, komt "uit de muur". Binnenkort dankzij SaaS zowat letterlijk, maar nu al figuurlijk. Je kunt voor een zeer lage prijs de "standaard" (wat is die standaard?) business functionaliteit kopen. SaaS, Internet, outsourcing, standaardpakketten, open source, en ook zaken als virtualisatie en grid computing werken wat dat betreft allemaal dezelfde richting uit. En het spoort ook met de neiging van bedrijven om alleen te investeren in hun echte core. IT, zelfs business functionaliteit hoort daar goed beschouwd zelden bij.
Maw: IT, althans dat deel ervan, wordt of is een "commodity", en dat betekent dat er nauwelijks een concurrentie-voordeel mee te behalen valt, in ieder geval niet op langere termijn. Dus doen bedrijven er verstandig aan om IT zoveel mogelijk als een kostenpost, een soort infrastructuur, te zien. Wellicht ten overvloede: het gaat dan niet alleen om de hardware (computers, kabels, routers, etc) en de systeem-software, maar ook om de business-software zelf.
Er valt natuurlijk met een nieuwe business-toepassing (meestal een herschikking van bestaande functies, of een beter UI op die functies) wel degelijk voordeel te behalen, maar dat zal in de praktijk heel snel worden nagemaakt door de concurrenten. (Ik heb een keer vernomen dat in de financiele wereld een nieuw produkt hooguit anderhalf jaar voorsprong geeft, meestal veel korter.)
De consequenties voor de IT-industrie zijn natuurlijk groot. De fictie van het bedrijfsspeciefieke maatwerk kan aan het gas (eindelijk, eindelijk. Altijd al kletskoek geweest), en de eigen IT-ontwikkeling van bedrijven is alleen maar een duur blok aan het been. Dus outsourcen die handel, en weg met die licenties!
Maar dat uitdijende heelal van services, geoutsourcede systemen, etc moet natuurlijk wel geprojecteerd worden op de business-functionaliteit van een bedrijf. Dat goed (dus: betrouwbaar, en dusdanig dat de wijze van implementatie echt irrelevant is) en goedkoop doen is ook een taak van IT.
En daarvoor is een forse omschakeling nodig. Want waar we eerst ons richtten op de code als referentiepunt en plaats van wijziging, kan dat nu niet meer. De code ligt in India, of is niet eens bekend omdat je een verscheidene service-leveranciers gebruikt, en hoe die eea gecodeerd hebben weet je niet, laat staan dt je bij die code kunt.
Maar hoe dan wel? Modellen. Die maken het mogelijk om volledig, exact en platform- en implementatie-onafhankelijk de business te beschrijven en bovendien (de functionaliteit van) de software te beschrijven, zelfs te genereren. Ze zijn dus een noodzakelijke koppeling tussen enerzijds de business en anderzijds de services en andere software die gebruikt worden
of kunnen worden.
Kan dat? Ja. We zijn inmiddels goed genoeg in het modelleren van domeinen dat we de business volledig en exact kunnen beschrijven. En het mooie van MDA/MDE is dat we de garantie hebben dat die modellen ook platformonafhankelijk kunnen worden gerealiseerd. We hoeven niet altijd gebruik te maken van die route (bij outsourcing bv kunnen de modellen als een "gewone" (maar wel volledige) specificatie dienen), maar het kan wel.
En die domein-modellen worden dus het "interface" tussen de gerealiseerde functionaliteit waar dan ook, en de business. Het stopcontact aan de muur, zogezegd.
Goed beschouwd dit: IT, althans de gangbare business-functionaliteit, komt "uit de muur". Binnenkort dankzij SaaS zowat letterlijk, maar nu al figuurlijk. Je kunt voor een zeer lage prijs de "standaard" (wat is die standaard?) business functionaliteit kopen. SaaS, Internet, outsourcing, standaardpakketten, open source, en ook zaken als virtualisatie en grid computing werken wat dat betreft allemaal dezelfde richting uit. En het spoort ook met de neiging van bedrijven om alleen te investeren in hun echte core. IT, zelfs business functionaliteit hoort daar goed beschouwd zelden bij.
Maw: IT, althans dat deel ervan, wordt of is een "commodity", en dat betekent dat er nauwelijks een concurrentie-voordeel mee te behalen valt, in ieder geval niet op langere termijn. Dus doen bedrijven er verstandig aan om IT zoveel mogelijk als een kostenpost, een soort infrastructuur, te zien. Wellicht ten overvloede: het gaat dan niet alleen om de hardware (computers, kabels, routers, etc) en de systeem-software, maar ook om de business-software zelf.
Er valt natuurlijk met een nieuwe business-toepassing (meestal een herschikking van bestaande functies, of een beter UI op die functies) wel degelijk voordeel te behalen, maar dat zal in de praktijk heel snel worden nagemaakt door de concurrenten. (Ik heb een keer vernomen dat in de financiele wereld een nieuw produkt hooguit anderhalf jaar voorsprong geeft, meestal veel korter.)
De consequenties voor de IT-industrie zijn natuurlijk groot. De fictie van het bedrijfsspeciefieke maatwerk kan aan het gas (eindelijk, eindelijk. Altijd al kletskoek geweest), en de eigen IT-ontwikkeling van bedrijven is alleen maar een duur blok aan het been. Dus outsourcen die handel, en weg met die licenties!
Maar dat uitdijende heelal van services, geoutsourcede systemen, etc moet natuurlijk wel geprojecteerd worden op de business-functionaliteit van een bedrijf. Dat goed (dus: betrouwbaar, en dusdanig dat de wijze van implementatie echt irrelevant is) en goedkoop doen is ook een taak van IT.
En daarvoor is een forse omschakeling nodig. Want waar we eerst ons richtten op de code als referentiepunt en plaats van wijziging, kan dat nu niet meer. De code ligt in India, of is niet eens bekend omdat je een verscheidene service-leveranciers gebruikt, en hoe die eea gecodeerd hebben weet je niet, laat staan dt je bij die code kunt.
Maar hoe dan wel? Modellen. Die maken het mogelijk om volledig, exact en platform- en implementatie-onafhankelijk de business te beschrijven en bovendien (de functionaliteit van) de software te beschrijven, zelfs te genereren. Ze zijn dus een noodzakelijke koppeling tussen enerzijds de business en anderzijds de services en andere software die gebruikt worden
of kunnen worden.
Kan dat? Ja. We zijn inmiddels goed genoeg in het modelleren van domeinen dat we de business volledig en exact kunnen beschrijven. En het mooie van MDA/MDE is dat we de garantie hebben dat die modellen ook platformonafhankelijk kunnen worden gerealiseerd. We hoeven niet altijd gebruik te maken van die route (bij outsourcing bv kunnen de modellen als een "gewone" (maar wel volledige) specificatie dienen), maar het kan wel.
En die domein-modellen worden dus het "interface" tussen de gerealiseerde functionaliteit waar dan ook, en de business. Het stopcontact aan de muur, zogezegd.
maandag 20 augustus 2007
BPM en agility
Goed stuk van Richard Veryard in CBDI Journal (link naar samenvatting). Veryard vestigt de aandacht op het feit dat toepassing van BPM en SOA zonder meer zeker niet de voordelen op het gebied van agility gaat opleveren die men er van verwacht.
Inderdaad. Zie ook SaaSaaS.
Inderdaad. Zie ook SaaSaaS.
vrijdag 3 augustus 2007
SaaSaaS (2)
SaaS is dus heel mooi, maar er zijn een aantal problemen en obstakels. Ik heb hiervoor een aantal genoemd (zie hier):
- er zijn standaards nodig, zowel op technisch als op "semantisch" (dwz: vwb het probleemdomein) gebied
- er is een manier van beschrijven van systemen nodig die het uitbesteden van systeemontwikkeling en -beheer, bv via outsourcing of offshoring makkelijker maakt
- de wijze van specificeren moet ervoor zorgen dat de problemen voortvloeiende uit "glue code" zoveel mogelijk worden vermeden
- er moet een manier zijn om bestaande software (legacy) in de SaaS-opzet te betrekken.
Is dat mogelijk? Ja, ik denk het wel.
We zijn al een heel stuk verder als we een (abstracte) taal hebben, die het mogelijk maakt een probleem domein (bijvoorbeeld een business-domein) te beschrijven to the point en zonder redundantie. Voorts moeten we in staat zijn een beschrijving in die taal te gebruiken voor een implementatie, zonder dat nadere informatie nodig is. Je kunt een specificatie dan gebruiken voor een automatische implementatie, maar ook voor de specificatie van een extern (bv via outsourcing) te realiseren systeem. De taal moet dus onafhankelijk zijn van de wijze van implementatie, maar ook van het platform van implementatie. Zo wordt lock-in vermeden. En de taal moet geschikt zijn om bestaande legacy-software in te beschrijven, alsmede "semantische" standaarden bevatten of in ieder geval mogelijk maken.
Zo, dat is nogal wat. Maar het kan wel. We zijn er in ieder geval vlak bij.
Voor de domeinbeschrijving is het mogelijk om met OO en UML een heel eind te komen. Inderdaad, UML is niet helemaal niet compleet: de beschrijving van gedrag is moeilijk, en UML bevat ook veel overbodige onzin (use cases!), maar die hoef je natuurlijk niet te gebruiken. Maar de basis is er, en met goed gekozen aanvullingen is OO-UML bruikbaar.
Die aanvullingen liggen op de volgende gebieden:
- beschrijving gedrag. UML is hiervoor onvoldoende. Er is een Action Language (een soort pseudo-code) nodig om gedragsbeschrijvingen bruikbaar te maken. Een subset van een gewone programmeertaal (bv Java of Ruby) is afdoende.
- een standaard voor het koppelen van de domeinmodellen. Een aspect van een domein wordt apart beschreven (later daarover meer), maar om een domein compleet te beschrijven is in feite een soort "meta-taal" nodig die beschrijft hoe modellen met elkaar samen (kunnen) hangen. Aspect-orientatie, MDSM, MDE en ook technieken als UML with color bieden bieden hiervoor mogelijkheden.
- een standaard semantiek die de gebruikte concepten beschrijft op een dusdanige wijze dat ze over de (deel)domeinen hetzelfde zijn. Voor SaaS is dat utieraard cruciaal. Hiervoor zijn verscheidene aanzetten, waarvan sommige varen onder de prachtige vlag van de "web ontology". Schitterend buzzword. Het is verstandig om een schuin oog op deze ontwikkelingen gericht te houden, maar het is niet nodig om erop te wachten. In de prakiek zijn allen OO-standaardmodellen voor business-domeinen ongeveer hetzelfde, en iig makkelijk naar elkaar te transformeren.
- eventueel kunnen naast UML DSLs gebruikt worden voor specfieke deelterreinen, zolang de koppeling met UML maar te maken is. Een voorbeeld hiervan is BPMN voor het modelleren van processen.
Wat wel van belang is; als uitbreidingen worden gemaakt, dan is het wijs om daarbij binnen de grenzen van de MOF te blijven. Dan is de koppeling naar MDE en MDA betrekkelijk makkelijk te maken. En er moet voor gezorgd worden dat de gebruikte modelleertalen en -technieken open zijn, zodat de resulterende artefacten (de modellen dus) hun waarde behouden, en niet geboden zijn aan een of andere esoterische aanpak, die niemand meer snapt na het vertrek van de goeroe van dienst.
Datzelfde (vermijding van lock-in) is nog belangrijker als het gaat om de verwerking van die modellen. Dat kan grofweg op twee manieren; handmatig, of geautomatiseerd via de MDA/MDE-route. Of een combinatie.
Eigenlijk maakt het niet zoveel uit of hoe het gebeurt. Want in beide gevallen moet de specificatie precies en volledig zijn. Bij een automatsiche realisatie is dat evident, maar bij een handmatige is het ook essentieel, omdat die steeds meer elders (in India of waar dan ook) plaatsvindt. De dagen van de halfzachte analyse, waarbij een groot deel van de specificatie in de bouwfase werd gemaakt (met alle problemen van dien) zijn over. Dat stelt duidelijk andere eisen aan de wijze van specificeren en analyseren dan we gewend zijn.
Bij een automatische realisatie is het cruciaal dat de modellen NIET op het MDA-traject zijn toegesneden. Zijn ze dat wel, dan zijn ze in feite tool-afhankelijk geworden, waarmee toch lock-in het resultaat zou zijn. En dat mag niet. Het MDA/MDE-proces dient dus zo te zijn opgezet, dat de platform- en toolonafhankelijkheid van de domeinmodellen verzekerd is, terwijl ze wel compleet zijn. (Dit sluit in de praktijk en aantal MDA-tools uit, omdat daar de PSM gebruikt wordt zowel voor platformspecifieke zaken als voor detaillering van het business-domein. Dat is belachelijk, en die tools dienen vermeden te worden.)
In de praktijk zal de realisatie in een aantal transformatie-stappen plaatsvinden, volgens het DAI-principe (Domein, Architectuur, Implementatie). De MDSD-aanpak voldoet min of meer hieraan, en er zijn inmiddels ook verscheidene tools die een voldoende flexibele M2M transformatie bieden (Borland, OAW, MIA, ArcStyler nb lijken alle bruikbaar). Een van de lastige dingen is ongetwijfeld het noodzakelijke "weaven" van deel-modellen. In de meeste MDA-aanpakken zit dat (nog) niet verwerkt, maar het is wel nodig. Gelukkig biedt hier Aspect-Orientatie (AOP, AOSD) oplossingen, en AOSD moet ook in de MDE-techniek geintegreerd worden. (MDSD doet dat trouwens ook.)
De werkwijze en inrichting van het transformatieproces moet natuurlijk flexibel maar ook open zijn, dit laatste om portabiliteit van het ene naar het andere tool mogelijk te maken. Als een transformatieproces een balck box is, is dat natuurlijk heel lastig, maar als duidelijk is hoe het werkt, is een overzetting naar een ander tool wel haalbaar. Sterker: als de trnasformaties zijn beschreven in de QVT-standaard (als dat inderdaad de standaard wordt), zijn ze waarschijnlijk herbruikbaar.
Het doel is hier: zoveel mogelijk abstractie van de concrete tooling. De MDA-standaard zou dit mogelijk moeten maken, maar het zal nog wl even duren eer die MDA-transformaties echt een "commodity" zijn geworden, en de tooling er niet meer toe doet.
We zijn eruit: dit is de oplossing. :)
De volgende keer over de IT-organisatie, SaaS en SaaSaaS. En ik zal ook een aantal thema's die hierboven zijn aangeroerd, uitdiepen.
Bijvoorbeeld:
- hoe moet je domeinmodelleren om dit alles mogelijk te maken?
- wat zijn de mogelijkheden en onmogelijkheden van UML?
- wat moeten we met DSLs?
- past legacy hier wel in, en zo ja, hoe dan?
Dat komt dus nog.
- er zijn standaards nodig, zowel op technisch als op "semantisch" (dwz: vwb het probleemdomein) gebied
- er is een manier van beschrijven van systemen nodig die het uitbesteden van systeemontwikkeling en -beheer, bv via outsourcing of offshoring makkelijker maakt
- de wijze van specificeren moet ervoor zorgen dat de problemen voortvloeiende uit "glue code" zoveel mogelijk worden vermeden
- er moet een manier zijn om bestaande software (legacy) in de SaaS-opzet te betrekken.
Is dat mogelijk? Ja, ik denk het wel.
We zijn al een heel stuk verder als we een (abstracte) taal hebben, die het mogelijk maakt een probleem domein (bijvoorbeeld een business-domein) te beschrijven to the point en zonder redundantie. Voorts moeten we in staat zijn een beschrijving in die taal te gebruiken voor een implementatie, zonder dat nadere informatie nodig is. Je kunt een specificatie dan gebruiken voor een automatische implementatie, maar ook voor de specificatie van een extern (bv via outsourcing) te realiseren systeem. De taal moet dus onafhankelijk zijn van de wijze van implementatie, maar ook van het platform van implementatie. Zo wordt lock-in vermeden. En de taal moet geschikt zijn om bestaande legacy-software in te beschrijven, alsmede "semantische" standaarden bevatten of in ieder geval mogelijk maken.
Zo, dat is nogal wat. Maar het kan wel. We zijn er in ieder geval vlak bij.
Voor de domeinbeschrijving is het mogelijk om met OO en UML een heel eind te komen. Inderdaad, UML is niet helemaal niet compleet: de beschrijving van gedrag is moeilijk, en UML bevat ook veel overbodige onzin (use cases!), maar die hoef je natuurlijk niet te gebruiken. Maar de basis is er, en met goed gekozen aanvullingen is OO-UML bruikbaar.
Die aanvullingen liggen op de volgende gebieden:
- beschrijving gedrag. UML is hiervoor onvoldoende. Er is een Action Language (een soort pseudo-code) nodig om gedragsbeschrijvingen bruikbaar te maken. Een subset van een gewone programmeertaal (bv Java of Ruby) is afdoende.
- een standaard voor het koppelen van de domeinmodellen. Een aspect van een domein wordt apart beschreven (later daarover meer), maar om een domein compleet te beschrijven is in feite een soort "meta-taal" nodig die beschrijft hoe modellen met elkaar samen (kunnen) hangen. Aspect-orientatie, MDSM, MDE en ook technieken als UML with color bieden bieden hiervoor mogelijkheden.
- een standaard semantiek die de gebruikte concepten beschrijft op een dusdanige wijze dat ze over de (deel)domeinen hetzelfde zijn. Voor SaaS is dat utieraard cruciaal. Hiervoor zijn verscheidene aanzetten, waarvan sommige varen onder de prachtige vlag van de "web ontology". Schitterend buzzword. Het is verstandig om een schuin oog op deze ontwikkelingen gericht te houden, maar het is niet nodig om erop te wachten. In de prakiek zijn allen OO-standaardmodellen voor business-domeinen ongeveer hetzelfde, en iig makkelijk naar elkaar te transformeren.
- eventueel kunnen naast UML DSLs gebruikt worden voor specfieke deelterreinen, zolang de koppeling met UML maar te maken is. Een voorbeeld hiervan is BPMN voor het modelleren van processen.
Wat wel van belang is; als uitbreidingen worden gemaakt, dan is het wijs om daarbij binnen de grenzen van de MOF te blijven. Dan is de koppeling naar MDE en MDA betrekkelijk makkelijk te maken. En er moet voor gezorgd worden dat de gebruikte modelleertalen en -technieken open zijn, zodat de resulterende artefacten (de modellen dus) hun waarde behouden, en niet geboden zijn aan een of andere esoterische aanpak, die niemand meer snapt na het vertrek van de goeroe van dienst.
Datzelfde (vermijding van lock-in) is nog belangrijker als het gaat om de verwerking van die modellen. Dat kan grofweg op twee manieren; handmatig, of geautomatiseerd via de MDA/MDE-route. Of een combinatie.
Eigenlijk maakt het niet zoveel uit of hoe het gebeurt. Want in beide gevallen moet de specificatie precies en volledig zijn. Bij een automatsiche realisatie is dat evident, maar bij een handmatige is het ook essentieel, omdat die steeds meer elders (in India of waar dan ook) plaatsvindt. De dagen van de halfzachte analyse, waarbij een groot deel van de specificatie in de bouwfase werd gemaakt (met alle problemen van dien) zijn over. Dat stelt duidelijk andere eisen aan de wijze van specificeren en analyseren dan we gewend zijn.
Bij een automatische realisatie is het cruciaal dat de modellen NIET op het MDA-traject zijn toegesneden. Zijn ze dat wel, dan zijn ze in feite tool-afhankelijk geworden, waarmee toch lock-in het resultaat zou zijn. En dat mag niet. Het MDA/MDE-proces dient dus zo te zijn opgezet, dat de platform- en toolonafhankelijkheid van de domeinmodellen verzekerd is, terwijl ze wel compleet zijn. (Dit sluit in de praktijk en aantal MDA-tools uit, omdat daar de PSM gebruikt wordt zowel voor platformspecifieke zaken als voor detaillering van het business-domein. Dat is belachelijk, en die tools dienen vermeden te worden.)
In de praktijk zal de realisatie in een aantal transformatie-stappen plaatsvinden, volgens het DAI-principe (Domein, Architectuur, Implementatie). De MDSD-aanpak voldoet min of meer hieraan, en er zijn inmiddels ook verscheidene tools die een voldoende flexibele M2M transformatie bieden (Borland, OAW, MIA, ArcStyler nb lijken alle bruikbaar). Een van de lastige dingen is ongetwijfeld het noodzakelijke "weaven" van deel-modellen. In de meeste MDA-aanpakken zit dat (nog) niet verwerkt, maar het is wel nodig. Gelukkig biedt hier Aspect-Orientatie (AOP, AOSD) oplossingen, en AOSD moet ook in de MDE-techniek geintegreerd worden. (MDSD doet dat trouwens ook.)
De werkwijze en inrichting van het transformatieproces moet natuurlijk flexibel maar ook open zijn, dit laatste om portabiliteit van het ene naar het andere tool mogelijk te maken. Als een transformatieproces een balck box is, is dat natuurlijk heel lastig, maar als duidelijk is hoe het werkt, is een overzetting naar een ander tool wel haalbaar. Sterker: als de trnasformaties zijn beschreven in de QVT-standaard (als dat inderdaad de standaard wordt), zijn ze waarschijnlijk herbruikbaar.
Het doel is hier: zoveel mogelijk abstractie van de concrete tooling. De MDA-standaard zou dit mogelijk moeten maken, maar het zal nog wl even duren eer die MDA-transformaties echt een "commodity" zijn geworden, en de tooling er niet meer toe doet.
We zijn eruit: dit is de oplossing. :)
De volgende keer over de IT-organisatie, SaaS en SaaSaaS. En ik zal ook een aantal thema's die hierboven zijn aangeroerd, uitdiepen.
Bijvoorbeeld:
- hoe moet je domeinmodelleren om dit alles mogelijk te maken?
- wat zijn de mogelijkheden en onmogelijkheden van UML?
- wat moeten we met DSLs?
- past legacy hier wel in, en zo ja, hoe dan?
Dat komt dus nog.
donderdag 2 augustus 2007
SaaS en SOA, hypes die voorbijgaan?
Will SOA still be ‘SOA’ five years from now?
Nee, zegt Joe McKendrick. SOA zal alomtegenwoordig zijn, net als GUIs dat al zijn, en Webservices bezig zijn het te worden.
Hij heeft daarin gelijk, maar er is nog een andere reden waarom SOA snel weer hype-af zal zijn. De SOA hype is een interne IT-hype, eigenlijk alleen interessant voor software-architecten, developers, etc. SOA is een architectuur die "services" mogelijk maakt (en zelfs dat is niet helemaal waar: het is mogelijk services te leveren of zelfs te consumeren zonder een echte SOA). Maar een SOA brengt helemaal neit noodzakelijk gebruik of beschikbaarstelling van services as vanzelf met zich mee, laat staan dat dat zal leiden tot de business-voordelen die klanten wordt beloofd.
SOA is eigenlijk het zoveelste voorbeeld waarbij een technische vernieuwing zonder meer als een business-voordeel wordt verkocht. De pretentie wordt natuurlijk niet waargemaakt, en vervolgens zijn we verbaasd als men cynisch wordt over de prachtige vergezichten die door de IT steeds worden geschilderd.
SaaS is een echte belofte, voor de business, en vooral voor de organisatie (en daarmee de kosten) van de IT. Om SaaS waar te kunnen maken, is er een SOA nodig. Dat is alles.
Link naar Phil Wainewright
Ik heb de blog van Phil Wainewright als link toegevoegd aan de link-lijst.
vrijdag 27 juli 2007
SaaSaaS (1)
Waarom heet deze blog SaaSaaS?
SaaS staat, zoals bekend, voor: Software as a Service. Software die door vele gebruikers als een service wordt aangeroepen, en waarbij de gebruiker dus niet meer de zorgen en de kosten van het beheer (zowel mbt hardware als mbt software) heeft, niet meer verantwoordelijk is voor het design, en eigenlijk alleen nog maar "aan het net" hoeft te zitten om te kunnen werken. Een prachtig toekomst-perspectief, zij het met een paar kanttekeningen (waarover verderop).
SaaSaaS staat voor Software as a Service as a Service. Want om de voordelen van SaaS te kunnen uitbuiten, en de nadelen te vermijden, moet er niet alleen een geschikte infrastructuur zijn (daarop focust men zich nu), maar moet ook de manier waarop IT georganiseerd is en gebruikt wordt veranderen.
Maar eerst de obstakels voor SaaS. Het belangrijkste obstakel is natuurlijk: legacy. Vrijwel alle bedrijven, van groot tot klein, gebruiken allang software, in ieder geval voor hun meest cruciale functies. Dat kan zelfgebouwde software zijn, het kan een pakket zijn, het kan brandnieuw zijn, het kan stokoud zijn. In al die gevallen is de combinatie met SaaS moeilijk. Want in die software zitten de voor het bedrijf specifieke "business rules" verpakt, en het gebruik van een externe service zal niet precies hetzelfde doen. En toch is dat wel de bedoeling. Natuurlijk, in theorie kan bestaande software gebruik maken van een externe service, of zelf als service beschikbaar worden gesteld. Maar dat is theorie. Technisch komen we er nog wel uit, maar op "logisch" niveau is het in de praktijk heel lastig. Want wat zijn eigenlijk die "business rules"? En waar moeten we dan de bestaande software "openknippen" om services te kunnen gebruiken of beschikbaar te stellen?
Een tweede obstakel voor SaaS wordt, merkwaardig genoeg, gevormd door een andere vrij nieuwe ontwikkeling: outsourcing en offshoring. Op het eerste gezicht is dat juist een ontwikkeling die hand in hand zou moeten gaan met SaaS, en tot op zekere hoogte is dat ook inderdaad het geval. Immers: door outsourcing zou het makkelijker moeten zijn om software tussen bedrijven te delen (bijvoorbeeld als service), en offshoring bestaat juist bij de gratie van het gebruik van het net. Dat spoort toch mooi met SaaS?
Ja, dat is wel zo, maar toch is er een probleem. Om iets aan SaaS te hebben, moet de bestaande software omgebouwd worden naar een voor SaaS geschikte opzet. Dat is al lastig als de software in eigen beheer is, maar als het beheer bij een andere partij ligt, wordt het nog moeilijker te organiseren. En als het een pakket is, ben je volkomen afhankelijk van de leverancier.
Er zijn nog twee risico's aan SaaS die aandacht behoeven.
Allereerst is daar het "glue-issue". De SaaS-services op zichzelf hebben meestal niet veel nut. Ze moeten aan elkaar worden gekoppeld, bijvoorbeeld in een user interface (bv een mashup) of een business process (bv een workflow geschreven in BPEL). Als de services perfect passen, is er niets aan de hand. Maar meestal zullen de services niet precies passen, en moet er extra "glue-code" worden geschreven om de services goed te laten samenwerken. De kans is groot dat daarin business-logica terecht zal komen (zeker bij proces-logica) en de kans is ook groot dat die logica redundant zal zijn, dwz: dezelfde logica komt op meer plaatsen in de code voor. Dit leidt al snel tot chaos, en inderdaad is de resulterende spaghetti-code ook al in SOA-trajecten te herkennen.
Een tweede punt is standaardisatie. Op "technisch" nivo is die in de SaaS- en SOA-wereld redelijk goed geregeld. Maar op "logisch" nivo nog niet. Als twee services met elkaar samenwerken en allebei de "Klant" gebruiken, is het wel van belang dat het begrip "Klant" voor beide services hetzelfde betekent. Conclusie: we hebben standaardisatie van begrippen (of concepten) nodig. Zonder dat zal Saas voor de business uitlopen op een babylonische spraakverwarring.
Wat we dus nodig hebben om de belofte van SaaS in te lossen, is in ieder geval een oplossing voor de integratie van legacy, voor het "glue-issue", en voor de standaardisering van begrippen.
Gelukkig zijn er in de IT altijd wel hypes en buzzwords die te hulp schieten: bijvoorbeeld MDA, MDE en Ontology. In een volgende post: hoe die samenwerken in SaaSaaS en waarom dat de geschetste problemen oplost.
SaaS staat, zoals bekend, voor: Software as a Service. Software die door vele gebruikers als een service wordt aangeroepen, en waarbij de gebruiker dus niet meer de zorgen en de kosten van het beheer (zowel mbt hardware als mbt software) heeft, niet meer verantwoordelijk is voor het design, en eigenlijk alleen nog maar "aan het net" hoeft te zitten om te kunnen werken. Een prachtig toekomst-perspectief, zij het met een paar kanttekeningen (waarover verderop).
SaaSaaS staat voor Software as a Service as a Service. Want om de voordelen van SaaS te kunnen uitbuiten, en de nadelen te vermijden, moet er niet alleen een geschikte infrastructuur zijn (daarop focust men zich nu), maar moet ook de manier waarop IT georganiseerd is en gebruikt wordt veranderen.
Maar eerst de obstakels voor SaaS. Het belangrijkste obstakel is natuurlijk: legacy. Vrijwel alle bedrijven, van groot tot klein, gebruiken allang software, in ieder geval voor hun meest cruciale functies. Dat kan zelfgebouwde software zijn, het kan een pakket zijn, het kan brandnieuw zijn, het kan stokoud zijn. In al die gevallen is de combinatie met SaaS moeilijk. Want in die software zitten de voor het bedrijf specifieke "business rules" verpakt, en het gebruik van een externe service zal niet precies hetzelfde doen. En toch is dat wel de bedoeling. Natuurlijk, in theorie kan bestaande software gebruik maken van een externe service, of zelf als service beschikbaar worden gesteld. Maar dat is theorie. Technisch komen we er nog wel uit, maar op "logisch" niveau is het in de praktijk heel lastig. Want wat zijn eigenlijk die "business rules"? En waar moeten we dan de bestaande software "openknippen" om services te kunnen gebruiken of beschikbaar te stellen?
Een tweede obstakel voor SaaS wordt, merkwaardig genoeg, gevormd door een andere vrij nieuwe ontwikkeling: outsourcing en offshoring. Op het eerste gezicht is dat juist een ontwikkeling die hand in hand zou moeten gaan met SaaS, en tot op zekere hoogte is dat ook inderdaad het geval. Immers: door outsourcing zou het makkelijker moeten zijn om software tussen bedrijven te delen (bijvoorbeeld als service), en offshoring bestaat juist bij de gratie van het gebruik van het net. Dat spoort toch mooi met SaaS?
Ja, dat is wel zo, maar toch is er een probleem. Om iets aan SaaS te hebben, moet de bestaande software omgebouwd worden naar een voor SaaS geschikte opzet. Dat is al lastig als de software in eigen beheer is, maar als het beheer bij een andere partij ligt, wordt het nog moeilijker te organiseren. En als het een pakket is, ben je volkomen afhankelijk van de leverancier.
Er zijn nog twee risico's aan SaaS die aandacht behoeven.
Allereerst is daar het "glue-issue". De SaaS-services op zichzelf hebben meestal niet veel nut. Ze moeten aan elkaar worden gekoppeld, bijvoorbeeld in een user interface (bv een mashup) of een business process (bv een workflow geschreven in BPEL). Als de services perfect passen, is er niets aan de hand. Maar meestal zullen de services niet precies passen, en moet er extra "glue-code" worden geschreven om de services goed te laten samenwerken. De kans is groot dat daarin business-logica terecht zal komen (zeker bij proces-logica) en de kans is ook groot dat die logica redundant zal zijn, dwz: dezelfde logica komt op meer plaatsen in de code voor. Dit leidt al snel tot chaos, en inderdaad is de resulterende spaghetti-code ook al in SOA-trajecten te herkennen.
Een tweede punt is standaardisatie. Op "technisch" nivo is die in de SaaS- en SOA-wereld redelijk goed geregeld. Maar op "logisch" nivo nog niet. Als twee services met elkaar samenwerken en allebei de "Klant" gebruiken, is het wel van belang dat het begrip "Klant" voor beide services hetzelfde betekent. Conclusie: we hebben standaardisatie van begrippen (of concepten) nodig. Zonder dat zal Saas voor de business uitlopen op een babylonische spraakverwarring.
Wat we dus nodig hebben om de belofte van SaaS in te lossen, is in ieder geval een oplossing voor de integratie van legacy, voor het "glue-issue", en voor de standaardisering van begrippen.
Gelukkig zijn er in de IT altijd wel hypes en buzzwords die te hulp schieten: bijvoorbeeld MDA, MDE en Ontology. In een volgende post: hoe die samenwerken in SaaSaaS en waarom dat de geschetste problemen oplost.
Abonneren op:
Posts (Atom)