Herken je je organisatie in onderstaande symptomen?
- Er wordt vaak om bestaande software heen gewerkt.
- Het algemene beeld van het interne applicatie landschap is negatief. Het is eerder een last dan dat het je verder helpt.
- Het oplossen van fouten en het toevoegen van nieuwe functionaliteit is lastig.
- Nieuwe initiatieven komen moeilijk van de grond.
- Nieuwe applicaties zijn lastig te koppelen aan je bestaande software.
Binnen organisaties zien we vaak dat de ontwikkeling van nieuwe digitale oplossingen wordt afgeremd door bestaande software of een interne IT afdeling, en dat is eigenlijk ook heel logisch.
Organisaties moeten investeren in nieuwe digitale toepassingen om de concurrentie voor te blijven. Om die reden gaat de investering vaker naar nieuwe mogelijkheden in plaats van onderhoud aan het bestaande.
Bij DIJ vinden we dat dit vraagt om een langetermijn strategie. Laten we zorgen dat je bestaande infrastructuur niet aanvoelt als een last, maar als een groeiversneller!
Ok, hoe pakken jullie dat dan aan?
Hoe ga je van je oude software systeem weer een bruisend hart van digitale innovatie maken? Bij DIJ hebben we vaker met dit bijltje gehakt en delen graag één van onze strategieën.
Kleine disclaimer: dit is zeker niet de enige weg naar Rome, mocht je een advies op maat willen, neem dan eens contact met ons op of kom langs tijdens ons Digitaal Spreekuur.
Stap 1: Inzicht
Voordat we ook maar met één vinger aan je bestaande applicaties zitten, zorgen we eerst voor inzicht. We willen weten wat er gebeurt op je platform. Dit doen we door zoveel mogelijk lagen te voorzien van logging en te centraliseren met behulp van bijvoorbeeld ELK-stack of Datadog. Hierbij kan je denken aan het netwerk, de servers, de webservers, de database en diverse andere applicaties die draaien op je platform.
Daarnaast brengen we je landschap in kaart zover dat nog niet is gedaan om een goed beeld te krijgen van de configuratie en afhankelijkheden.
Stap 2: Geautomatiseerd testen
We realiseren ons als geen ander dat jouw applicaties bedrijfskritisch zijn. Zonder deze applicaties breekt binnen je organisatie paniek uit. Om dit te voorkomen kiezen we ervoor de meest kritische functionaliteit onder te brengen in automatische tests.
Wat dit doet is in principe een gebruiker simuleren die een bepaald proces doorloopt. Zolang deze tests slagen weten we zeker dat het kritieke proces nog draait. Wat dit enorm krachtig maakt is dat we dit in de ontwikkelstraat kunnen implementeren en automatisch kunnen draaien bij elke wijziging zodat we de kwaliteit kunnen waarborgen.
Stap 3: Automatiseer alles
We optimaliseren je nieuwe ontwikkelstraat zodat we sneller kunnen ontwikkelen. Dit is mogelijk door een geautomatiseerde pijplijn neer te zetten die security, kwaliteit en stabiliteit van de oplossing borgt. (DevOps)
(Hackernoon)
Door geautomatiseerde tests hierin te hangen en pas wanneer alle tests slagen de oplossing volautomatisch naar productie te brengen (deployment), zorgen we ervoor dat er niets misgaat. Daarnaast kunnen we in deze pijplijn nog veel meer interessante quality assurance technieken toepassen zodat we feedback loops verkorten en nog sneller en veiliger nieuwe functionaliteit kunnen realiseren.
Daarnaast kunnen we de releases linken aan het verkregen inzicht in stap 1 om te kijken of alles soepel verloopt en welke impact de wijzigingen hebben op de performance van het geheel.
Stap 4: Heroverweeg je architectuur
Bij beleggen of in het casino is een succesvolle strategie om goed te spreiden. In softwaredevelopment hebben we dat de afgelopen jaren niet goed gedaan. We hebben vaak 1 groot systeem gebouwd die steeds groter en complexer is geworden en uiteindelijk onbeheersbaar. Daarnaast is het onmogelijk om slechts alleen een deel van de applicatie te vervangen zonder de andere onderdelen aan te raken.
Wij adviseren om verschillende lagen uit elkaar te trekken en onder te brengen in verschillende onderdelen, met in gedachte dat ze onafhankelijk van elkaar moeten kunnen opereren. (microservices).
(BMC)
Dit zorgt ervoor dat we een aantal problemen oplossen. Dit maakt het beter onderhoudbaar, minder gevoelig voor een brain-drain en creëert de mogelijkheid voor makkelijker kunnen toepassen van nieuwe technologieën.
Verder is de stap naar cloudtechnologie als Google Cloud, Microsoft Azure en Amazon Web Services hiermee kleiner en is schaalbaarheid ook een groot voordeel van deze aanpak.
Stap 5: Stap-voor-stap refactoren
Het is afhankelijk van de situatie, maar onze voorkeur heeft het project op te delen in een aantal logische onderdelen en per onderdeel stap voor stap te gaan vernieuwen.
Overigens kan het natuurlijk zijn dat er onderdelen zijn waarbij een stuk standaardsoftware de beste optie is. Dit hoeft in deze strategie geen enkel probleem te zijn.
Het oude en het nieuwe landschap kan naast elkaar draaien en per onderdeel kan je gebruikers routeren. Door middel van de automatische tests weten we of het nog steeds doet wat het moet doen en door het inzicht van we hebben in alle lagen van het systeem weten we of er zich vreemde situaties voordoen.
Kan dit bij jou allemaal niet?
Is je applicatie closed-source, te oud of te groot? Je kan er ook voor kiezen om het bestaande te laten voor wat het is. Zolang je bijvoorbeeld een nieuw te bouwen applicatie toegang kan geven tot dezelfde data, kun je op een zelfde manier langzaam stap-voor-stap migreren naar een nieuwe omgeving.
En dan?
Zodra je door alle onderdelen bent kun je op een gegeven moment de conclusie trekken dat de oude oplossing uitgezet kan worden. Feest! Als mooi bijproduct heb je dan een ontwikkelstraat staan die continu kwaliteit kan leveren.
Wil je weten wat voor jou een goede strategie is of wil je een keertje sparren over iets anders? Kom vrijblijvend langs op ons digitaal spreekuur!
