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.