Nieuws overzicht

Waarom onze software staat als een huis

“De software van PharmaPartners is verouderd, waarom doen jullie daar niets aan?” Deze vraag heeft Richard Arnoldussen klanten al heel vaak horen stellen. Vanuit zijn rol als directeur PharmaPartners Farmacie Groepen met 14 jaar aan technologie-ervaring zijn deze klanten bij Arnoldussen aan het juiste adres voor een antwoord over de toekomstbestendigheid van onze software. Net als met de andere vraag die hij vaak krijgt: “als je de software van PharmaPartners opnieuw zou bouwen, zou je het dan op dezelfde manier doen?”

Stelt u zich eens voor: u staat voor de deur van een huis dat u op het punt staat te be zichtigen. Nadat u aanbelt, bekijkt u de gevel. De voegen en het schilderwerk zijn goed onderhouden. Ondanks dat het huis 40 jaar oud is, maakt het een verzorgde indruk. De deur gaat open en de makelaar heet u van harte welkom. Terwijl u de woonkamer binnenloopt, valt u de moderne en fi jne inrichting op. De meubels nodigen uit om neer te ploffen of uitgebreid te tafelen. Ook de keuken is modern en van alle ge makken voorzien: precies zoals u wilt. De badkamer vraagt wel om een opknapbeurt, maar is verder goed te gebruiken.

Is dit huis verouderd? De fundering en de muren zijn 40 jaar oud en ook het dak gaat al heel wat jaren mee. Als we alleen naar deze zaken kijken, is het huis inderdaad al wat jaren oud, maar dat biedt juist ook rust voor de toekomstige jaren. Het huis is goed onderhouden en de fundering en muren staan over 40 jaar waarschijnlijk nog net zo stevig als nu. Daarnaast zit de keuken er pas een jaar in en sommige meubels zijn zelfs nog geen maand oud. Is de software van PharmaPartners verouderd? De fundering en kernprocessen zijn met Cobol-technologie gemaakt en 40 jaar oud. Als we alleen naar deze zaken kijken, is onze software inderdaad al wat jaren oud, maar dat biedt juist ook rust voor de toekomstige jaren. De Cobol-software is goed onderhouden en de fundering en kern processen zijn over 40 jaar waarschijnlijk nog net zo stevig als nu. Daarnaast bestaan sommige modules pas een jaar en sommige functies zijn zelfs nog geen maand oud.

Maar Cobol is toch achterhaald?

“Als voorbeeld van verouderde PharmaPartners-software, gaan klanten vaak in op het gebruik van Cobol en de bijbehorende ‘oude’ schermen. Alleen is dat het halve verhaal: we passen ook andere technologieën dan Cobol toe in onze software als de situatie daarom vraagt”, vertelt Arnoldussen, “We gebruiken Cobol nu voor een stuk ‘business logica’ dat al heel lang bestaat en erg stabiel is. Hier verandert weinig aan afgezien van de nodige tussentijdse updates. Cobol is nog steeds de beste keuze voor dit stuk van onze software.” Die business logica vormt de fundering, muren en het dak van onze software. Afgezien van tussentijds onderhoud aan schilderwerk en voegen, is de basis van het huis robuust. Net als de basis van onze software. “Het gedeelte van onze software dat met Cobol gebouwd is, is erg stabiel. Daarnaast is onze Cobol-oplossing de allerbeste als het aankomt op snel en goed data ophalen, opslaan en bewerken, en komen voor Cobol jaarlijks updates uit om de systemen volledig actueel en toekomstbestendig te houden”, legt Arnoldussen uit, “dat is ook een reden waardoor Cobol in heel veel software-systemen ter wereld gebruikt wordt, zoals in systemen van banken, verzekeraars en ziekenhuizen.”

Gebruikersgemak

In de omgeving die de gebruiker ziet, is Cobol minder prettig in het gebruik. Arnoldussen: “Je kunt vanuit Cobol vrij weinig informatie op een scherm tonen en ook duurt het langer voor nieuwe gebruikers voordat ze met de Cobol-schermen kunnen werken.” Net als dat het in de badkamer van ons huis wat langer duurt voordat u de douche op de juiste temperatuur heeft ingesteld met de twee aparte knoppen voor warm en koud water. Het werkt, maar die douche is gebruiksvriendelijker met een thermostaatknop. De thermostaatknop vraagt om een ander soort technologie en binnen onze software kiezen we hiervoor Java: “Hiermee hebben we onze nieuwe, grafische ‘user interface’ gemaakt. Deze technologie zorgt voor een gebruikservaring die meer aansluit op de behoeftes van onze gebruikers, waarbij we meer informatie op een scherm laten zien en met iconen werken.” Die hoeveelheid informatie kan juist ook voor uitdagingen zorgen. “Apothekers die al lang met Pharmacom werken, zweren bij de ‘oude’ schermen omdat je hiermee heel snel veel werk kan verzetten.” Hoewel u meer keuzes heeft, kost het juiste programma samenstellen via het menu van een digitale thermostaat meer tijd dan een verwarming aanzetten door aan de knop te draaien.

Snel aan te passen

“Inmiddels gebruiken we ook een derde technologie: Service Universe. Dit zijn losse componenten die taken uitvoeren of schermen laten zien en samen een web-omge ving vormen. De verschillende componenten binnen die web-omgeving kunnen we los van elkaar wijzigen.” “Daarentegen vormen Cobol en Java een geheel, dat we ook altijd als geheel moeten updaten.” Het verschil tussen Service Universe en de combinatie Java en Cobol is goed te zien in de keuken in onze woning. Een stoel vervangen we heel eenvoudig voor een andere stoel, zonder dat de hele inrichting aangepakt hoeft te worden. Maar willen we de keuken vernieuwen, dan is dit een omvangrijker project. Afgezien van de vervanging van keukenkasten en -apparatuur (Java), moeten we misschien ook wel leidingen verleggen of een extra groep in de meterkast toevoegen (Cobol).

Hoe kiezen we de juiste technologie bij de ontwikkeling?

“We kijken continu naar welke technologie we het beste kunnen gebruiken om een bepaalde functionaliteit te ontwikkelen. Is het logisch om een uitdraaiproces uit te leveren in Cobol, omdat die technologie het snelste data kan opleveren? Of willen we Java gebruiken, zodat de functionaliteit naadloos aansluit in de flow van de applicatie? Of willen we een volledig nieuwe module ontwikkelen met Service Universe?” In de praktijk komen we vaak bij een combinatie uit, omdat die het beste past. “De schermen van Digitaal Recept hebben we in Service Universe gebouwd. De receptver werking zelf is nog een combinatie van Cobol en Java op de achtergrond, omdat dit harde logica is.” Zo kunnen we in de keuken de inbouwoven vervangen voor een oven met een digitaal menu in plaats van draaiknoppen, zonder dat we de hele keuken vervangen.

Wat is geen optie?

Arnoldussen is erg duidelijk over wat we in ieder geval niet doen: “dat is in één keer alle Cobol-technologie uit onze applicatie halen. Dat is vragen om problemen, zoals verschillende andere ICT-bedrijven al hebben ervaren.” Een volledige functionaliteit op dezelfde manier nabouwen met als enige verschil het uiterlijk van de functie zonder dat die functioneel verbetert? “Dan spenderen wij tijd en geld aan iets wat geen meerwaarde voor de klant toevoegt.” Een keuken slopen om vervolgens exact dezelfde keuken neer te zetten met als enige verschil de kleur, is zonde van het geld. “Je kunt beter in meerdere, verbeterende stappen naar een andere technologie over schakelen en continu afwegen wat de beste optie is.”

Zouden we het nog een keer zo doen?

Het wordt een ander verhaal als we een bouwkavel kopen in plaats van het bestaan de huis. Dan kiezen we toch voor een andere aanpak. Niet omdat de fundering en muren van het bestaande huis van slechte kwaliteit zijn: we kiezen zo weer voor de stabiliteit van Cobol. Het is echter lastig om vaklui te vinden die bekend zijn met de technologieën van 40 jaar geleden. Dat is ook de reden waarom Arnoldussen nu een andere keuze zou maken: “Nieuwe developers die nu van de hogeschool komen leren geen Cobol.” Toch leidt dat voor de huidige Cobol in onze systemen niet tot problemen: “Gelukkig hebben we een aan tal collega’s die zeer ervaren zijn met Cobol en onze nieuwe collega’s graag bekend maken met de Cobol-taal. Hierdoor werken er inmiddels verschillende collega’s die met al onze technologieën thuis zijn en is onze software op de toekomst voorbereid.’’