Technisch Architect Non-Functional Requirements

Met de opkomst van internet en smartphones verschuift de focus van fysieke retail en telefonische klantenservice naar multi-channel selfcare, van beperkte openstellingstijden naar 24-uurs, 7 dagen per week beschikbaarheid van de leverancier. Dit vereist een hoge automatiseringsgraad en robuustheid van alle onderdelen van de applicatie-keten.

Situatieschets

Een telecomoperator heeft jarenlang de nadruk gelegd op “wat” (functional/business requirements) IT-systemen leveren en veel minder op “hoe” (non-functional requirements) de functionaliteit geleverd wordt. Hierdoor is een allegaartje van oplossingen (vaak houtje-touwtje) voor soortgelijke problemen ontstaan. Naarmate de druk op de systemen toenam (groei in orders, groei in opvragingen, langere openstellingstijden, hogere beschikbaarheid, grotere gevolgen bij niet-beschikbaarheid), werd het steeds problematischer om de systemen (en daardoor business-ketens) in de lucht te houden en te laten performen.

Methode

Een technisch architect van Ventus werd ingeschakeld bij het trouble-shooten van productie-problemen (m.n. op het gebied van performance, robuustheid, capaciteit en stabiliteit) in en met applicaties en applicatie-ketens. Deze problemen werden onder meer veroorzaakt door het aansluiten van steeds meer websites, introducties van smartphone apps, nieuwe interfaces en nieuwe functionaliteiten). Door zijn brede kennis van het applicatie-landschap (functioneel) en de gebruikte technologie (Windows, SQLServer, Unix, Oracle) was de technisch architect in staat symptomen van oorzaken te onderscheiden en zo voor de telecomoperator een goede oplossingsrichting te formuleren, waarbij de oplossingsrichting niet altijd een IT-oplossing was, maar ook procesmatig of opleiden van de gebruiker kon zijn. De rol van de technisch architect verschoof steeds meer van re-actief (problemen oplossen) naar pro-actief (problemen voorkomen).

Door de nadruk te leggen op het vooraf formuleren, invullen (SMART) én controleren van de implementatie van “non-functional requirements” gedurende het bouw- en testtraject en daarna de resultaten te monitoren in productie werd een inhaalslag gemaakt waardoor de applicaties weer “fit-for-purpose” werden, minder resources nodig hadden én beter presteerden op performance, robuustheid, beschikbaarheid, schaalbaarheid en beheerbaarheid. De uitwerking van de “non-functional requirements” resulteerde in richtlijnen voor ontwerp en ontwikkeling van software en een standaard architectuurinrichting voor applicaties, waaraan elke nieuwe ontwikkeling op de systemen moesten voldoen.

Resultaat

Enkele voorbeelden van behaalde resultaten:

  • Redesign van de orderinleg en -verwerking: het aantal orders dat kon worden ingelegd steeg van max. 1000 per uur naar 10.000 per uur op dezelfde hardware, terwijl de doorlooptijd van orderverwerking daalde van 2 minuten naar minder dan 1 minuut.
  • Reductie van het aantal ernstige verstoringen van meer dan 20 in 2006 tot 1 in 2016.
  • Betere beheerbaarheid en voorspelbaarheid door inrichting van logging en monitoring.
  • Hogere performance door verbeterde technische implementaties (gebruik maken van de sterke punten van de infrastructuur, operating system en databases), zoals bijvoorbeeld een van de response tijden van 4 seconden naar minder dan 1 seconde bij een toename van 400% in het aantal aanvragen voor een aantal veel gebruikte services door de logica niet langer in de database af te handelen maar in de webservice.

Conclusie

Door de verbeteringen op “non-functional” gebied heeft de telecomoperator enkele jaren langer plezier gehad van de “oude” systemen met relatief geringe kosten. Door deze besparingen ontstond er financiële ruimte om een geheel nieuw systeem (deels standaard, deels maatwerk) te realiseren. Bij de realisatie van de nieuwe systemen zijn de “non-functional requirements” expliciet meegenomen.