Een flexibel en schaalbaar IT-landschap zorgt dat je snel kunt innoveren, nu en in de toekomst. Is je bedrijf snel gegroeid en heb je veel nieuwe functionaliteit uitgerold? Dan is het misschien tijd om weer eens kritisch naar je landschap te kijken. Dit zijn onze 4 stappen naar een IT-landschap dat weer helemaal klaar is voor de toekomst.
Als developers worden we vaak ingehuurd om een specifieke klus te klaren. En dat doen we dan ook met plezier. Maar waar we kunnen, laten we het IT-landschap van de klant altijd wat mooier achter dan we het aantroffen. Beginnen we een project met een discovery phase? Dan adviseren we ook altijd over de belangrijkste aanpassingen in het IT-landschap. In adviestrajecten zien we vaak dat flexibel en schaalbaar maken van het landschap een hoge prioriteit moet krijgen. Want hoe kun je groeien als je architectuur je in de weg zit?
Wat we bedoelen met een ‘ontkoppeld’ landschap
Voor niet-developers is de term ‘ontkoppelen’ vaak verwarrend. Want je kunt natuurlijk geen business runnen als je systemen helemaal ontkoppeld zijn. Het uitwisselen van data tussen systemen is juist essentieel voor goede bedrijfsprocessen. Wat we bij ‘ontkoppelen’ in feite doen, is voor ieder systeem apart bepalen wat het zou moeten doen en – vooral – wat het niet zou moeten doen. Als we dat bepaald hebben, halen we functionaliteit die niet in een systeem hoort weg en brengen die ergens anders onder. We hebben dan dus de functionaliteiten ontkoppeld. Om toch data uit te kunnen wisselen laten we de systemen communiceren via API’s (lees hierover ook ons Handboek API-management). We zetten dus de stap van tight coupling, een situatie met veel complexiteit, afhankelijkheden en onduidelijkheid, naar loose coupling, een overzichtelijke situatie met systemen die min of meer onafhankelijk een duidelijk gedefinieerde taak uitvoeren.
Waarom ontkoppelen belangrijk is
Het ‘los koppelen’ van je landschap is essentieel om je business wendbaar en onderhoudbaar te houden. Een landschap met teveel afhankelijkheden wordt kwetsbaar voor onverwachte fouten, zodra je wijzigingen gaat aanbrengen. Privacy en security zijn ook een belangrijke reden om je IT-landschap overzichtelijk te houden. Door data maar op één plek te bewaren en continu kritisch te kijken welke gegevens over welke lijnen gaan, verlagen we het risico van datalekken en schade door hacks. En zeg nou eerlijk: het is toch niet meer dan logisch dat wachtwoorden niet in het ordersysteem staan en betalingsgegevens niet in het web-CMS? Toch vinden we bij een project soms dezelfde klantdata op vijf verschillende plekken! In de volgende paragrafen vind je ons stappenplan voor een overzichtelijk IT-landschap.
Stap 1: vertical slicing
Het eerste wat je kunt doen om je landschap hanteerbaarder en flexibeler te maken, is het opdelen in functionele blokken. Ontwikkelaars hebben het dan over vertical slicing. We zoeken naar stukken functionaliteit die we makkelijk kunnen loskoppelen van de rest van het landschap. Want pas als je het hebt losgekoppeld, kun je rustig verder kijken of je de functionaliteit kunt uitbesteden of herbouwen. Of misschien (voorlopig) laten zoals hij is en er later nog eens naar kijken. Want je hoeft natuurlijk niet alles tegelijk te doen.Â
Voorbeelden van functionaliteiten die we graag lossnijden zijn fulfilment, voorraadbeheer, betalingen, abonnementsbeheer en CRM. Maar de lijst is oneindig en afhankelijk van de business van de klant.
De eisen die je stelt aan zo’n ‘functioneel blok’ veranderen ook met de tijd. Als je het netjes ‘apart zet’ kan het groeien, krimpen of veranderen zonder dat de rest van het landschap daar last van heeft.
Stap 2: legacy uitfaseren
Nu je landschap in functionele blokken verdeeld is, kun je per blok gaan kijken wat je ermee wilt doen. De meeste landschappen bevatten best veel legacy: software die al een paar jaar oud is en niet meer helemaal mee kan met de technische ontwikkelingen. Het integreren van zulke software in een modern, schaalbaar landschap is niet makkelijk. En het is ook niet altijd nodig. Sommige dingen kunnen gewoon weg, omdat er inmiddels een beter, betaalbaarder en moderner alternatief is.Â
Vaak zijn legacy-applicaties in de loop der jaren uitgebouwd met allerlei maatwerk-functionaliteit. We zien dat vaak bij Exact en SAP, maar we zien ook vaak CRM-systemen die zijn uitgebreid met marketing- en mailfuncties. Het onderhoud van dit soort maatwerk is meestal tijdrovend en foutgevoelig, maar de functionaliteit is vaak business critical. In zulke gevallen doen we ook binnen het systeem aan vertical slicing: we proberen de maatwerkfuncties stukje bij beetje naar nieuwe systemen te migreren, zodat alleen het kernsysteem overblijft. Als dat klaar is, kunnen we alsnog beslissen of we het legacy-systeem willen vervangen.
Stap 3: inkopen en uitbesteden
Wij bouwen maatwerksoftware, maar we bouwen nooit meer dan nodig is. Bij Enrise zijn we er voorstander van om zo veel mogelijk functionaliteit extern in te kopen. Externe leveranciers, bijvoorbeeld van CRM, CMS, betalingen, e-mailmarketing of ERP, concentreren zich 100% op hun product. Zij voegen dagelijks nieuwe functies toe en bewaken continu de veiligheid en performance van hun software en hun software wordt getest door honderden andere gebruikers. Daar kunnen wij nooit tegen op. Daarnaast zijn betalingen en e-mail complexe processen die je echt niet in eigen beheer wilt hebben. Zie bijvoorbeeld het stukje ‘E-mails versturen, niet zo makkelijk als het lijkt’ op onze pagina over systeemintegraties.
Stap 4: bouw een tussenlaag
Heb je veel systemen, dan is het slim om met een tussenlaag te werken die ze van elkaar isoleert. Zo’n tussenlaag noemen we vaak een Business Logic Layer (BLL) of, met een wat oudere term, een Enterprise Service Bus (ESB). In zo’n tussenlaag centraliseer je al je businesslogica en bouw je voorzieningen die zorgen dat je business ook kan draaien als een van de onderliggende systemen offline is. Een tussenlaag organiseert je landschap in een ‘stermodel’: de tussenlaag zit in het midden en communiceert aan één kant met al je backend-systemen en aan de andere kant met al je apps en websites.
Het alternatief voor zo’n tussenlaag is een systeem waarbij systemen direct met elkaar koppelen. In het gunstigste geval levert dat een ‘spinnenwebmodel’ op, maar vaak lijkt het meer op spaghetti. Maar het is in zo’n landschap moeilijk om een plek te vinden voor complexe businesslogica. Bij een usecase als ‘we willen dit type factuur naar dit type klant alleen binnen kantooruren versturen’ zijn meestal meer dan twee systemen betrokken. In het spinnenwebmodel wordt de oplossing dan snel onoverzichtelijk.
iPaaS: een tussenlaag van een derde partij
Ook een tussenlaag kun je ‘as a service’ inkopen. Voorbeelden hiervan zijn de integratieplatformen in de cloud van Dell Boomi, Mulesoft en Alumio. Het voordeel van zo’n platform is dat je het niet zelf hoeft te bouwen. Meestal is het een kwestie van configureren, met een visuele editor, en kan IT er zelfstandig mee aan het werk, zonder dat er een developmentteam nodig is. De developers kunnen zich concentreren op het echte maatwerk. Het grote nadeel van deze platformen is vaak de prijs. Alumio, een platform waar wij graag mee werken, is de gunstigst geprijsde optie. Een belangrijke voorwaarde voor het inzetten van iPaaS is dat al je platformen extern te benaderen zijn. Heb je nog systemen on-premises staan, dan moet je alsnog ontwikkelwerk doen om iPaaS te kunnen gebruiken.
Meer leren over het ontkoppelen van je landschap? Kijk deze aflevering van Enrise Business Talks en Steven praat je er doorheen.
Duik dieper in de materie en lees ook het Handboek API-management
