Artikel

Is mijn ICT Total Loss?

Innovatie in ondernemingen hangt sterk af van de het kunnen koppelen van informatiesystemen. Dit zodat bedrijfsprocessen het werk zaaksgewijs kunnen organiseren. Maar dan mag niet de businesscase overhoop worden gehaald door te hoge ICT-verbouwingskosten. De vraag is dan: hoe kunnen we dit zien aankomen en voorkomen?

Dit artikel is bedoeld voor managers en gaat over het verkrijgen van een juiste beeldvorming van de staat waarin de ICT verkeert, met behulp van visuele enterprise architectuur. Op basis van standaard soorten architectuurvisualisaties uit de methode Dragon1 worden in dit artikel voorbeeldvisualisaties aangereikt die jezelf of door de architect kan laten toepassen op de ICT om te beoordelen wat voor de onderneming de beste optie is: vernieuwen of nieuwbouw?

Wat is Total Loss?

Van de auto kennen we het concept Total Loss. Deze term wordt gebruikt om aan te geven dat de auto niet meer gerepareerd kan worden of wanneer het niet aantrekkelijk is om de auto te repareren. Zo zijn er zijn twee vormen van Total Loss.

Technisch Total Loss is de term die we hanteren wanneer een auto, bijvoorbeeld na een ongeluk, achterstallig onderhoud of vanwege ouderdom, in een dergelijke schadestaat verkeerd dat deze niet meer te repareren is. Hoeveel geld je er ook in stopt, er is eigenlijk geen sprake van reparatie. Er wordt een complete nieuwe auto gebouwd.

Economisch Total Loss is de term die we hanteren wanneer een auto op zich wel in een schadestaat verkeerd dat deze nog goed te repareren is, alleen dat de kosten die de reparatie met zich meebrengt niet meer verantwoord zijn. Dit is dan vergeleken met de dagwaarde van de auto of de vervangende waarde van de auto.

Bij ICT zijn deze twee begrippen ook in te zetten voor de achterstand aan onderhoud die in veel ICT-omgevingen aanwezig is en voor het in productie nemen van zelfgebouwde danwel onvoldoende geteste nieuwbouw informatiesystemen.

Als een onderneming gaat fuseren, centraliseren, decentraliseren, e-dienstverlening optuigen, selfservice aanbieden en virtualiseren zijn de investeringen die worden gedaan in ICT zeer hoog. Dit maakt het legitiem om 1%-5% van het budget te investeren in het maken van architectuurvisualisaties om de huidige staat van de ICT-omgeving te kunnen analyseren in termen van het wel of niet Total Loss zijn. Dit is in feite de risicopremie.

Verouderde technologie veroorzaakt een economische Total Loss

In de ICT van een grote onderneming is er vaak sprake van maandelijkse vernieuwing. Elke maand worden er nieuwe informatiesystemen ingevoerd of ingrijpende wijzigingen op de informatiesystemen doorgevoerd, zoals het softwarematig flexibel koppelen van informatiesystemen aan elkaar. Echter lang niet alles wordt geregeld vernieuwd. Met als gevolg dat sommige ICT-oplossingen wel vijf tot tien jaar oud zijn, voordat voor deze systemen voor het eerst softwarematig worden gekoppeld aan andere ICT-oplossingen. Vanwege de verouderde technologie zijn dan de kosten zo hoog voor het aansluiten, dat het oude systeem beter kan worden vervangen door één of meer nieuwe beter koppelbare oplossingen. Weet jij waar de legacy zit in de ICT?

Soms worden er tijdelijke ICT-oplossingen aangebracht in de onderneming die eigenlijk nooit meer goed worden opgeruimd, en op een gegeven moment een belangrijke onmisbare constructie vormen in de ICT. Tijdelijke ICT-oplossingen laten zich vaak typeren door niet- standaard te zijn, zelf gebouwd, onvoldoende gedocumenteerd en minder qua prestaties, levensduur, kwaliteit en capaciteit. Als dan op de tijdelijke ICT-oplossingen weer verder gebouwd wordt, zijn er vaak capaciteits- of kwaliteitsvraagstukken die maken dat de uitbreidingen veel kostbaarder zijn dan wanneer er niet op een tijdelijke ICT-oplossing uitgebreid wordt.

In feite wil iedereen in de onderneming ‘stootvaste’ en goed samenwerkende ICT-oplossingen die niet bij kleine aanpassingen onderuit gaan of veel moeite kosten om aan te sluiten aan andere ICT-oplossingen.

Voor elke ICT-omgeving is het mogelijk om, ver voordat er een vernieuwing of wijziging dient te worden doorgevoerd, in beeld te brengen waar er verouderde technologie in de ICT-omgeving zit, welke moeite in tijd, geld en resources het softwarematig en hardwarematig koppelen van een ICT-oplossing is. Ook is in beeld te brengen welke ICT-oplossingen van tijdelijke aard zijn en hoe er wordt gedacht om van die tijdelijke oplossingen af te komen. Wat is het plan daarachter?

Door deze zaken te visualiseren ontstaat er voor bestuur, directie en management in de onderneming een begrijpelijk beeld van belangrijke aspecten die aangeven of een ICT-omgeving Total Loss is. Door voorafgaand aan een innovatie dit beeld te hebben kan op tijd worden gekozen voor nieuwbouw of verbouwen op basis van inzicht. Dit in plaats van er tijdens projecten achter te komen dat de businesscase van een vernieuwing niet gehaald wordt vanwege ‘voortschrijdend inzicht’ op de verbouwingskosten.

Onvoldoende testen van ICT-oplossingen veroorzaakt een technische Total Loss

Omdat elke onderneming uniek is, realiseren veel ondernemingen hun eigen informatiesystemen alleen of met derden zoals consultancybedrijven of softwarehuizen. Ook worden standaardsystemen door leveranciers vaak voorzien van maatwerkuitbreidingen. Dit allemaal zodat de informatiesystemen flexibele duurzame en toekomstvast de bedrijfsprocessen in de onderneming ondersteunen.

Vanwege tijdsdruk wordt in veel gevallen tijdens de ontwikkeling bezuinigd op de testtrajecten. Dit wreekt zich echter. Een onvoldoende geteste ICT-oplossing brengt al snel schade aan gegevens, software of apparatuur aan. Stel dat een week lang wijzigingen op productiegegevens door een bedrijf niet worden opgeslagen, maar wel worden doorgegeven aan ketenpartners, dan ontstaan er op andere plekken problemen als deze externe gegevens weer de organisatie in komen.

Het vakgebied van testen leert ons dat herstelkosten, naarmate ze later in een ontwikkelproject of in productie moeten worden gemaakt, betekenisvol hoger zijn. Stel maar voor wat de herstelkosten of financiële schade is als andere bedrijven een tijd lang met foutief verstrekte gegevens hebben gewerkt. Hoe meer het back-uppen, installeren, beheren, gebruiken, integreren van nieuwe ICT-oplossingen wordt getest, des te groter is de kans dat eventuele herstelkosten voor fouten er niet voor zorgen dat de ICT Total Loss is.

Laat jezelf niet voor de gek houden!

Ik heb het vaak meegemaakt. De kosten voor aanschaf of ontwikkeling van een informatiesysteem zijn precies wat je bent overeengekomen met een leverancier. Echter bij het beheren, integreren en aanpassen van het informatiesysteem komt de aap uit de mouw: zeer hoge wijzigingskosten.

Dit komt vaak omdat de eisen die worden gesteld bij het ontwerp en de realisatie van het informatiesysteem onvoldoende gericht zijn op toekomstige behoefte, namelijk de kwaliteitseisen en prestatie-eisen van morgen. Stel je betere eisen, dan nemen de kosten van beheer in vergelijking af.

Het verdient aanbeveling om bij het visualiseren van een ICT-omgeving in beeld te brengen welke eisen aan prestaties en aan de kwaliteit van ICT-oplossingen zijn gesteld in het verleden en welke nieuwe eisen aan prestaties en aan de kwaliteit moet stellen voor de toekomst. Zo wordt al snel duidelijk welke ICT-oplossingen gaan knellen en welke eisen je voortaan beter kan stellen om een Total Loss te voorkomen.

Architectuurvisualisaties van Dragon1 bieden ondersteuning in regie op onderhoud en testen van ICT

Een werkwijze die we vanuit Dragon1 bij het visualiseren van ICT dienen toe te passen is: Je niet blind staren op technische producten van leveranciers. Maar vooral kijken naar de technische componenten waar de producten en de logische elementen uit bestaan die achterliggend zijn aan de technische componenten. Een tweede werkwijze die we vanuit Dragon1 toepassen is het inzichtelijk maken wat een technisch product, component, element of concept de onderneming kost in termen van kosten, tijd en resources voor ontwikkeling en beheer. Dit kan zowel voor de huidige situatie als voor de toekomstige situatie indien er veranderd moet worden of als er veranderd is.

In dit artikel volgen nu vier architectuurvisualisaties met een verschillend abstractieniveau waarmee gestructureerd in beeld is te brengen wat een onderneming aan ICT heeft. Als voorbeeld bedrijf is een niet-bestaande zorgverlener BetereZorg gekozen, waarvoor een architect visualisaties maakt, ter ondersteuning van het voorkomen dat de ICT Total Loss raakt op het moment dat er fundamenteel vernieuwd gaat worden. Achtereenvolgens brengen we op fysiek, logisch en conceptueel niveau een deel van de ICT in beeld. De visualisaties brengen samen een deel van de architectuur van de ICT van BetereZorg in beeld.

Nu volgt kort de uitleg van vier belangrijke kernbegrippen uit Dragon1 die centraal staan bij het maken van de Dragon1-architectuurvisualisaties die we in dit artikel aan bod laten komen. Een concept is een idee, abstractie van een implementatie, werking, werkwijze of aanpak. Een concept bestaat logisch gezien uit elementen. Elementen zijn logische functionele onderdelen die weinig tot geen implementatieaspecten kennen. De elementen van een concept worden met een component technisch gerealiseerd. Een component is een fysiek of digitaal technische entiteit. Technische producten zijn de oplossingen die leveranciers in de markt aanbieden waarmee componenten zijn in te vullen. Ook zelfgebouwde fysieke en digitale oplossingen zijn als technisch producten te beschouwen. Technische producten laten zich kenmerken door het hebben van een eigennaam, typenummer en versienummer.

Figuur 1, Overzicht technische producten in een ICT-infrastructuur.

Figuur 1 laat zien welke technische producten (typenaam en leverancier) onderdeel uitmaken van de ICT-infrastructuur. Aan deze visualisatie, hoe leuk ook, zien we echter niet of deze ICT Total Loss is of niet. De architect kon deze visualisatie wel goed gebruiken richting medewerkers en de manager inkoop, over welke ICT-onderdelen hij zich zorgen maakt en om hoeveel geld en welke servicecontracten het gaat.

De architect kan in figuur 1 aangeven wat de beheerkosten gaan worden in de toekomst van de producten. Zo wordt duidelijk welke producten onevenredig veel budget naar zich toe gaan trekken in de toekomst, en waar je dan wellicht van moet overwegen om er afscheid van te nemen. Echter of dat kan en hoe dat kan, daar zijn de volgende visualisaties voor nodig om de logische afhankelijkheden en verbanden te zien.

In figuur 2 zien we de aanwezige ICT-infrastructuurcomponenten die in figuur 1 met technische producten zijn ingevuld. Dit overzicht geeft al meer informatie wat de informatiekundige staat is van de ICT-omgeving, maar nog steeds kan de architect hiermee nog alleen maar brandjes blussen voor de korte termijn en nog niet structureel aan oplossingen werken. Figuur 1 en figuur 2 laten dezelfde ICT zien, maar met een ander perspectief, voor een andere doelgroep, vanuit een ander gezichtspunt.

In figuur 2 staan geen namen van producten of leveranciers, maar namen van technische oplossingen met implementatie kenmerken. Het perspectief in figuur 2 is samenwerking en koppeling van technologie in componenten. Het perspectief in figuur 1 is meer een leveranciers-producten-perspectief.

Figuur 2, Overzicht componenten in een ICT-infrastructuur.

In figuur 2 ziet de architect van BetereZorg al gelijk dat het softwarematig koppelen van de drie software applicaties (SAP, VC++ en ASP.NET) niet eenvoudig zal zijn, en dat daar veel tijd en geld in gaat zitten. Samen met specialisten op die terreinen kan de architect nu uitwerken wat een slimmere toekomstige applicatietechnologisch oplossing is. Voorafgaand aan de behoefte van de business kan de architect nu goed werk doen!

Ook hier kan de architect aangeven hoeveel een component kost. Bijvoorbeeld wat zijn de verschillen in kosten voor het ontwikkelen of koppelen van een bepaalde applicatietechnologie? En hoe is dat in de toekomst?

De architect zal er wellicht naar willen streven dat minimaal één van de drie applicatietechnologieën gaat verdwijnen en dat je bij voorkeur op één applicatietechnologie overgaat. In figuur 2 zien we dat er één database is die niet van standaard SQL gebruik maakt. Ook deze uitzondering is de architect een doorn in het oog. Figuur 2 maakt al meer inzichtelijk hoe de kwaliteit van de ICT omhoog kan gaan, maar voor het voorkomen van een Total Loss is nog meer nodig aan inzicht.

Wat van belang is voor het beoordelen van de staat van de ICT-omgeving, is om te kijken naar de informatiekundige en technologische concepten die zijn gebruikt in de ICT-omgeving. We hebben nu de technische producten en technische componenten in beeld, maar we weten nog niet welke informatiekundige concepten achterliggend zijn aan deze producten en componenten. Weten we dit wel, dan zorgt dat ervoor dat je kunt zien waar of van wie je in bepaalde mate afhankelijk bent: Ben je voor bepaalde oplossingen afhankelijk van specifieke producten van leveranciers? Of ben je afhankelijk van een bepaalde technologie die in verschillende producten leveranciers beschikbaar is.

Door in de ICT-omgeving ervoor te zorgen dat je niet afhankelijk bent van producten van leveranciers, maar van technologie dan zet je al een eerste stap in het voorkomen van een technisch Total Loss van de ICT-omgeving. Stel dat die ene leverancier van dat ene product niet (meer) in staat is jouw ICT-oplossing aan te passen, dan kan het een dure business worden om anderen de ICT-oplossing te laten aanpassen.

Hier zit overigens een addertje onder het gras: indien de organisatie een ICT-oplossing maatwerk heeft laten bouwen bestaande uit alleen maar open standaarden, dan nog kan het zijn dat je een afhankelijkheid naar de leveranciers van de ICT-oplossing hebt. Immers de ICT-oplossing is een product waar versiebeheer en doorontwikkeling op van toepassing is. Ook kan de leverancier een slim mechanisme of oplossingsrichting in de ICT-oplossing hebben gebruikt. In dit geval is er sprake van een nieuw concept en dan is het extra van belang dat dit goed gedocumenteerd wordt en bewust ervoor wordt gekozen om een afhankelijkheid op deze wijze naar een leverancier toe te creëren.

Voordat we naar de concepten gaan kijken dienen we eerst op logisch niveau de functionele ICT-elementen in beeld te brengen die met de technische componenten worden vormgegeven. Dit heeft als voordeel dat we als architect zonder enige vorm van implementatie of afhankelijkheid naar oplossingen en leveranciers toe kunnen kijken naar wat er aan ICT beschikbaar is. De architect van BetereZorg maakt nu een elementenconfiguratie-tekening van de ICT en hij ziet tot zijn verwondering dat de verschillende softwareapplicaties veel overlap hebben in de bedrijfsobjecten die ze behandelen.

Figuur 3, Overzicht van logische functionele elementen in een ICT-infrastructuur.

Ook ziet hij dat de bedrijfsobjecten dubbel in verschillende gegevensopslagoplossingen worden ondergebracht. Wanneer de onderneming nu een nieuwe administratie zou willen toevoegen aan de ICT, dan is wellicht de applicatie zo geïnstalleerd en in gebruik genomen, maar kost het nog heel wat verbouwingsinspanningen om softwarematig en informatiekundig correct de bedrijfsobjecten tussen de applicaties over en weer te laten behandelen.

Interessant is het om bij de elementen in beeld te brengen hoe uniek of hoe standaard een element is. Als een element een unieke combinatie van functies is, verdient het vaak aanbeveling om dit element op te delen in niet-unieke deelelementen. Dat maakt de implementatie in componenten en technische producten vele malen eenvoudiger en goedkoper.

Een volgende stap voor de architect van BetereZorg is het in beeld brengen van alle concepten en technologieën die worden gebruikt en hun end-of-life datum. En het in beeld brengen van welke concepten en technologieën in de onderneming al verlopen zijn. Hoe verder deze data weg liggen, des te toekomstvaster zijn de ICT-oplossingen die de onderneming heeft gekozen. Een architect hoort hier zelf proactief een bijdrage aan te leveren door het maken van een roadmap. Voor de ICT-infrastructuur dient er een technology roadmap beschikbaar te zijn en voor de informatievoorziening een information roadmap. Dit zijn twee onmisbare instrumenten bij het voorkomen van een Total Loss van ICT.

Figuur 4, Totaalconcept (de architectuur) van een ICT-infrastructuur.

In figuur 4 staat een fictief totaalconcept, of technische architectuur, van het voorbeeld bedrijf BetereZorg. De groene kronkelige ovalen zijn concepten die als zeer toekomstvast en duurzaam worden gezien door de architect van de onderneming, en niet gerelateerd zijn aan oplossingen van een leverancier. De oranje concepten doen de wenkbrauwen fronsen van de architect of het wel verstandig is om die concepten te verankeren, hetzij dat ze uitontwikkeld zijn, hetzij dat ze teveel aan een leverancier kleven.

De rode concepten zijn wat de architect betreft concepten die uit de ICT-architectuur gehaald dienen te worden, omdat ze bijvoorbeeld teveel gekoppeld zijn aan een enkel product of leverancier of zijn uitontwikkeld en vernieuwing gaan remmen. De technische producten die dit concept bevatten mogen wat de architect betreft nog wel gebruikt worden in de ICT-infrastructuur, alleen mogen niet de unieke kenmerken van het concept in het product worden gebruikt. In de Oracle en Microsoft databasesystemen mag bijvoorbeeld alleen maar van standaard SQL gebruik worden gemaakt wat betreft de architect van BetereZorg.

In figuur 4 is duidelijk dat wanneer een rood concept (een sterk leveranciersgerelateerd concept dat binnen drie jaar end of life is) is, dat het de ICT van de onderneming in haar innovatiecapaciteit gaat beperken.

Door dit in beeld te brengen en te sturen op proactieve vernieuwing, beheer en onderhoud, kan goed worden voorkomen dat de gehele ICT een Total Loss wordt.

Met het conceptenplaatje is de architect in staat toekomstige hoge kosten in beeld te brengen die zomaar kunnen volgen vanwege een afhankelijkheid naar een leverancier toe die daarvoor schaarse kennis moet inzetten.

In elke onderneming zijn er ICT-standaarden en ICT-richtlijnen. Die vormen goede vertrekpunten om te achterhalen welke ICT-concepten aanwezig zijn in de onderneming.

Met behulp van architectuurvisualisaties uit Dragon1 is in korte tijd al bruikbaar in beeld te brengen wat de realistische bouwkundige staat is van de ICT van een onderneming. Dit creëert voor het management een kans om te voorkomen dat de ICT Total Loss is. Als de noodzakelijke vernieuwingen voor de ICT op korte termijn zo drastisch zijn dat de bestaande ICT niet is aan te passen tegen verantwoorde kosten, is het slimmer om gelijk al te kiezen voor nieuwbouw. Daar wil je niet pas achter komen als de projecten al flink op stoom zijn.

Conclusie: Regie op ICT op basis van architectuurvisualisatie helpt Total Loss van ICT voorkomen!

Categorie:   
Auteur(s)
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.