30-09-2020 / publicatie / Lucas Jellema
Verder met Oracle?

Ons advies als klanten vragen om ervan af te komen.

Dit is de helft van een wens. Klaarblijkelijk wil de organisatie het één niet meer – maar is niet beschreven wat dan wél gewenst wordt. Wat is het nagestreefde doel?

 

En wat wordt eigenlijk bedoeld met Oracle? Oracle heeft een breed productportfolio en is natuurlijk ook een bedrijf, een zakelijke relatie. Zouden alle producten verwijderd moeten worden en alle banden met het bedrijf Oracle verbroken? Zou de vraagsteller weten wat er allemaal in huis is van een leverancier? Is er trouwens een business case op te stellen voor zo’n operatie, die aanmerkelijke kosten, inspanningen en risico’s vergt? En zoals bij iedere vraag die mij als architect wordt voorgelegd moet ik begrijpen wat de achtergrond en werkelijke doelstelling is van een verzoek en stel ik dus de ‘powervraag’: waarom?

 

In dit artikel wil ik eerst onderzoek waar de wens om van Oracle af te gaan vandaan zou kunnen komen. Dan onderzoek ik waar de naam Oracle voor staat – meer dan 2.000 producten op allerlei lagen in de technologiestack en in verschillende bedrijfsonderdelen. Tenslotte breng ik in kaart waar het ‘ervan af gaan’ uit bestaat: het selecteren van waar je ‘naar toe gaat’ en het daadwerkelijk daarnaar overstappen.

Waarom (van Oracle af)?

De aanleiding van de hulpvraag om van Oracle af te komen is niet zelden het gedrag van het bedrijf Oracle Corporation. Een combinatie van assertieve, op korte termijn gerichte salesacties, beperkt blijkgeven van interesse in het succes van klanten [met de Oracle-producten] en onverwacht en substantieel kosten opdrijvende bevindingen van LMS (License Management Service) en onbegrijpelijke herzieningen van de prijsstructuur heeft menige klant van Oracle stevig tegen de borst gestuit. Ook de bij gelijke hoge kosten afnemende kwaliteit van de Support-organisatie en de extra kosten om ACS in te schakelen om problemen opgelost te krijgen hebben veel kwaad bloed gezet. Oracle wordt ervaren als star, bot, de afhankelijkheid van klanten misbruikend en misplaatst arrogant.  “Met een partij die je op die manier behandelt wil je geen zaken doen. Zo bijzonder zijn die producten immers ook weer niet.” 

 

Zoals veel leveranciers – en zeker niet minder dan andere leveranciers – heeft Oracle wel met groot enthousiasme nieuwe producten geïntroduceerd maar niet veel aandacht besteed aan duidelijke migratiepaden voor bestaande klanten. Productteams binnen Oracle werken vaak vanuit hun eigen context zonder veel onderlinge afstemming en verantwoordelijkheid voor de historie die met klanten is opgebouwd.

ergenis is een slechte v2 111928218791

Hoewel de ergernis in veel gevallen best te begrijpen is, vormt dit op zichzelf nog geen zakelijk argument om Oracle [producten] – of producten van andere leveranciers waar iets vergelijkbaars voor geldt - zo snel mogelijk de deur uit te werken. Net als angst – onzekerheid en twijfel – is ook irritatie een slechte raadgever. Maar gerechtvaardigd chagrijn legt een bom onder een zakelijke relatie en is een extra aanleiding die relatie kritisch te beschouwen. En met de organisatie Oracle een stevig gesprek te voeren – al dan niet ondersteund door een partner en/of samen optrekkend met andere Oracle-klanten.

 

Continuous Evaluation

Een regelmatige evaluatie van de technology stack die een organisatie toepast is een good practice die leidt tot een roadmap met per component een middellang termijnplan voor consolidatie, evolutie of vervanging door een alternatief. Een beslissing om met een component door te gaan is daarbij net zo goed een beslissing als de keuze om te vervangen. Deze periodieke evaluatie moet voorkomen dat de door een organisatie toegepaste technologie onveilig of incourant wordt met mogelijk te weinig ondersteuning vanuit de markt, de afhankelijkheid van een leverancier te risicovol wordt of de kosten voor onderhoud, operations en doorontwikkeling te hoog oplopen.

GEEN OUDE MEUK V3 111928217323

Een speciale aanleiding voor een heroverweging van de toegepaste technologystack is in diverse organisaties ook het definiëren van een cloudstrategie. Dit is een moment om producten die veelal als een gegeven in het IT-landschap staan (naast Oracle bijvoorbeeld ook SAP of IBM) opnieuw onder de loep te nemen en ervan af te stappen.      

        

Kosten en Duur

Met die kosten raken we aan een ander argument dat ik wel eens tegenkom met betrekking tot Oracle: “het is (te) duur”. Dit klinkt minder emotioneel maar is wel subjectief. Duur is een oordeel dat iets zegt over kosten ten opzichte van opbrengsten – in vergelijking tot realistische alternatieven. 

 

DUUR =  (gebruikskosten + beheerkosten + onderhoudskosten) > Opbrengsten 
            || (gebruikskosten + beheerkosten + onderhoudskosten van Oracle Oplossing) >> (kosten van gelijkwaardig alternatief)

 

Natuurlijk is het denkbaar dat de kosten van een bestaande oplossing op Oracle technologie gebaseerd hoger zijn dan gerechtvaardigd door de business baten of hoger zijn dan een alternatieve oplossing. En als dat zo is – en de kosten voor de migratie terugverdiend kunnen worden – lijkt dat een prima argument om voor die oplossing “van Oracle af te gaan”. 

 

MIGREREN_GOED_IDEE = (Huidige Kosten – Toekomstige Kosten) * 5 jaar >> kosten voor migratie (requirementsanalyse + ontwerp + implementatie + test + train + risico mitigatie + …)

 

WAT HET KOST OF OPBRENGT V4 111928141461

Ik ken weinig organisaties die van hun IT-activiteiten weten wat deze per technologie of per applicatie kosten – licenties, operationeel beheer, kennis op peil houden, onderhoud – en nog minder wat deze aan concrete opbrengst hebben. Daarmee is het dus moeilijk om de gevoelsmatige duur te formuleren in objectieve termen waar je een besluit op kunt baseren. Ik zou ervoor willen pleiten om hier wel meer inzicht in op te bouwen. Ver weg van het wel heel weinig verfijnde lumpsum IT-budget, naar concreet applicatiemanagement en serieuze business caseontwikkeling.

"Ik zou ervoor willen pleiten om hier wel meer inzicht in op te bouwen. Ver weg van het wel heel weinig verfijnde lumpsum IT-budget, naar concreet applicatiemanagement en serieuze business caseontwikkeling"

Wet van de remmende voorsprong en slachtoffer van eerder succes

Het is me gebleken dat op diverse plaatsen de naam Oracle een gevoel oproept van groot, complex, heel moeilijk aan te passen en ouderwets. Zoals we in de jaren ’90 – toen Oracle hip & happening was – over Cobol en mainframes spraken. En dat terwijl de Oracle technology stack in die 25 jaar enorm is geëvolueerd en uitgebreid met acquisities van innovatieve bedrijven en technologieën. Dus eigenlijk begreep ik dat sentiment niet zo goed. Tot er mij een lichtje opging. Wat gebeurt er met een softwaresysteem waar al 15, 20 of zelfs 25 jaar aan ontwikkeld is? Los van de toegepaste technologie? In vrijwel alle gevallen is zo’n systeem ongecontroleerd gegroeid tot groot en complex. Vaak onderhouden en beheerd door medewerkers die ook al decennia met dat systeem bezig zijn en niet zelden op min of meer dezelfde manier als twintig jaar terug. Zo’n systeem is vaak van groot belang van de business, het hart van een organisatie. En terwijl het in zijn begintijd een grote stap voorwaarts vormde is het door de groeiende complexiteit en niet meebewegende manier van werken van trots paradepaardje verworden tot bijna een blok aan het been. Dat ligt niet specifiek aan de gebruikte technologiestack – want deze systemen kom je in allerlei technologieën tegen – maar aan ons beperkte vermogen om kwaliteitssoftware te bouwen en te onderhouden.

 

Er is veel ongemak over het gebrek aan verandervermogen van en controle over die applicaties. Dit ongemak straalt af op de destijds toegepaste technologie en op de leverancier en direct op alle andere producten van die leverancier. Systemen die nu zo’n twee decennia oud zijn, zijn gebouwd met de technologie die eind vorige eeuw populair was, zoals de combinatie van Oracle Database en Oracle Forms. Deze combo is op heel veel plekken gebruikt voor het bouwen van de applicaties waar nu met veel ongemak naar gekeken wordt. En dat lijkt een belangrijke rol te spelen in het algemene sentiment over Oracle. Gebruikers, business stakeholders en IT-verantwoordelijken met frustraties over de maatwerkapplicatie projecteren die gevoelens op de technologie, de leverancier en alles waar die leverancier mee te maken heeft. Zo is Oracle vandaag in zekere zin slachtoffer van het eigen succes van meer dan twintig jaar geleden.

en dus van oracle af v2 111928216886

Organisaties zijn (meestal) overtuigd en enthousiast begonnen met Oracle-technologie en daar initieel succesvol mee geweest. Als die organisaties aangeven van Oracle af te willen maar nu niet goed de vraag kunnen beantwoorden waarom ze dat willen en waarom het mis is gegaan, lopen ze het risico dat ze over 10 of 20 jaar een soortgelijke vraag gaan stellen “help mij van xxxx af” (waarbij xxxx de technologie du jour is).  Uiteindelijk wil je niet van een technologie af maar van een complexe, slecht aanpasbare, duur te beheren applicatie. Dus zorg ervoor dat je niet opnieuw in een zo’n situatie belandt en realiseer je dat technologie niet daarin de bepalende factor is.

"Uiteindelijk wil je niet van een technologie af maar van een complexe, slecht aanpasbare, duur te beheren applicatie"

Wat is “Oracle”?

Wat precies bedoeld wordt met “Oracle [waar men vanaf wil]” zal per klant verschillen. En veel klanten weten misschien niet eens precies wat hun Oracle-gehalte is. Veel mensen zullen bij de naam Oracle allereerst denken aan de database – de RDBMS waarop het Oracle koninkrijk is gebouwd. En zelfs daar is het makkelijk een verkeerd beeld te hebben. 

DE ORACLE DATABASE IS NIET EEN DATABASE V3

De Oracle Database is eigenlijk niet een database – of in elk geval niet alleen maar een database. De Oracle Database is een krachtig en proprietary applicatie platform. Gebruikmaking van de PL/SQL procedurele programmeertaal in packages en triggers met integratie van Oracle-specifieke SQL-extensies, libraries en speciale mechanismen voor beveiliging, recovery, tijdreizen, web service-calls hebben onbedoeld voor een vendor-lockin gezorgd waar niet op triviale wijze aan te ontsnappen valt. Als ook nog APEX-applicaties (een low code-platform dat gratis beschikbaar is bij de Oracle Database) worden gebruikt is de verwevenheid met het Oracle Database-platform nog groter.

 

En naast de Database (die dus geen database is) heeft Oracle nog meer dan tweeduizend producten – van hardware tot ERP-applicatie. En biedt het ook diensten op het gebied van training, support en consultancy.

 

Van Oracle af kan dus heel veel verschillende duidingen hebben. Dus als een organisatie “van Oracle af wil” moet er een uitgebreide inventarisatie worden gedaan om vast te stellen op welke vlakken de organisatie eigenlijk precies “op Oracle zit”. En op welke manier de toegepaste Oracle-producten zijn ingezet, welke (business) doel ze dienen en waar ze mee verweven zijn. 

 

Ook als een organisatie niet per se van Oracle af wil, moet in de periodieke evaluatie van technologiecomponenten ook bovengenoemde inventarisatie worden gemaakt en de roadmap van het Oracle-aanbod – en de producten van andere oorsprongen- kritisch beschouwd moeten worden.

"Dus als een organisatie 'van Oracle af wilt' moet er een uitgebreide inventarisatie worden gedaan om vast te stellen op welke vlakken de organisatie eigenlijk precies op Oracle zit."

Deep Dive Oracle stack

Naast dit RDBMS omvat het Oracle productenportfolio ook hardware – bijvoorbeeld de traditionele Sun Microsystems machines, ZFS Storage, de Exadata engineered systems en de ODA’s (Oracle Database Appliance). De operating systems Solaris en Enterprise Linux en de Hotspot Java Virtual Machine zijn ook producten van Oracle. 

ORACLEOMVATMEERDAN 111928216455

Veel organisaties die in de jaren ’90 met Oracle technologie zijn gaan werken hebben applicaties ontwikkeld – en gebruiken die nog steeds – met Oracle Forms en in sommige gevallen met het al meer dan een decennium niet meer ondersteunde Oracle Designer. Tegenwoordig draaien die Forms-applicaties op de WebLogic Java EE Applicatie Server – in 2009 door Oracle in handen gekregen met de overname van BEA. Veel organisaties maken gebruik van WebLogic en ook van diverse onderdelen van Oracle Fusion Middleware. Dit zijn onder andere Oracle Service Bus en SOA Suite, OBI EE (Business Intelligence), Hyperion, Oracle Data Integrator en GoldenGate, WebCenter Content, ADF en Coherence (voor caching). 

 

Naast deze traditionele technologie-pijler steunt Oracle in toenemende mate op bedrijfsapplicaties. Generieke on premise ERP-pakketten zoals E-Business Suite, Peoplesoft, JD Edwards en Siebel en industrie-specifieke oplossingen zoals Hospitality (waaronder Micros), Retail (waaronder Retek), Health Insurance, Engineering (onder andere Primavera). De meeste van deze pakketten zijn inmiddels ook beschikbaar als semi-SaaS (gehost maar niet cloud-native). Pure SaaS-producten zijn er ook – bijvoorbeeld voor Customer Experience en Marketing met diensten als Eloqua, BlueKai, Marketing Cloud en in toenemende mate voor ERP – Fusion Apps for HCM, CRM, Sales, ERP, Supply Chain Management.

 

De technologie-pijler is onder de naam Oracle Cloud Infrastructure (OCI) in de markt gezet – een publieke cloud met een dienstenaanbod dat te vergelijken is met AWS en Azure – zowel IaaS als PaaS. De Autonomous Database is het vlaggenschip van OCI – wat Oracle betreft de bestemming voor al haar Database-klanten. Oracle is een samenwerking aangegaan met Microsoft met betrekking tot een verbinding tussen Azure en OCI data centers om klanten in staat te stellen diensten van beide leveranciers eenvoudig te combineren: bijvoorbeeld Azure PowerBI tegen Oracle Autonomous Database. Hiermee wordt de hybrid-cloud een realiteit vanuit het besef bij beide partners dat het merendeel van hun klanten van meer dan één cloud-platform gebruik zal maken. 

 

Veel van de “on prem” technologie-producten worden door Oracle nog maar mondjesmaat doorontwikkeld; klanten worden steeds dringender richting PaaS-diensten geadviseerd.

Van af?

Met “van Oracle af” wordt impliciet misschien wel bedoeld: van de huidige toepassing van Oracle-producten onder de huidige voorwaarden af. Een beter passende toepassing van (wellicht nog steeds, gedeeltelijk) Oracle-technologie onder betere condities is ook een manier om die wens in te vullen. Een migratie van een deel van de stack naar de (Oracle) cloud en een dynamisch pay-per-use model is misschien een beter passende beweging dan het volledig loslaten van alles dat met Oracle te maken heeft. Of zelf het komen tot een geconsolideerde, geoptimaliseerde inrichting van de aanwezige technologie met gebruikmaking van 15 jaar innovatie en nieuwe features in die technologie die een organisatie al die tijd over het hoofd heeft gezien. 

 

 

15 JAAR GELEDEN 111928216130

Ook als het huidige Oracle-landschap niet goed of goedkoop functioneert is het denkbaar dat met diezelfde producten wel goede resultaten worden behaald. Door de producten efficiënter en beter te benutten bijvoorbeeld. Regelmatig tref ik Oracle ontwikkelaars en administrators die de technologie van 2020 gebruiken zoals ze dat met de voorgangers van die technologie in 2010 of zelfs in 1995 deden. Cloud heeft de innovatie van de technologie stack nog verder versneld: op kwartaalbasis of nog vaker zijn nieuwe features en betere mechanismen beschikbaar. Betere kennis van de huidige mogelijkheden van technologie en een modernere procesinrichting voor softwarevoortbrenging en operationeel beheer kan tot substantiële en verrassende verbetering van resultaten leiden.

 

Voor alle technologiecomponenten en daarmee ontwikkelde systemen is een roadmap razend relevant. Een richting voor de verdere reis. Het 6R-model beschrijft diverse richtingen die overwogen kunnen worden: retire, retain, rehost, refactor & rearchitecture, replatform en repurchase. Heel kort te duiden als: afscheid nemen, behouden (en mogelijk moderniseren), naar een nieuwe omgeving brengen (veelal de cloud), moderniseren en verbeteren (verbouwing op zelfde fundament), herbouwen met nieuw geselecteerde platform-componenten, vervangen met standaardoplossingen.

ZESMANIEREN 111928215934

De wens “van Oracle af” zou op de volgende manier verkend kunnen worden: een reis van de huidige op bepaalde Oracle-producten gebaseerde situatie qua kosten, flexibiliteit, beheerbaarheid, beveiliging en schaal naar een wenselijke situatie waarin op agile wijze gecontroleerd software kan worden ontwikkeld, uitgerold en beheerd tegen aantrekkelijke TCO. In een afbeelding ziet dat er volgt uit:  de gewenste situatie omvat mensen, cultuur, proces, middelen en 3rd party producten en technologieën. In die mix zouden producten van Oracle een plek kunnen hebben (zie onderstaande figuur).

En wat dan wel – en hoe?

De keuze om te stoppen met een product of technologie is over het algemeen de afgeleide van de keuze om een ander product of technologie te gaan gebruiken. De wens tot iets anders resulteert in de keuze het huidige los te laten. Wat mij betreft zou ‘niet Oracle’ de uitkomst moeten zijn van een proces waarin een afweging is gemaakt en een bewust besluit is genomen tot ‘wat wel’ : om een bepaald product te gaan inzetten waarmee een Oracle-product vervangen wordt.

 

Bij het maken van dit soort keuzen tussen behouden en doorzetten of uitfaseren en vervangen wordt naar verschillende aspecten gekeken. Deze criteria op basis waarvan de alternatieven voor een bepaald technologie bouwblok vergeleken worden omvatten bijvoorbeeld fit for purpose: functionaliteit (wat kan met een bepaald product of technologiecomponent), veiligheid, stabiliteit en schaalbaarheid, courantheid, kosten en productiviteit (aanschaf, ontwikkeling, beheer, onderhoud), marktacceptatie, vooruitzichten zoals vastgelegd in een product-roadmap en inpasbaarheid in het bestaande landschap en organisatie.  Ook de zakelijke betrouwbaarheid van de leverancier – zo goed mogelijk objectief uitgedrukt – is een criterium.

 

Migratie naar alternatief

Als er een alternatief is dat beter scoort dan de huidige oplossing komt de vraag voor te liggen hoe een eventuele migratie er uitziet. Wat kost deze, wie kan deze uitvoeren, hoeveel tijd en inspanning is ervoor nodig, welke ruimte qua resourcebezetting en noodzakelijke downtime is er, welke risico’s geeft dat, hoeveel impact is er op het vermogen nieuwe businessfunctionaliteit op te leveren? Een niet onbelangrijke overweging is de betrokkenheid en motivatie van de medewerkers: willen zij graag de overstap maken en is deze haalbaar binnen de budgetten en termijnen? 

 

Geld is een belangrijk onderdeel in alle gevallen. De kosten van de migratie zijn lastig in te schatten. Hieronder vallen ook de eenmalige afschrijving op boekhoudkundig geactiveerde applicaties en platformcomponenten en ook de training en tijdelijk lagere productiviteit van betrokken personeelsleden. De cumulatieve investering – in geld, kennis en emotionele betrokkenheid – in applicaties die soms meer dan twintig jaar in gebruik zijn is veel groter dan vaak onderkend wordt. De inspanning die nodig is om de verwevenheid van deze applicatie met andere systemen en met de organisatie te ontrafelen is groot evenals de risico’s. 

 

Als ook enigszins mogelijk zou deze migratie – net als iedere grote verandering - in niet te grote stappen en zeker niet overhaast moeten worden gedaan. 

Om een succesvolle vervanging van al toegepaste componenten te bereiken moeten volledige functionele en technische specificaties beschikbaar zijn die in detail beschrijven waarvoor en hoe de componenten worden gebruikt. Op basis daarvan kunnen we het as-is vervangingstraject (vrijwel zonder business value) plannen en inschatten. 

WAT ZOU DE APPLICATIE EIGENLIJK MOETEN DOEN V4 111928141355

Deze specificaties zijn in de praktijk maar zelden compleet en up-to-date beschikbaar en dus zal het opstellen van deze detailbeschrijving vaak onderdeel moeten zijn van het traject. Dit onderzoek kan gebruikt worden om ook draagvlak op te bouwen voor de vervanging en om laaghangend fruit qua optimalisatie in kaart te brengen. Overigens moeten ook procedures en tools voor CI/CD en voor monitoring en beheer onderdeel zijn van de inventarisatie en de uiteindelijke migratie.

 

Aanwezigheid van geautomatiseerde testen op alle interactiepunten tussen het te vervangen systeem en andere interne en externe applicaties is van grote waarde om de correctheid van de vervangende component vast te stellen en zo risico’s te beperken. Ook deze testen zijn zelden volledig aanwezig en moeten dus als onderdeel van – of als voorbereiding op – de migratie worden opgebouwd.

 

Elke activiteit kan eenvoudiger en minder risicovol worden gemaakt als deze in kleinere stappen kan worden opgedeeld. Dat zullen we bij een migratietraject van Oracle naar iets anders ook proberen: betekenisvolle plateaus om stapsgewijs de vervanging te doen.

EEN TECHNOLOGIE MIGRATIE V2 111928141339

De betrokken medewerkers – of outsourcing partner - zijn een belangrijk onderdeel van het migratietraject. Hun functionele kennis en vakmanschap zijn vaak van grote waarde, ook aan de andere kant van de migratie. De context waarin ze werken verandert – en daarin zullen ze opgeleid, begeleid en vaak ook verleid moeten worden, om zelfstandig en gemotiveerd hun werk met de nieuwe producten en technologie uit te voeren. Mogelijk willen of kunnen niet alle medewerkers in hun rol verdergaan na de migratie; dat kan een extra uitdaging zijn op HR-gebied. 

En nu?

Als je van Oracle af wilt – dan wil ik graag met je komen praten. Om te begrijpen waarom je dat wilt. Om vast te stellen wat je ermee wilt bereiken. Om een beeld te krijgen van de uitgangssituatie en het bestaande gebruik van Oracle-producten. Ik wil graag gezamenlijk de mogelijkheden, potentiële voordelen en impact van migratiepaden vaststellen. En ook ondersteunen bij de eventuele daadwerkelijke overgang van een Oracle-product naar het vastgestelde doel en het succesvol maken van de organisatie met die nieuwe technologie. 

 

Oracle-technologie heeft de afgelopen decennia, ook bij organisaties die er nu vanaf willen, gezorgd voor continuïteit van de IT en de dagelijkse operationele performance. Als je dat gaat vervangen is het goed ook een lijst te maken met zaken in die Oracle-technologie die je (nog) steeds waardeert, dagelijks gebruikt en nodig hebt voor de bedrijfsvoering. Die moeten wel terugkomen in de vervangende technologie.

"Als er voor je wens om van Oracle af te gaan geen positieve business case te maken valt - in geld noch in andere maatstaven – of in elk geval niet voor de mate waarin je dat wilt of de termijn waarbinnen je dat plant, dan zal ik dat ook tegen je zeggen. Om te voorkomen dat ergernis je slechte raadgever is."
Lucas Jellema
Meer weten over Oracle?
Ik praat er graag verder met je over.
Bel Lucas Jellema 030 601 6000
Abonneren
op nieuws?