Ecosystemen, integratie en softwarehouses

Afgelopen week heb ik de SIIA On Demand conferentie in Amsterdam bezocht.

Twee kreten kwamen vaak terug: "ecosystem" en "integration". Die hebben met elkaar te maken, maar laten we beginnen met integratie.

Bij integratie op het gebied van SaaS gaat het eigenlijk om drie soorten integratie:
1. integratie van SaaS-services onderling in het user-interface. Een vorm daarvan is de bekende mashup, waarbij in het user-interface enkele services (bijvoorbeeld een routeplanner en Buienradar) worden samengevoegd.

2. integratie van SaaS-services met eigen (legacy-)software (zoals ooit ontwikkelde maatwerksystemen) of met gekochte pakketten (zoals SAP of Office).

3. integratie van SaaS-services "aan de achterkant", bijvoorbeeld een factureringservice van Salesforce.com, de betaalservice FPS van Amazon en een boekhoudservice van Business ByDesign (de uitgestelde SaaS-variant van SAP).

Door IT-ers wordt de eerste vorm (user-interface mashups) niet erg interessant gevonden. Immers, business-processen spelen geen rol bij Buienradar, dus dit is leuk voor fröbelende webdesigners en andere dameskappers, maar voor serieuze IT-ers is het niet van belang. (Ik denk dat dit een misvatting is, maar dat doet er nu niet zoveel toe.)

De tweede en derde vorm van integratie lijken vanuit het perspectief van de softwareontwikkeling en de IT-sector erg op elkaar. In beide gevallen moet data geconverteerd worden, moeten services worden aangeroepen, enzovoort. En inderdaad: tussen de koppeling van als service beschikbare legacy software en een SaaS-service enerzijds en tussen twee SaaS-services anderzijds bestaat geen verschil. Tenminste: vanuit technisch perspectief.

En dus hebben de softwarehouses zichzelf weer eens opnieuw uitgevonden, en proclameert men dat men voortaan SaaS-services gaat integreren, dat de klanten daar erg veel behoefte aan hebben, en dat dit in feite vrijwel net zo veel werk met zich meebrengt als traditionele systeemontwikkeling.

Op korte termijn hebben ze hierin ongetwijfeld gelijk. Maar op wat langere termijn geloof ik er niks van. Waarom niet?

1. het grote voordeel van SaaS is het "functionaliteit-uit-de-muur"-effect. Standaardfucntionaliteit wordt gebruikt in de aangeboden vorm, en daardoor zijn de kosten van een fractie van die van zelf ontwikkelde en beheerde software. Bovendien hoeft er geen voorinvestering in de vorm van ontwikkelkosten, de aanschaf van een licentie of de aanschaf van servers betaald te worden.

Maar als je ten behoeve van die spotgoedkope SaaS-functionaliteit weer een hoop integratie-scripts en dergelijke moet gaan maken en onderhouden omdat anders de legacy niet meer werkt, schiet je jezelf in de voet. Want dat is weer gewoon maatwerk: hoge kosten, en in feite lock-in. Dit is niet een argument tegen SaaS, maar tegen legacy.

De tweede vorm van integratie (SaaS-legacy) moet dus tot een minimum worden beperkt: zo weinig mogelijk, zo simpel mogelijk. Ja, de softwarehouses hebben gelijk: integratie van SaaS met legacy is duur. Maar nee: dat zal (op iets langere termijn tenminste) niet leiden tot meer werk, maar tot vervroegde uitfasering van legacy-software.

2.voor de integratie van SaaS-services met elkaar zijn drie varianten waarneembaar.

a. ad hoc integratie van SaaS-services. De gebruiker van de klant integreert de SaaS-services met elkaar, op de manier zoals hij ze nodig heeft. Deze aanpak heeft uiteraard dezelfde nadelen als legacy-SaaS-integratie, en zal dan ook een kort leven beschoren zijn, en worden verdrongen door de volgende twee ontwikkelingen.

b. de "ecosystems" (het tweede buzzword van de conferentie): op de "grote platformen" zoals Salesforce.com en Amazon's AWS ontstaan een reeks van applicaties die gebruik maken van het platform en van elkaar om allerlei geïntegreerde functionaliteit aan de klant aan te bieden. Salesforce doet dat expliciet via Force.com, Amazon doet het impliciet door stapje voor stapje de voorwaarden voor het ontstaan van zo'n ecosysteem te scheppen. En Google doet iets dergelijks, en biedt via de AppEngine ook de mogelijkheid om het platform als ontwikkelplatform te gebruiken.

c. de integratie-services. Dat zijn in feite SaaS-toepassingen die SaaS-services van diverse pluimage en diverse platforms combineren en integreren. SaaSaaS dus. Een voorbeeld hiervan is RunMyProcess, en een ander DreamFactory (hoewel dat strikt genomen geen SaaS-service is, maar een te downloaden applicatie). Er wordt dan een soort virtueel ecosysteem gecreëerd. (Maar dat ecosysteem was toch al virtueel? Hmmmm.......)

Ik denk dat de varianten b en c van de SaaS-integratie in elkaar over zullen lopen. Vanuit de consument zal het niet veel uitmaken, zolang hij zijn doelen maar haalt: lage kosten, laag risico, geen lock-in. Variant a moet vermeden worden.

Vanuit het gezichtspunt van een softwarehouse zijn legacy-SaaS-integratie en SaaS-SaaS-integratie vrijwel hetzelfde. Maar vanuit het gezichtspunt van de klant, het SaaS-consumerende bedrijf, zijn het dus twee totaal verschillende zaken. De eerste vorm van integratie hangt al snel als een molensteen om de nek van de klant, omdat ie de nadelen van SaaS met de nadelen van een eigen IT-functie combineert. De tweede vorm van integratie maakt SaaS makkelijker en goedkoper bruikbaar.

Het zou kunnen dat bij de SaaS-SaaS-integratie een kans ligt voor de softwarehouses, zeker als het om de ad hoc integratie gaat. Maar die zal snel worden verdrongen door de ecosystemen en de integratieservices. En die zijn moeilijker te leveren door de softwarehouses. Ik denk dat, voorzover de softwarehouses nu leven van het verhuren van capaciteit, ze hiertoe niet in staat zullen zijn. O, technisch kunnen ze het wel. Maar het business-model is totaal anders, en daarnaar toe overschakelen is waarschijnlijk net zo'n probleem als het overschakelen naar SaaS is voor bedrijven als SAP en Oracle.

Maar hoe zit het dan met de befaamde semantische mismatch? Gaat al dat geïntegreer wel zo makkelijk? "Begrijpen" die services elkaar dan zonder meer? Nee. Die semantische mismatch is er inderdaad nog steeds. Maar er zijn enkele ontwikkelingen die er wellicht voor zorgen dat dit probleem kleiner wordt. (Hierover binnenkort.)

Is er dan niks meer te doen voor de softwarehouses? Zeker wel. Om van SaaS gebruik te kunnen maken moeten ze weten hoe hun bedrijfsmodel mapt op de modellen van de SaaS-aanbieders. Ze moeten weten hoe en waar in hun business-processen gebruik gemaakt kan worden van welke SaaS-services. En ook de aanbieders van SaaS zullen IT-kennis nodig hebben. En er zij natuurlijk ook toepassingen die (nog) niet als SaaS beschikbaar of bruikbaar zijn.

Het idee dat dat er voor de functionaliteit die door SaaS-aanbieders goed wordt afgedekt, een krachtige IT-functie bij de klanten blijft, is een illusie. En ook integratie zal niet het werkterrein van de softwarehouses blijken, tenzij ze kans zien zich om te vormen tot SaaS-aanbieder. Maar dat is heel moeilijk.