28-11-2018

Microservices: het einde van de SAP spaghetti?

In deze tweedelige blog leggen we uit hoe het gebruik van microservices de klassieke problemen van SAP ERP producten zouden kunnen verhelpen. Dit doen we door het laatste aanbod van SAP op dit gebied te belichten, SAP S/4HANA. Ook bespreken we hoe microservices daarnaast nieuwe kansen kunnen bieden voor SAP en haar partner-ecosysteem. In deel 1 bespreken we de blind spots in de huidige S/4HANA propositie. In deel 2 stellen we microservices voor als oplossing en werpen we een blik op de agenda van SAP op dit gebied.

 

Het SAP vlaggenschip

Sinds de lancering van S/4HANA in 2015, is deze suite hét vlaggenschip voor SAP’s ERP portfolio. SAP S/4HANA is de opvolger van SAP Enterprise Central Component, beter bekend als SAP ECC, die al decennialang de cashcow vormt voor SAP binnen het ERP segment. Gebaseerd op de laatste innovaties op het gebied van computing infrastructuur, wordt S/4HANA geloofd vanwege de snelheid en het vermogen om vanuit één systeem zowel business transacties (OLTP) als analytische reporting (OLAP) te ondersteunen. Daarnaast is er met de komst van Fiori een grote stap gezet op het gebied van user experience, waardoor SAP applicaties op een moderne en rolgebaseerde manier worden ontsloten richting gebruikers.

S/4HANA: the digital core
S/4HANA: the digital core

Hoewel SAP met S/4HANA ten opzichte van ECC een tal van innovaties en verberingen heeft kunnen doorvoeren (bijvoorbeeld ‘live MRP’), biedt dit geen garanties om ook aan de toekomstige marktvraag te voldoen. SAP wordt in de markt nu al vaak gezien als rigide en complex, bekend vanwege de vendor lock-in effecten. Cynische acroniemen als ‘Submit And Pray’ en ‘Sandläufer Anschau Programm’ zullen ingewijden dan ook bekend in de oren klinken.

Kunnen we met de komst van S/4HANA nu wat anders van SAP verwachten? Zijn SAP klanten met S/4HANA voldoende uitgerust om het welbekende big-ball-of-mud-probleem te voorkomen? Om uit te leggen waarom wij namens Experis Ciber hier niet overtuigd van zijn, moet er ten eerste worden gekeken naar de huidige applicatie architectuur van S/4HANA.

pattern
Zijn SAP klanten met S/4HANA voldoende uitgerust om het welbekende big-ball-of-mud-probleem te voorkomen?

S/4HANA de monoliet

Net zoals bij SAP ECC, is de architectuur van S/4HANA monolithisch. In essentie betekent dit dat alle functionaliteiten zijn verpakt in één grote applicatie. Dit soort applicaties zijn doorgaans georganiseerd in functionele modules die onderling sterk met elkaar verbonden zijn en ondersteund worden door een gemeenschappelijke database. Monolithisch betekent letterlijk ‘samengesteld uit een enkel stuk’.

Deze aanpak kent veel voordelen. Zo is procesintegratie eenvoudig, omdat alle functionele modules onderdeel van dezelfde toepassing zijn. Wanneer er bijvoorbeeld na het aanleggen van een verkooporder direct een inkooporder moet worden gegeneerd, is het binnen de toepassing eenvoudig om de onderliggende methode aan te roepen, zonder je je zorgen te hoeven maken over zaken als data consistentie tussen modules of communicatiefouten. Monolithische applicaties zijn daarnaast simpel te ontwikkelen, testen en op te schalen.

Tenminste, in het begin.

 

Wanneer de sneeuwbal begint te rollen

In de loop van de tijd groeien succesvolle applicaties doorgaans in omvang, gedreven door de ontwikkeling van extra functionaliteiten. Het implementatieteam erachter groeit daarop mee en zal uiteindelijk opgesplitst worden in afzonderlijke groepen. Dit is waar monolithische systemen in de problemen beginnen te raken.

Omdat de ontwikkelteams uiteindelijk allemaal bijdragen aan dezelfde codebase, zullen organisatorische afhankelijkheden zich gaan voordoen bij systeemwijzigingen, wat de implementatie ervan zal bemoeilijken. Een ander probleem dat voortvloeit uit de immer toenemende codebase, is de onmogelijkheid om de impact van individuele systeemverandering te overzien. Hierdoor zal de kwaliteit van de coding over de tijd afnemen, terwijl de onderliggende technologische stack steeds verder verouderd. De toenemende risico’s van systeemwijzigingen worden meestal gecompenseerd door extra controlemaatregelen in te voeren, zoals complexe goedkeuringsprocedures en uitgebreide regressietests, waardoor de doorlooptijden van projecten en systeemwijzigingen snel oplopen.

Dit alles resulteert uiteindelijk in een oncontroleerbare spaghettibal binnen het landschap die innovaties afremt en ervoor zorgt dat pogingen voor het gebruik van agile methoden over de schutting kunnen worden gegooid. Wij denken dat veel SAP klanten zich in deze reeks aan gebeurtenissen zullen herkennen. Door de opgebouwde complexiteit van het ERP systeem, is moeilijk om het als iets anders te zien dan een starre kostenfactor die elk project dat ermee in aanraking komt bemoeilijkt en vertraagd.

 

Het antwoord van SAP

Zich bewust zijnde van dit probleem, antwoordt SAP hierop door out-of-the-box ‘best practices’ aan te bieden voor S/4HANA. Deze ‘best practices’ zijn ontwikkeld op basis van de jarenlange ervaring die SAP heeft opgedaan met klanten in allerlei industrieën voor hoe bedrijfsprocessen er normaliter uit zouden moeten zien. Met S/4HANA zijn deze ‘best practices’ makkelijk te activeren om daarmee op een snelle manier kernfunctionaliteiten en integraties te implementeren. Dit is geweldig, als jouw organisatie voldoet aan deze door SAP gedefinieerde standaard. Het wordt al gauw ingewikkelder wanneer de bedrijfsprocessen beginnen af te wijken van deze templates, wat vaak het geval is voor grote zakelijke klanten die ondersteuning nodig hebben voor een brede variëteit aan complexe bedrijfsscenario’s.

Soorten s/4hana

De opties om procesdifferentiatie toe te voegen zijn vooral beperkt in het S/4HANA Public Cloud aanbod, waar klanten en implementatiepartners moeten vertrouwen op de procedures van SAP om wijzigingsverzoeken ingewilligd te zien worden wanneer er aan functionaliteit ontbreekt. Dit betekent concreet dat wanneer je geen strategische account bent voor SAP, een dergelijk verzoek ergens op de roadmap wordt geplaatst… als je gelukt hebt. Alhoewel het begrijpelijk is dat SAP de regie wil voeren over haar cloud producten, bemoeilijkt deze driehoeksverhouding de inspanningen van implementatiepartners en klanten om de producten succesvol geïmplementeerd te krijgen.

Natuurlijk is er de optie om te kiezen voor de private cloud of on-premise oplossingen, waar ‘best practices’ ook altijd nageleefd kunnen worden, maar waar klanten alle vrijheid hebben om maatwerk toe te voegen. Omdat klanten dit al gewend waren uit de tijd van SAP ECC, is het voor de hand liggende nadeel dat het voor organisaties en partners gemakkelijk is om in de aloude valkuil te trappen van het opnieuw tot rollen brengen van de ERP sneeuwbal. Bij Experis Ciber zien we SAP klanten ver gaan om deze praktijken dan ook te voorkomen door middel van beleidsmaatregelen. Een voorbeeld uit markt was een partij die afdwong dat elke ontwikkeling die meer dan 4 uur kostte, goedgekeurd moest worden door een stuurgroep. Het is maar de vraag of een dergelijk beleid op de lange termijn kan worden volgehouden, wetende hoe monolieten zich over de tijd blijken te ontwikkelen.

SAP biedt met de “N-Tier” benadering nog een alternatief, waarbij kleinere organisatieonderdelen die met de best practices overweg kunnen, in de public cloud worden geïmplementeerd, terwijl de complexere entiteiten in een private cloud of on-premise S/4 Hana oplossing worden gezet. Hoewel deze aanpak het mogelijk maakt om de differentiatie toe te voegen waar deze nodig is, zullen klanten die hier voor kiezen uiteindelijk volgens verschillende licentiemodellen kostenfactoren aan het stapelen zijn, terwijl ze functionele dubbelingen aanbrengen in hun applicatielandschap.

SAP s/4HANA n-tier benadering
De SAP S/4HANA N-Tier benadering

Omdat alle opties die SAP biedt om een wildgroei van S/4 Hana te beteugelen ook duidelijke nadelen hebben, moeten klanten overwegen of ze, door voor S/4 Hana te kiezen, hun organisatie niet in de wachtrij zetten voor precies dezelfde problemen waar ze nu met SAP ECC al mee te maken hebben.

 

Échte best practices

Als we een stap terug doen naar wat recente onderzoeken naar succesvolle software ontwikkeling laten zien, dan wijst dit uit dat sucessvolle software ontwikkeling bereikt wordt door het organiseren van multidisciplinaire, autonome teams die continue software leveren of, nog beter, implementeren. De IT experts uit deze teams werken nauw samen met de business vertegenwoordigers om waardevolle software te garanderen. Vanuit het bovenstaande betoog is het echter ook duidelijk dat wanneer complexe monolithische systemen zoals SAP ERP opgroeien, dit de autonomie en wendbaarheid van de achterliggende ontwikkelteams onvermijdelijk aantast. Veel geluk aan de agile ‘change agent’ van deze wereld om de silo’s binnen global IT uit te leggen dat ze vanaf nu scrum moeten gaan doen!

In plaats van de vingers richting mensen te wijzen, of de oplossing zoeken in de nieuwste technologische innovaties, is de echte innovatie misschien wel te vinden in een andere hoek, namelijk de applicatie architectuur. Gelukkig lijkt er een alternatief zich aan te dienen..

Bron infographics: SAP NL

Martijn Hulshof & Robin Day

Business Thema's

IT-Trends

Partners van deze blog

SAP

Kennismaken?

nl.info@ciber.nl

Binnen 12 uur reactie

Onze locaties

Bekijk onze locaties

2.0.0