Techniek

Het Abillity®-platform

Het Abillity®-platform moet blijvend voldoen aan hoge eisen, bijvoorbeeld op het gebied van performance en security. Voor nieuwe softwareontwikkeling maken we dan ook gebruik van moderne (maar bewezen) technieken. De robuuste softwarearchitectuur borgt veilige en gestandaardiseerde integratie met andere applicaties. Onze werkwijze – inclusief het toepassen van automatisering in het test- en uitleverproces – dwingt softwarekwaliteit af en vertaalt zich voor onze klanten naar stabiliteit, veiligheid en schaalbaarheid.

Domain-Driven Design (DDD)

Wij zijn specialisten binnen ons (FinTech) vakgebied, maar onze klanten zijn specialisten binnen hun eigen domein. Elk specialisme kent specifieke terminologie, waardoor er al snel sprake is van vakjargon. Zeker in een ICT-project is het cruciaal dat alle betrokken partijen dezelfde taal spreken. Waar denk jij bijvoorbeeld aan bij termen als ‘betaaltermijn’, ‘betaalregeling’ en ‘betaalplan’? Voor ons zijn dit drie verschillende concepten, die binnen jouw organisatie zomaar andere benamingen kunnen hebben. Daarmee ligt miscommunicatie op de loer en als dit niet wordt ondervangen, kan dit leiden tot software waar je niet om hebt gevraagd. Het kost dan tijd en geld om dit achteraf te repareren. Voorkomen is vele malen beter (en goedkoper) en daar helpt een DDD-aanpak bij.

Hoe je iets noemt is niet eens het allerbelangrijkste, zolang je maar allemaal dezelfde begrippen en definities hanteert om de te automatiseren processen te beschrijven (en begrijpen).

Daarom hanteren wij bij het ontwerpen van onze software een voor iedereen begrijpelijke en zo herkenbaar mogelijke terminologie en bouwen we eerst het ‘functionele domein’ op uit deze definities. Vervolgens kan dan op basis daarvan – vanuit een solide begrip van de materie, eenvoudig te valideren door onze klanten – het technische ontwerp (‘Design’) worden gerealiseerd, dat daarmee dus ‘Domain-Driven’ is.

Met deze (in de praktijk bewezen en in de softwarebranche hoog aangeschreven) benadering dicht je ook de kloof die vaak bestaat tussen ‘business’ (vaak alfa-denkers) en ‘techniek’ (vaak bèta-denkers), ofwel tussen gebruikers en programmeurs.

Modulaire opbouw

Bij veel softwareprojecten moet eerst een keuze worden gemaakt tussen de inzet van een standaardoplossing of het bouwen van maatwerk. Het eerste kan goedkoper zijn, maar vraagt concessies aan functionaliteit. Het tweede kan een beter passende oplossing opleveren, maar is vaak duurder en mist niet zelden bepaalde basisprincipes of handigheidjes.

In onze filosofie combineren we het beste van beide werelden door onze software modulair op te bouwen (rondom afgebakende functionele gebieden zoals b.v. facturatie en debiteurenbeheer), maar door daarnaast alle mogelijke functionaliteit ook in 3 lagen te verdelen:

  • Generiek: dit is functionaliteit die elke klant nodig heeft, denk bijvoorbeeld aan autorisatie, auditing en logging, maar ook aan een tabel met landcodes.
  • Domeinspecifiek: dit is functionaliteit die klanten binnen een bepaald functioneel domein nodig hebben, bijvoorbeeld ordertypes binnen een logistiek domein of ouderdomsanalyses binnen debiteurenbeheer.
  • Klantspecifiek: dit is functionaliteit die alleen een specifieke klant nodig heeft, bijvoorbeeld een specifieke koppeling of rapportage.

Bij elk verzoek dat we van een klant krijgen denken we na over ‘de vraag achter de vraag’ en of we het verzoek het beste kunnen invullen met een generieke, domeinspecifieke of klantspecifieke oplossing. Wanneer we niet voor klantspecifiek kiezen, verbeteren we ons platform ook meteen voor andere klant(groep)en.

Daarnaast denken we goed na over in welke module bepaalde functionaliteit ondergebracht moet worden met (vanuit technisch perspectief) oog voor ‘dependencies’ (afhankelijkheden) en ‘separation of concerns ’. Dit verhoogt de onderhoudbaarheid.

Het grote voordeel van deze aanpak voor onze klanten is een (featurerijke) standaardoplossing die naadloos uitgebreid kan worden met maatwerk, dat eveneens ‘productized ’ aanvoelt en goed onderhouden kan worden.

Techniek

Het Abillity®-platform is gebaseerd op een Service Oriented Architecture (SOA). Frontend en backend wisselen via een Backend-For-Frontend (BFF) API veilig (en versleuteld) informatie uit. Het backend is ontwikkeld in .NET Core, het frontend in Angular.

Het systeem is ‘Code-First’, waarbij het entiteitenmodel eerst in code wordt gedefinieerd. Er wordt gebruik gemaakt van Microsoft Entity Framework (EF Core) en er is geen logica geïmplementeerd op de database. Als datastore wordt grotendeels gebruik gemaakt van MS SQL Server. Data kan desgewenst ‘encrypted at rest’ worden opgeslagen, waarbij sleutelbeheer wordt ingeregeld. Waar nodig en nuttig kan gebruik gemaakt worden van andersoortige datastores, zoals document databases.

Voor backend logica schrijven ontwikkelaars unit tests, die tijdens het bouwen van versies worden uitgevoerd. Zo wordt automatisch getest of er niets ‘stuk’ is gegaan als gevolg van wijzigingen. Ook het frontend wordt automatisch getest, gebruikmakend van Cypress, waarbij diverse end-to-end tests zijn voorgedefinieerd. Dit resulteert in optimale betrouwbaarheid van nieuwe softwareversies.

Deployment vindt geautomatiseerd plaats via build pipelines en Docker containers, waardoor de applicatie eenvoudig in verschillende (cloud)omgevingen te hosten is. Ook logging en daarop gebaseerde monitoring (inclusief health checks) zijn geautomatiseerd.

Eenvoudige integratie

Voor een laagdrempelige integratie in een bestaand systeemlandschap biedt het Abillity®-platform een full featured REST API. Hiermee is de integratie van Abillity® met andere systemen – zowel voor de ingaande als uitgaande datastromen – snel te realiseren, ook als dit verder zou gaan dan de standaard beschikbare calls. Desgewenst kunnen we generieke API-calls uitbreiden met domeinspecifieke en zelfs klantspecifieke velden en logica, of geheel ‘to the point’ API-calls realiseren, mocht dat de beste oplossing zijn.

Zeker in landschappen met wat oudere (‘legacy’) systemen komen we situaties tegen waarbij een API-koppeling net een brug te ver is. In dat soort gevallen kunnen we ook koppelen via bestandsuitwisseling (typisch secured FTP). Op ons cv staat een indrukwekkende lijst met systemen waarmee we succesvol koppelingen hebben gerealiseerd. Deze ervaring brengen we (dus) ook aan tafel bij nieuwe klanten.

Performance en schaalbaarheid

Een duidelijk onderscheidend vermogen van het Abillity®-platform is dat het efficiënt met zeer grote hoeveelheden data kan omgaan. Onze oplossingen zijn ontworpen met als insteek hoge data volumes te verwerken, soms wel tientallen tot honderden miljoenen transacties per dag.

Performance vraagt voortdurend om aandacht, omdat zowel de omvang als samenstelling van (klant)databases kunnen wijzigen. Wij bewaken de performance via monitoring en besteden – indien nodig – tijdig en proactief aandacht aan ‘tuning’ van de performance.

Dankzij de architectuur van de applicatie kan ook altijd ‘horizontaal’ opgeschaald worden, door meer (i.p.v. zwaardere) hardware bij te schakelen. Zeker in cloud computing situaties kan dat met de huidige stand van techniek ook zeer kosteneffectief, door ‘on demand’ resources op- of af te schakelen. Stel dat de piekbelasting van processen binnen jouw organisatie op (of vlak na) de eerste dag van de maand ligt, dan kunnen we automatisch rond die tijd voldoende resources activeren die daarna weer vrijgegeven worden (zodat er niet de hele maand voor betaald hoeft te worden).

Bovenstaande gaat vooral over de performance van dataverwerking aan het backend. Daarnaast is uiteraard een snel en goed werkende grafische user interface (GUI) van groot belang. Ook de performance aan het frontend geven we binnen ons softwareontwikkelproces veel aandacht, waarbij we bijvoorbeeld goed nadenken over het ‘cachen’ van bepaalde informatie versus momenten waarop data aan het frontend juist ververst moet worden. Dit leidt tot een zeer prettige gebruikerservaring, weinig wachttijd en (dus) hoge productiviteit.

Van ontwikkeling naar productie

Voor elk project richten wij een OTAP-straat in (Ontwikkel, Test, Acceptatie en Productie). De eerste twee omgevingen gebruiken we intern, Acceptatie en Productie zijn voor onze klant.

Nieuwe functionaliteit ontstaat eerst op de ontwikkelomgeving. Onze analisten schrijven daarvoor user stories (specificaties) uit voor ontwikkelaars (op basis van klantverzoeken of als gevolg van autonome productontwikkeling). Ontwikkelaars bouwen de nieuwe software, waarbij minimaal een vier-ogenprincipe geldt: tenminste één andere ontwikkelaar doet een review op de code van de verantwoordelijke programmeur, waarbij ook getoetst wordt op het correct toepassen van standaarden en de leesbaarheid (dus onderhoudbaarheid) van de geschreven code.

Ook schrijven ontwikkelaars (zelfstandig of in samenwerking met test automation specialisten) automatische softwaretests. Na het succesvol doorlopen van de automatische tests kan een testversie worden gebouwd, zodat de nieuwe functionaliteit ook door onze testers beproefd kan worden. Staan daarna alle lichten op groen, dan gaat de nieuwe software door naar het volgende stadium. In dit proces streven we naar ‘first time right’ en daar waar rework ontstaat, proberen we daarvan te leren om ons ontwikkelproces verder te verbeteren.

Zodra een nieuw ‘product increment’ is ontstaan, vaak na een ontwikkelsprint waarin meerdere user stories zijn opgenomen, en nadat ook dit 100% door de automatische en handmatige tests is gekomen, kunnen we een versie uitleveren naar de acceptatieomgeving van onze klant(en). Op basis van release notes kunnen de gebruikers de nieuwe functionaliteit dan uitproberen en beproeven.

Na goedkeuring door de klant wordt de nieuwe release op vaak vooraf met elkaar afgestemde tijdsloten naar de productieomgeving gepromoveerd en staat de nieuwe software ‘LIVE’.

Binnen deze cyclus is niet alleen het testen (van zowel backend als frontend) geautomatiseerd, ook het uitleverproces (deployment) verloopt volledig automatisch. Dit bespaart tijd en minimaliseert de kans op fouten en werkt dus kwaliteitsverhogend. Dankzij moderne technieken zoals containerization kan de downtime tijdens upgrades geminimaliseerd worden en is feitelijk sprake van continuous integration en continuous deployment (CI/CD).

Waar we onze software op uitleveren, hangt af van de wensen van de klant. Diverse scenario’s zijn mogelijk, variërend van bij de klant zelf (‘on premise’) tot ‘in de cloud’ en allerlei scenario’s daartussenin (bijvoorbeeld private cloud). Het type cloud (bijvoorbeeld Azure of AWS) maakt daarbij niet uit; onze oplossing is cloud-onafhankelijk. We kunnen onze klanten ook op dit vlak volledig ontzorgen door gebruik te maken van onze eigen hostingfaciliteiten of die van diverse partners.

Meer informatie?

Ben je benieuwd of ons platform geschikt is voor jouw organisatie?
Wij gaan graag met je in gesprek!

Willem Lemmers

Senior Consultant

+31 297 382323 Plan een online demo in