Heeft u ook wel eens een auto gehuurd op vakantie? Als zuinige Nederlanders zijn we geneigd een kleiner type te nemen dan dat we zelf bezitten. We zijn dan blij verrast als die de betreffende dag niet beschikbaar is en we, zonder meerprijs, een grotere auto krijgen. Upgrades zijn dan ineens leuk. Niet alleen voor een auto maar ook voor een telefoon, huis, fiets, televisie, et cetera.
Hoe anders is het voor enterprise software. Indien we bewust de functionaliteit van een nieuwe release willen uitnutten is een multidisciplinair team noodzakelijk. Externe consultants worden ingehuurd en uitvoerige test-scripts worden uitgewerkt. Als het weekend van de upgrade eindelijk is aangebroken liggen de noodscenario’s klaar. Na een nacht doorhalen zijn we zo blij dat de champagne open gaat.
Raar eigenlijk dat ik als klant veelal meer dan 20 procent maintenance fee betaal en daarnaast nog enorme kosten moeten maken om elke keer een release upgrade uit te voeren. Zeker omdat we er in veel gevallen slechts voor zorgen dat we een weer een actuele versie hebben die nog door onze software leverancier ondersteund wordt. Geen wonder dat organisaties liever een extended maintenance fee betalen dan dat ze een upgrade uitvoeren. Upgrades zijn niet leuk. Sterker nog wel liggen er wakker van en stellen ze het liefst zo lang mogelijk uit. Kan het ook anders?
Cloud computing wordt vaak als de oplossing voor deze upgrade nachtmerrie genoemd. Dit is echter maar ten dele waar. Het naar de cloud brengen van traditionele on-premise applicaties in een IaaS model lost het probleem niet op. De software architectuur van deze applicaties zijn destijds ontworpen om per organisatie te installeren en configureren. De “upgrade.exe” moet nog steeds voor elke specifieke omgeving, en bij elke organisatie uitgevoerd worden. Zeker bij sterk aangepaste erp-systemen leidt dit nog steeds tot kostbare upgrades. IaaS verplaatst alleen de fysieke omgeving waar de software staat en niet de impact van het upgrade proces.
Gartner voorziet zelfs dat deze sterk aangepaste erp-systemen rond 2016 de nieuwe legacy-omgevingen zijn. Het upgraden van deze systemen wordt als niet meer rendabel geacht. Advies is wel om ze onder te brengen in een IaaS omgeving om zo de voordelen van hardware en infrastructuur beheer uit te nutten. Sluit desgewenst een passend supportcontract af voor regulier onderhoud. Ontsluit processen via api’s in een Pace Layering Architectuur Model om nieuwe systemen toegang te geven tot de informatie. Vraag blijft hoe we met deze nieuwe systemen niet weer in dezelfde upgrade nachtmerrie gaan terecht komen.
SaaS-leveranciers van enterprise software, zoals NetSuite, Salesforce, Succesfactors en Workday, hebben de afgelopen jaren laten zien dat het ook anders kan. Door toepassen van een multi tenant cloud-architectuur wordt de infrastructuur gecentraliseerd en door de leverancier beheerd. Een upgrade van deze infrastructuur betekent automatisch een nieuwe release voor alle klanten. Alle upgrade-inspanningen en complexiteit wordt hierbij centraal door de leverancier in plaats van decentraal door de klant uitgevoerd. Tevens zijn ze onderdeel van de standaard onderhoudscontract.
De daadwerkelijke upgrade, en dus de tijd dat de klant geen toegang tot zijn systeem heeft, duurt slecht enkele minuten. Na de upgrade werken alle bestaande processen nog exact hetzelfde en staat nieuwe functionaliteit klaar om direct toe te passen. In het juiste cloudmodel en met SaaS-applicaties die gebouwd zijn voor de cloud kunnen upgrades dus wel degelijk leuk zijn. Heel leuk zelfs.
Het artikel beschrijft de voordelen van massaproducten client/server kunnen draaien. Server upgraden en klaar. Het gaat natuurlijk gewoon niet op voor maatwerk.
En als je interfaces veranderen tijdens die upgrade ? bijv bij ETL, batchverwerkingen enzo met externe systmen ? Krijgt de klant daar een overzicht van en hoe kun je dat testen zonder productie te verstoren ?
En als ik nou niet wil upgraden, laten ze die oude release dan intact voor mij ?
Kan je ook weer downgraden als er na upgrade problemen blijken ?
Lead Solution Engineer, Architectuur expert… Maar dit artikel gaat gewoon over een gedwongen upgrade van een massaproduct.
“Na de upgrade werken alle bestaande processen nog exact hetzelfde en staat nieuwe functionaliteit klaar om direct toe te passen”.
Jij heb nog niet zoveel meegemaakt, zo te horen 🙂
Ik sluit me aan bij Felix, het verhaal komt wereldvreemd over.
In 30 jaar dat ik upgrades van van alles meegemaakt heb was er altijd iets vergeten, dat zal nu met “cloud” IaaS/SaaS of wat je het ook wil noemen niet anders zijn.
Zonder hardware en OS bestaat er geen cloud, en hardware/OS hebben af en toe een update nodig. Je kunt nog zoveel virtualiseren of in software definiëren nieuwe versies krijg je niet zonder update en ook niet zonder moeite en/of uitval.
Innovatie zonder upgrades is eenvoudig weg niet mogelijk. Dus in die zin zul je daar niet omheen kunnen.
Maar deze axioma wordt ook schaamteloos misbruikt in het verdienmodel van de degenen die de upgrades aanbieden. Dus in die zin is het verstandig om de verschillende upgrades zoveel mogelijk van elkaar te scheiden zodat je strategische keuzes én bedrijfseconomische keuzes kan maken die elkaar niet al teveel in de weg lopen.
De applicatiestack bestaat inderdaad uit meer onderdelen dan de applicatie alleen. Zo is er nog de database, de database client software, het OS, en (vooral bij een wat grotere omgeving) de talrijke connected applications die allemaal met de nieuwe versie van de applicatie overweg moeten kunnen.
“Na de upgrade werken alle bestaande processen nog exact hetzelfde en staat nieuwe functionaliteit klaar om direct toe te passen”.
Maar die zin impliceert dat de hoeveelheid verouderde en backwards compatible functionaliteit na iedere upgrade zou toenemen, iets wat natuurlijk niet zo kan zijn.
Verder moeten de businessprocessen en de nieuwe versie uiteraard vooraf goed getest worden en moet er een werkend backout plan bestaan.
Wat is het dan toch heerlijk als er alleen met standaard software gewerkt kan worden, dus zonder maatwerk. Hierdoor kunnen de upgrades massaal uitgevoerd worden op het online-platform zonder dat er rekening gehouden hoeft te worden met klant-specifiek maatwerk. Succes verzekerd!
Dank voor jullie reacties. De feedback en interactie wordt erg gewaardeerd
@Felix de Cat Ik snap je reactie, Hij is vergelijkbaar met mijn reactie voordat ik kennis maakte met SaaS Updates versus software upgrades. Met dit opiniestuk hoop ik lezers te triggeren zich ook hierin te verdiepen omdat ik van mening ben dat upgrades voor klanten ook anders kunnen dan de afgelopen 30 jaar. Zelf spreek ik wekelijks architecten van multinationals die hiervoor open staan en ervaren dat upgrades inderdaad anders kunnen.
@Jan van Leeuwen. Mijn stuk is geschreven vanuit de ogen van de eindklant. Natuurlijk zijn hardware en OS nog immer de basis van Clouddiensten. Leveranciers van SaaS diensten verbergen deze complexiteit echter voor de eindklant in hun subscription model. Dat upgrades nog immer een complex proces is blijkt oa uit deze blog https://developer.salesforce.com/blogs/engineering/2013/05/here-comes-the-hammer.html
Belangrijk verschil is dat de leverancier en niet de eindklant de verantwoordelijkheid (en de kosten) van de upgrade draagt. Op soortgelijke wijze dat jij als klant van KPN of T-Mobile ook geen server upgrade hoeft uit te voeren. Voor de eindklant zijn upgrades daarmee een stuk leuker 😉
@KJ Zie mijn vorige opmerking. Aanvullend zorgt een Metadata-Driven Architectuur bij veel SaaS leveranciers voor een strikte scheiding tussen platform en de (maatwerk)applicaties die daarop draaien. Hierdoor kan het platform geupgrade worden er geborgd worden dat de klantspecifieke customizing in de applicaties behouden blijft. Lees dit artikel eens ter inspiratie. http://www.netsuiteblogs.com/whos-afraid-of-erp-upgrades
@Johan Duinkerken Continue upgrades van het platform is bij SaaS leveranciers aan de orde van de dag. Dit is juist de manier waarop deze platformen innovatie veel sneller kunnen brengen dan traditionele on-premise software. Lees dit artikel van een eindklant ter inspiratie. http://www.workday.com/company/news/featured_articles/saas_updates_vs_software_upgrades/the_update_experience.php
Pim,
Ik sluit me aan bij je verhaal en jouw reacties. Onbekend maakt onbemind en onbegrepen. Nog wel – maar Cloud/SaaS ervaringen zijn inderdaad dusdanig dat het oude euvel van upgrades doen verdwijnt. De business die veel meer dan traditionele IT’ers de toegevoegde waarde van SaaS inmiddels onderkent zal dit beamen.
Ik kan me tot op zekere hoogte goed vinden in het verhaal van Pim. Als je puur naar de ‘Shelf’ software van je leverancier kijkt, zorgen zij in 99% van de gevallen voor backward compatibility bij een upgrade. Echter, wat ik vaak zie is dat het maatwerk IN die software (Scripts/batches/code) bij upgrade van versie N naar N+1 nog wel oke werkt, maar ergens bij N+3 of N+4 ineens niet meer werkt. Met andere woorden, de problemen zitten over het algemeen in het niet bijwerken van de eigen customisations naar de functies die door een upgrade zijn bijgewerkt. Als die customisations goed zijn gedocumenteerd, is het bijwerken daarvan een stuk eenvoudiger, zeker als deze kort na een upgrade ook uitgevoerd worden. Als iedereen een beetje bij blijft, is Upgraden een stuk minder complex.