Enterprise software ter ondersteuning van bedrijfsprocessen is traditioneel een speelveld van on premis- software geweest. De five hundred pound gorillas van erp, cfm, bi en hrm (lees SAP, Oracle en Microsoft) vertrouwen hierbij veelal op een eigen programmeertaal (Abap, PL/SGL, .Net). Hoe past PaaS hier eigenlijk in?
Maatwerk binnen deze applicaties wordt ondersteund, maar dient dan wel in de betreffende taal te worden uitgevoerd. Natuurlijk zijn er interfaces. Deze maken de systemen breder toegankelijk. Ze geven de mogelijkheid om aanvullende functionaliteit op een veelvoud van andere platformen en programmer talen te realiseren.
De laatste jaren zijn er enkele nieuwe Gorilla’s opgegroeid. Zij slaan de on premise stap over en baseren hun software volledig op het SaaS-model. Voorbeelden hiervan zijn Netsuite, Workday en Salesforce. Het SaaS model heeft zich ondertussen bewezen en ook veel van de traditionele on premise-leveranciers maken momenteel een grote ommezwaai richting dit model. Zo zet bijvoorbeeld Microsoft vol in op Office 365 uit de cloud iin plaats van lokaal geïnstalleerde Exchange- of Sharepoint-servers. SAP kondigde onlangs S4/Hana aan met een cloud first approach.
Interessante trend is dat veel enterprise software-leveranciers nu ook PaaS-functionaliteit bieden. Waarom doen ze dit?
Daar waar SaaS zich heeft bewezen als een efficient delivery model voor standard software levert PaaS dezelfde voordelen bij het ontwikkelen van nieuwe software. Niet langer eigen hardware en besturingssystemen beheren, maar direct starten met programmeren op een gehoste omgeving.
De platformen waarop de SaaS enterprise-applicaties gebouwd zijn leveren hiertoe wel mogelijkheden maar kennen ook enkele aandachtspunten.
-
Voordeel is dat deze platformen vaak nauw geïntegreerd zijn met het datamodel van de SaaS-applicatie. Dit resulteert in het snel kunnen aanpassen of ontwikkelen van nieuwe procesondersteuning.
-
Aandachtspunt is dat deze platformen veelal een leverancierspecifieke programmeertaal gebruiken. Nieuwe functionaliteit werkt hierdoor alleen op dit platform.
-
Nadeel is dat je gespecialiseerde kennis van dit platform nodig hebt. De nieuwe generatie ontwikkelaars leeft tegenwoordig meer in talen als Java, Python, PHP en NodeJs. Ze willen een PaaS-omgeving waar ze snel met hun bestaande programmeerkennis uit de voeten kunnen.
Enterprise software-leveranciers kennen nog een bijkomend probleem. Traditioneel ontsluiten ze hun processen primair richting de interne gebruikers. Echter de gebruiker is al lang niet meer alleen de medewerker van de logistieke afdeling of de account manager. De processen dienen ontsloten te worden via een multi channel strategie. Of in toenemende mate zonder enige tussenkomst van een eindgebruiker en direct vanuit sensoren of machines. Het internet is hierbij een primair kanaal geworden.
Andere wetten
Hier gelden andere wetten en zal je de programmeurs in deze nieuwe wereld moeten kunnen faciliteren. De strategie die ze hierbij volgen is het openstellen van hun enterprise software via api’s. Nadeel is echter dat ze hierbij ook de controle dreigen te verliezen. Andere softwareleveranciers kunnen deze api’s immers ook gebruiken en de gewenste flexibiliteit aan de eindklant leveren. Als enterprise software-leverancier wordt je teruggedrongen tot api-leverancier en dreig je de controle over je klant te verliezen. Het zelf leveren van een PaaS-oplossing is dan een logische keuze.
Dit is ook exact wat momenteel de traditionele enterprise software-leveranciers doen. Microsoft ondersteunt niet alleen .Net binnen Azure maar tegenwoordig ook bijvoorbeeld Java. SAP levert sinds kort een PaaS-oplossing middels het Hana cloud platform en Salesforce heeft enkele jaren geleden al een acquisitie gedaan van Heroku, dat nauw geïntegreerd is met hun bestaande SaaS producten.
Door zowel een SaaS- als PaaS-platform te leveren bieden ze een kosten-efficiënte delivery voor standaard en maatwerk software. Tevens strijden ze om de belangrijkste asset die het succes naar de toekomst zal bepalen: de ontwikkelaar.
Ben benieuwd naar jullie specifieke ervaringen van het gebruik van PaaS binnen de context van enterprise software.
Pim,
– Een aspect van je artikel doet me denken aan wat ik eerder heb geschreven:
SaaS, het oerwoud van de toekomst!
https://www.computable.nl/artikel/opinie/infrastructuur/4923342/2379248/saas-het-oerwoud-van-de-toekomst.html
– API-management is een onderwerp waar Gijs in ‘t Veld eerder op deze site een artikel gepubliceerd heeft.
– Ik vraag me af tot hoeverre je onderwerp geldig is wanneer Containerization (zoals Docker) verder ontwikkeld en toegepast is! In dat geval heb je geen zorgen omtrent PaaS!
Ik wordt een beetje in verwarring gebracht door schuifende definities, Paas is naar mijn mening namelijk in eerste instantie een delivery model van infrastructuur en op zich zelf nog geen service model. In deze opinie wordt namelijk stilletjes naar boven in de stack geschaald door die scheidslijn weg te halen waardoor de dimensionering van Enterprise scheef gaat. Naar mijn mening wordt met begrip Enterprise namelijk het ondernemingsniveau bedoeld waarbij verschillende organisaties een bepaald doel of principe nastreven terwijl het hier vertaald wordt naar de levering van een product met een bepaalde levensduur.
Een zin: “… als enterprise software-leverancier wordt je teruggedrongen tot api-leverancier en dreig je de controle over je klant te verliezen…” kan natuurlijk een ongelukkige woordkeuze zijn maar ik denk dat niet de ontwikkelaar maar de data de belangrijkste asset van een organisatie is. Aangaande veranderende wetten misschien goed om te kijken wat Europese Unie hiervan vindt nu we in
het post-Snowden era gekomen zijn en van e-conomie naar een i-conomie gaan. Persoonlijk denk ik dat je eerst het delivery model van je data op orde moet hebben voordat je de service modellen van de cloud induikt.
PaaS en Enterprise hoeven daarmee elkaar niet per definitie uit te sluiten maar inblikken van data en service in containers zoals bijvoorbeeld Dockers lijkt veel op de wijze waarop mijn kinderen hun kleren opruimen, zoeken in de berg naar gelijke sokken gaat vaak niet goed. Wie de sok past trekt hem aan maar maar idee van multi-channel klinkt als debacle van SVB omdat in een Enterprise het uiteindelijk de processen zijn die bepalend zijn. En als verschillende organisaties in dezelfde informatieketen met elkaar samenwerken dan gaat het om de rechten en plichten aangaande die data. API’s als de nieuwe Enterprise Service Bus is technisch een leuk oplossing maar vergeet niet etiketten met houdbaarheidsdatum en voedingswaarde op de blikken met data te plakken:
http://www.datacenterknowledge.com/archives/2014/11/05/data-portability-shortcomings-of-containers-and-paas/
PaaS heb je in alle soorten en maten.
Mendix / Cordys / OutSystems / Force.com kun je als een PaaS omschrijven. Het is een platform en je betaald naar gebruik.
Azure Cloud Services / AWS Elastic Beanstalk is ook platform as a service.
Maar in feite in de AppStore / Google Play / Facebook ook PaaS aangezien derden functionaliteit kunnen toevoegen.
Maar zelfs Google Maps zou je als een platform kunnen zien. Je kunt er iets uithalen, mengen van jezelf en aanbieden als dienst aan een ander.
En alle leveren wel iets voor de Enterprise 🙂
Waarmee ik bedoel te zeggen: Vergeet XaaS en noem gewoon man en paard.
Zelf geloof ik heilig in platformen, API’s en openstellen daarvan. Vroeger kocht je een (ERP) pakket en daarop konden medewerkers inloggen. Die gedachte is veel te nauw. Tegenwoordig wil je samen met je klanten / leveranciers / collega’s kunnen samenwerken overal altijd en op ieder device. Logisch dat je dus dingen moet samenbrengen en openstellen. Zelfs Apple heeft welliswaar een streng beleid, maar is bied wel degelijk een vorm van openheid. Je kunt bestanden bewerken met leverancier X en het opslaan in de cloud van Leverancier Y.
Generieke systemen zijn weer helemaal hot en hiermee kun je nog grotere clusterfucks veroorzaken… En dan bellen we Ewout, haha.
@Henri
Zoals ik in voorgaande reactie al aangaf zit er een verschil tussen het service model van ‘pay-per-use’ en delivery model van portabiliteit, één sluit het ander niet uit maar bepaalt wel de ‘vendor-lock’ als je er geen rekening mee houdt. Om even een ‘Rezaatje’ te doen verwijs ik je naar:
https://www.computable.nl/artikel/opinie/cloud_computing/5020126/2333364/waverzekering-in-de-cloud.html
Sorry Henri maar je gaat voorbij aan de delivery modellen als ik kijk naar service modellen welke dus ook private en community ingevuld kunnen worden. En het is jammer dat je les van tweede CAA sessie aangaande de schaalbaarh van de data architectuur vergeten bent. Voorbeeld van Azure doet voor ingewijdene wel wat vraagtekens oproepen omdat hier dus wat verteld werd over de verwachtingen en teleurstellingen.
Persoonlijk ben ik meer een aanhanger van ToC en als ik kijk naar keten als geheel en dan is voorbeeld van belastingdienst die iedereen een brief gestuurd heeft om te voorkomen dat brievenbus overbelast raakt wel een goede metafoor. Het gaat niet zo zeer om clusterfucks maar ketenfucks als we kijken naar de Enterprise als geheel. 80% van de Enterprise processen zijn batch georiënteerd en dat belast meer het netwerk dan de processor.
Uiteraard kan iedereen me bellen als ze zich zorgen maken om data architectuur, de afgelopen maand weer de gebruikelijke klachten gehoord over gebrek van ‘zoon-vader-grootvader’ back-up principe in de cloud wat voor verlies van data zorgde. Tot op heden is mijn advies hiervoor om Google te bellen omdat deze zich dus niets aantrekt van ons recht om vergeten te worden.