Smile
Terug naar hoofdmenu
Terug naar het overzicht

Belko, een handelsonderneming in connectoren en kabels, had begin jaren 90 het ISO9001 certificaat gehaald. Dit mede door de volledig in eigen beheer ontwikkelde (en in die tijd zeer vooruitstrevende) logistieke software van automatische inkoop tot automatische levering en de daarbij behorende klachten. De certificerende instelling was hier zo van onder de indruk dat Belko als voorbeeld werd gebruikt en andere bedrijven de wens uitspraken om met een soortgelijk klachtensysteem te gaan werken. Dát was de trigger om klachtensoftware te gaan maken als ‘core business’ en dus voor het ontstaan van Smile.

De eerste ontwikkeling

Frank: “Smile stelde zich tot doel een universeel toepasbaar klachtensysteem maken dat gemakkelijk in gebruik was, een goede performance had en eenvoudig was aan te passen. Hoewel het ook een grote wens was om qua operating systeem platform onafhankelijk te zijn, was dat met de stand van de techniek nog niet haalbaar. Daarom koos Smile in eerste instantie voor FoxPro op Windows 3.11 als ontwikkel-basis, het meest gebruikte systeem op dat moment. Na ongeveer 3 maanden ontwikkelen werd in 1995 de eerste versie geboren, genaamd TransCom, een combinatie van Transdata (de naam die Smile in het oprichtingsjaar had) en Complaint. Het was een single-user applicatie met een eigen database. Je kon een klacht registreren inclusief klant, leverancier, aard en oorzaak. Daarnaast kon je per klacht acties koppelen met een datum en persoon. Hiervan waren overzichten te maken op elk onderdeel.

Omdat FoxPro toch te beperkt aanpasbaar bleek voor gebruikers is een half jaar later gekozen om de software te herschrijven op een meer standaard aanpasbaar platform genaamd Delphi, een op pascal gebaseerde en object georiënteerd ontwikkel-taal. Hierdoor werd het mogelijk om de data op te slaan in relationele databases zoals Oracle, MSSQL, MYSQL etc. wat o.a. zorgde voor een betere performance. Gebruikers konden zelf eenvoudig aanpassingen maken, zoals bijvoorbeeld extra velden toevoegen. Hierdoor was de software persoonlijk en dus makkelijker in gebruik. Door een zelf ontwikkelde grid component, TDBGridRG, was het tevens mogelijk om snel overzichten te maken door te selecteren en filteren en op te slaan. Gebruikers waren dan ook zeer enthousiast. De software was nog steeds single-user maar de vraag naar een multi-user variant liet niet lang op zich wachten. De eerste stap op weg naar een multi-user applicatie werd gemaakt met behulp van een synchronisatie methodiek die de individuele systemen met elkaar synchroniseerde. Dat werkte in die tijd perfect.”

De eerste webbased versie

Frank: “Toen eind jaren 90 het Internet sterk opkwam, besloten we een volledige ‘webbased’ versie te gaan bouwen, o.a. om een meer eenvoudige multi-user opzet mogelijk te maken. We kozen voor Apptivity, een op Java gebaseerd platform (en dus onafhankelijk van operating systemen) en het systeem kreeg de naam SmartCom. Een grote Telecomklant zag direct veel potentie en kocht het systeem al voordat het gebouwd was. Dat gaf ons vleugels: de eerste versie van SmartCom werd begin 2000 ontwikkeld en 6 maanden later aan de eerste klant geleverd.

Deze versie was meer aanpasbaar dan de Windows-variant. Gebruikers konden net alleen velden toevoegen, maar ook verschillende schermen samenstellen en gebruik maken van een workflow die taken uitzette voor en e-mails verstuurde naar behandelaars van klachten. Het was zelfs mogelijk het systeem voor andere processen te gebruiken dan klachten door aanpasbare labels. Om dit te realiseren, maakten we gebruik van een zogenaamde ‘datareader’ en van een ‘condition evaluator’. De datareader haalde de hele structuur van een object op, afhankelijk van de vraag die je meegaf. Hierdoor was het eenvoudig om gegevens op schermen te zetten: je hoefde alleen maar het betreffende veld te benoemen en niet de hele structuur erachter te weten. Dit datareader component werd ook gebruikt om condities te evalueren die nodig waren om de workflow af te trappen. Soortgelijke structuren zijn ook in de huidige software nog terug te vinden, maar met de nieuwe technieken is dit ondertussen natuurlijk vele malen verbeterd.

Om organisaties eenvoudig in te kunnen laten stappen op een standaard klachtenmanagement-software zonder zelf hardware te investeren, is SmartCom ook ingezet als ASP-oplossing (de voorloper van SaaS). Enkele klanten hebben hier gebruik van gemaakt, maar voor de meeste bedrijven was dit toen nog veel te vroeg: Smile liep echt voor de muziek uit!”

Een low code software platform in de dop

Niels: “In 2004 merkten we dat het huidige platform beperkingen kreeg (we waren eigenlijk net te vroeg gestart met webbased technieken). We besloten af te stappen van Apptivity en ontwikkelden een geheel nieuw platform dat de naam SmileCom kreeg. Dit is nog steeds de basis van het huidige Smile Platform. Om dynamische applicaties te kunnen maken kozen we voor Flash op een ColdFusion server. Vooral het beheer-deel waarin er op een ‘what-you-see-is-what-you-get’ manier gewerkt kon worden, was een grote verbetering in het nieuwe SmileCom en onze klanten én consultants waren erg enthousiast over de tijdsbesparing die dat met zich meebracht. Terugkijkend heeft Smile toen al de basis gelegd voor een low code software platform waarmee niet-developers zonder technische kennis heel eenvoudig processen kunnen inrichten: een trend die anno nu niet meer is weg te denken.

De ontwikkelingen gingen door richting HTML en Javascript. Om bij de tijd te blijven werden in 2007 stappen genomen om alle Flash elementen uit de interface te halen en onder te brengen in een nieuw Struts-framework, op dat moment een van de grootste Java frameworks met ondersteuning voor model/view/controller. Dit draaide allemaal op Tomcat applicatieservers. De Hibernate communicatielaag naar de database, die al vanaf het begin in SmileCom aanwezig was, kon blijven bestaan. Toen ook de ‘drag-and-drop’-functie voor aanpassen van schermen in SmileCom 1.7 gereleased werd, was Flash helemaal uitgefaseerd.”

Nieuwe techniek biedt nieuwe mogelijkheden

Niels: “Doordat alles opnieuw was opgetild naar de op dat moment laatste technieken, kwamen er ook weer volop mogelijkheden voor nieuwe functionaliteit, zoals het mogelijk maken van ‘bulk-veranderingen’. In eerste instantie werd dat gedaan door een overzichtsscherm aanpasbaar te maken, waardoor er op een regel geklikt kon worden en er daarna records konden worden aangepast. Omdat er binnen de interface nogal wat afhankelijkheden zitten tussen velden, hebben we dit al vrij snel weer aangepast naar de ‘repeating tab’-functionaliteit die een stuk flexibeler was. Ook werden aanvullende features geïntroduceerd zoals ‘bulk-koppelen’.

Er kwamen in deze periode steeds meer klanten die verschillende SmileCom applicaties hadden draaien voor verschillende doeleinden en deze applicaties met elkaar wilden koppelen. Smile had deze uitdaging zelf ook in de online support community die publiek beschikbaar was en een belangrijke link had met de door Smile intern gebruikte SmileBase. Uit deze situatie is de ‘synchronisatie techniek’ geboren die verschillende SmileCom-systemen op een eenvoudige manier met elkaar kon verbinden.

Ook de manier waarop workflows werden geconfigureerd ging in deze tijd op de schop: het bleek dat workflows zo groot werden dat beheerders het overzicht verloren. Een meer grafische oplossing o.b.v. een gemodelleerd UML-diagram gaf veel meer overzicht en dus gebruiksgemak. Dit was in eerste instantie gemaakt door bestanden van een open-source UML-tool in te kunnen lezen en is later uitgebouwd naar een volledig geïntegreerde tool voor het bewerken van flows. Sinds de laatste 3.x versies is dit ook de basis van de Microflows.”

Een nieuwe major versie

Niels: “In 2013 is de 2.0 uitgebracht, een versie met een volledig aangepaste userinterface en een nieuwe analysefunctionaliteit genaamd de CockPIT, als vervanger van de verouderde ReportBox. Ook kwamen er een aantal ‘social’ functies, zoals de mogelijkheid om te zien wie er nog meer was ingelogd. Gaandeweg zijn er ook binnen de 2.x lijn diverse technische verbeteringen doorgevoerd om bij de tijd te blijven. Rond 2016 zijn we tevens begonnen met het aanhaken van een externe partij t.b.v. extra security in ons platform. Op basis van hun kennis en rapporten zijn er een aantal security optimalisaties doorgevoerd waardoor Smile nog veiliger werd. Sindsdien worden er periodiek volledige code-audits gedaan en doen we dagelijkse scans op nieuwe CVE’s.

Vooruitlopen op de AVG en de ISO27001 certificeringen die Smile wilde halen zijn we ook begonnen met het introduceren van extra logging functies. Hieruit is bijvoorbeeld de ‘audit trail’ geboren. Later hebben we dit ook doorgepakt en is de software volledig AVG-proof geworden met de introductie van verschillende AVG-functies. Het werd bijv. mogelijk om gegevens te markeren als persoonsgegeven en in de rechtengroepen vast te leggen wie persoonsgegevens mocht inzien. De persoonsgegevens kregen een bewaartermijn waarna ze geanonimiseerd werden, er kon beheerd worden of persoonsgegevens geëxporteerd mochten worden en persoonsgegevens werden verborgen in de GUI als iemand ze niet mocht zien. Alle social functies uit 2013 zijn met het oog op de AVG weer ontmanteld.”

De stap naar SaaS

Jasper-Willem: “Sinds 2017 (de 2.4) is Smile ook meer met SaaS gaan doen en is de naam SmileCom vervangen door Het Smile Platform. Een belangrijk onderdeel van SaaS is het gescheiden houden van gegevens van verschillende accounts en dus klanten, daar is in de code dan ook veel aandacht aan besteed. In eerste instantie moest er bij iedere aanpassing ontzettend goed opgelet worden of filters wel voldoende rekening hielden met verschillende accounts om data af te schermen, ondertussen zorgt de software er automatisch voor deze ‘datascheiding’.

In 2018 zijn we begonnen aan onze 2.6 versie. We kozen er voor om niet door te bouwen op de – ondertussen ook weer outdated – Struts-backend maar over te stappen het meer toekomstvaste Spring framework in combinatie met Angular. Omdat Struts en Spring naast elkaar kunnen blijven werken, werden de Struts onderdelen in kleine behapbare brokken omgeschreven naar Spring, conform het zogeheten boyscout principe. Met behulp van Angular zijn we ook aan de slag gegaan om stukje bij beetje de componenten in de userinterface om te schrijven naar deze nieuwe techniek. In de 2.6 was dit het Multi-select component waarmee n-op-n relaties veel makkelijker aanpasbaar zijn dan de bulk-koppelen feature die tot dan toe werd gebruikt.”

Een nieuw release schema

Jasper-Willem: “Vanaf de 3.0 is het release schema aangepast. In plaats van 1x per jaar een nieuwe major zijn we overgestapt naar 3 á 4 major releases per jaar. Hierdoor hebben we meer mogelijkheid om brekende wijzigingen ‘uit te stellen’ tot een nieuwe major versie en alleen patches uit te brengen in de al gereleasde majors. De stabiliteit van het platform heeft hierdoor een enorme boost gekregen en het heeft de deuren opengezet om applicaties op onze eigen servers automatisch te gaan updaten.

De focus binnen de 3.x lijn is o.a. gemakkelijke integratie met andere software. Hiervoor hebben we bijvoorbeeld microflows en webhooks ontwikkeld, waarmee het nog gemakkelijker wordt voor functioneel beheerders om de Smile applicatie aan te sluiten op andere applicaties in hun landschap. Tijdens de 3.0 is ook de overgang naar een volledige single-page applicatie in gang gezet, dit geeft gebruikers veel meer een herkenbaar ‘website-gevoel’. Sindsdien zijn alle nieuwe GUI-elementen in Angular gemaakt: o.a. de importmanager werd aangepast, grids en overzichten, uitgebreid zoeken en natuurlijk de rightpane. Ook zijn we begonnen met het in memory houden van configuratie. Hierdoor hoeft de applicatie minder vaak naar de database en kunnen we sneller configuratiefouten detecteren (zo is ook de application health geboren). Voor het in memory houden wordt wederom het boyscout principe toegepast om zo stukje bij beetje steeds meer van de applicatie ‘in memory’ te zetten. Hoe meer in memory, hoe sneller de applicatie.

In het verleden is vaker geprobeerd om een nieuwe manier te vinden waarop uitgebreide zoekopdrachten gemaakt konden worden en in de 3.1 is dat naar onze mening eindelijk goed gelukt. De nieuwe manier om te sorteren en filteren op kolomkoppen en de manier waarop we de regels van een zoekopdracht tonen zijn in deze versie sterk verbeterd.”

Material design

Jasper-Willem: “In de 3.x lijn bewegen we de applicatie ook steeds meer richting standaard Material Design, een veel gebruikte – en daardoor voor gebruikers herkenbare – webstandaard. Voorheen werd de userinterface gemaakt op de manier waarop wij zelf vonden dat dingen eruit horen te zien en ondanks dat dat prima werkte was het bij iedere aanpassing een discussie om op de pixel nauwkeurig iets mooi te krijgen. Nu we Material Design volgen, is deze discussie een stuk makkelijker: we volgen wat de guidelines voorschrijven tenzij we een goede reden hebben om af te wijken. De grote voorbeelden van Material Design componenten zijn in de 3.2/3.3 terug te vinden in de nieuwe vragenlijst module en de organized view. Beide zijn ook mooie voorbeelden van componenten die meer eenvoud brengen voor gebruikers door losse pagina’s te maken voor specifieke acties.

In de komende 3.x. releases zal de gehele front-end de Material Design guidelines gaan volgen en gaan we zoveel mogelijk onderdelen van de applicatie ‘single page’ maken. Ook werken we aan verdere optimalisaties van de nieuwe vragenlijstmodule én aan diverse andere zaken die de veiligheid, performance en het gebruiksgemak dienen. Want als er één ding duidelijk is, is het wel dat ontwikkeling nooit stopt. Gelukkig is het onze passie, dat maakt dat we elke dag met veel plezier werken aan zaken die gebruikers op een nog betere manier ondersteunen. Ik ben reuze benieuwd waar we over nog eens 25 jaar zullen staan!”