Een aardig verhaal van Tim Berners-Lee over Web 3.0, het Semantische Web. Het lijkt allemaal nogal vergezocht, abstract en theoretisch, maar ik denk dat het in veel opzichten veel dichterbij en ook veel relevanter is dan doorgaans wordt gedacht.
Want de steeds verdergaande ontkoppeling tussen het ding of concept waarover we praten, en de weerspiegeling daarvan in bits, maakt het nodig om in termen van een abstract model (dat wil zeggen: los van de "implementatie") over de dingen te kunnen spreken, en ze ook in termen van dat model te kunnen manipuleren. SaaS maakt dat, omdat je bij SaaS vaak eigenlijk geen idee meer hebt hoe een en ander is geimplementeerd in datamodellen en in software, laat staan waar het op welk platform draait, des te meer nodig.
Maar gelukkig hebben we daarvoor ook de middelen, in ieder geval waar het business zaken betreft. UML, MOF, MDA, etc bieden een toolbox die iig een goed startpunt is.
Posts tonen met het label ontology. Alle posts tonen
Posts tonen met het label ontology. Alle posts tonen
donderdag 22 november 2007
maandag 12 november 2007
Ministerie van Waarheid en Betekenis
Tim O'Reilly is kritisch over OpenSocial. Zijn punt: OpenSocial is een API, terwijl wat je nodig hebt juist uitwisselbaarheid van data is. O'Reilly's kritiek in deze op OpenSocial is niet helemaal terecht, en daarop wordt hij in de reacties ook gewezen. En O'Reilly erkent dat ook.
Maar wat breder bezien (afgezien dus van OpenSocial) heeft O'Reilly wel een punt. Het gaat inderdaad om de gegevens, en de uitwisseling daarvan. Of wat preciezer gezegd: om de objecten, dat wil zeggen: groepen gegevens met een beschreven duidelijke betekenis, en een bekende samenhang met andere (groepen) gegevens. Hiervoor is natuurlijk een soort betekenis-standaardisatie nodig. En hier komen ongetwijfeld begrippen als (web) ontology, metamodeling, etc om de hoek kijken. Dat is duidelijk.
Hoe gaan die standaarden er komen? Zal er een soort wereldwijd Ministerie van Waarheid en Betekenis komen, ongetwijfeld onder auspiciën van de OMG, of zal Microsoft weer eens wat roepen?
Geen van beide natuurlijk. Dat Ministerie zal er niet komen, OMG of niet, en Microsoft is als het om de wereld van services enzo gaat, snel bezig een also-ran te worden. Maar er zijn legio andere bedrijven die graag de dominante positie van Microsoft willen overnemen. Om te beginnen natuurlijk het alomtegenwoordige Google. En voor wat betreft deelgebieden is er bijvoorbeeld SAP als het om ERP-services gaat, en bijvoorbeeld Amazon als het gaat om platform-services zoals Payments (het elegante Amazon FPS).
Maar de kans dat een dergelijke industriestandaard snel een echte 100% standaard zal zijn is klein. Is dat erg? Ik denk het niet, zolang maar duidelijk is waar de standaarden op een bepaald gebied zich van elkaar onderscheiden. Het is niet erg dat er bv een Payment standaard van Amazon is, en een andere van bv PayPal, zolang maar duidelijk is wat de verschillen zijn, en hoe die eventueel overbrugd kunnen worden.
Daarvoor zijn abstracte modellen (vaak ten onrechte metamodellen genoemd) nodig. In dergelijke modellen zal een bedrijf zijn business modelleren, en vervolgens mappen op de modellen van de Googles, Amazons, SAPs, Oracles, SalesForces, en ook Microsofts van deze wereld. Die modellen zullen "vanzelf" ontstaan als best practices voor een bepaald soort domein, en snel worden verspreid in de IT-industrie, zoals dat altijd is gegaan.
Maar wat breder bezien (afgezien dus van OpenSocial) heeft O'Reilly wel een punt. Het gaat inderdaad om de gegevens, en de uitwisseling daarvan. Of wat preciezer gezegd: om de objecten, dat wil zeggen: groepen gegevens met een beschreven duidelijke betekenis, en een bekende samenhang met andere (groepen) gegevens. Hiervoor is natuurlijk een soort betekenis-standaardisatie nodig. En hier komen ongetwijfeld begrippen als (web) ontology, metamodeling, etc om de hoek kijken. Dat is duidelijk.
Hoe gaan die standaarden er komen? Zal er een soort wereldwijd Ministerie van Waarheid en Betekenis komen, ongetwijfeld onder auspiciën van de OMG, of zal Microsoft weer eens wat roepen?
Geen van beide natuurlijk. Dat Ministerie zal er niet komen, OMG of niet, en Microsoft is als het om de wereld van services enzo gaat, snel bezig een also-ran te worden. Maar er zijn legio andere bedrijven die graag de dominante positie van Microsoft willen overnemen. Om te beginnen natuurlijk het alomtegenwoordige Google. En voor wat betreft deelgebieden is er bijvoorbeeld SAP als het om ERP-services gaat, en bijvoorbeeld Amazon als het gaat om platform-services zoals Payments (het elegante Amazon FPS).
Maar de kans dat een dergelijke industriestandaard snel een echte 100% standaard zal zijn is klein. Is dat erg? Ik denk het niet, zolang maar duidelijk is waar de standaarden op een bepaald gebied zich van elkaar onderscheiden. Het is niet erg dat er bv een Payment standaard van Amazon is, en een andere van bv PayPal, zolang maar duidelijk is wat de verschillen zijn, en hoe die eventueel overbrugd kunnen worden.
Daarvoor zijn abstracte modellen (vaak ten onrechte metamodellen genoemd) nodig. In dergelijke modellen zal een bedrijf zijn business modelleren, en vervolgens mappen op de modellen van de Googles, Amazons, SAPs, Oracles, SalesForces, en ook Microsofts van deze wereld. Die modellen zullen "vanzelf" ontstaan als best practices voor een bepaald soort domein, en snel worden verspreid in de IT-industrie, zoals dat altijd is gegaan.
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.
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)