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.