In de wereld van de it wordt er veel tijd en aandacht besteed aan het ontwikkelen en aan het handhaven van standaarden. Op zich is dat geen slechte gedachte: het bespaart tijd en geld om een ontwerp of implementatie nog een paar keer te kunnen herhalen. Bij een grote detacheerder waar ik een aantal jaren geleden werkte had men hiervoor een prachtige Engelse term: 'repeatable solution'.
Echter, zoals vaker het geval, is de praktijk een andere realiteit dan wat er in de hoofden zit van de accountmanagers en de it-managers. Je kan je dan vervolgens afvragen of de kosten en tijd die er gemoeid zijn met het vasthouden aan een (rigide) standaard, opwegen tegen de baten van standaardisatie; de beoogde lagere beheerlasten.
In een ideale situatie is er een it-infrastructuur, waarvan de componenten min of meer van hetzelfde bouwjaar zijn, de bouwblokken op elkaar zijn afgestemd, de software versies en configuraties zijn bijgewerkt en dat alle segmenten zijn ontworpen op basis van één architectuur concept. Je ziet dit soort plaatjes vaak terug in de brochures van fabrikanten en leveranciers: een serverfarm met alleen maar Windows-servers, een netwerk met alleen maar Cisco-componenten, een architectuur volgens het model dat door de fabrikant wordt gepropageerd. De kans dat het nieuwe product dan naadloos en met de spreekwoordelijke 'één druk op de knop' aansluit op de bestaande infrastructuur is dan hoog en is redelijk makkelijk te garanderen.
Maar hoe realistisch is een dergelijk strakke, homogene en gestandaardiseerde infrastructuur. Een organisatie zal ongeveer eens in de tien jaar een kans krijgen om zoiets op te zetten. Bijvoorbeeld bij de bouw van een nieuw datacentrum of het openen van een nieuwe vestiging.
De meeste ict-infrastructuren worden gekenmerkt door een grote verscheidenheid van segmenten en componenten die in de loop der jaren zijn ontstaan. Het is eigenlijk niet meer dan logisch dat ze organisch met de organisatie zijn meegegroeid. Tel daarbij op de dynamiek aan de aanbodzijde met betrekking tot overname van hardwarefabrikanten, het stoppen van produktlijnen, het wijzigen van subcomponenten et cetera. Met andere woorden elkeict- infrastructuur is op zichzelf een 'special' die bestaat uit een unieke combinatie van legacy- en moderne segmenten en de unieke wijze waarop ze zijn verweven.
Ik zie vaak om me heen dat it-beheerders deze realiteit niet kunnen en willen accepteren en dat er vervolgens veel tijd en energie wordt gestoken in standaardisatieslagen en het kost-wat-kost vasthouden aan te rigide requirements bij de introductie van nieuwe segmenten. Het resulteert in lange doorlooptijden van implementatietrajecten, de onnodige aanschaf van apparatuur en de zeer moeizame en tijdrovende migratie van oude koppelingen met externe partijen. Het kan tot niets anders leiden dan frustratie en onbehagen. Vergelijk het met de krampachtige wens om een moderne bungalow die is ingericht door Jean des Bouvrie, wit, strak en clean te houden, met een dynamisch gezin van vier kinderen, een hond en twee katten.
Een ander risico van het vasthouden aan de standaardisatie-illusie is dat documentatie en kennisborging niet de aandacht krijgt die het verdient. Er wordt te snel verwezen naar de beschrijving in 'de standaard' en de afwijkingen en specials op het koppelvlak tussen 'de standaard' en de rest van de infrastructuur worden te weinig belicht.
Laten we het omdraaien en 'de special' beschouwen als een gegeven en een uitgangspunt. Dit geeft gelijk al een alertheid en een noodzaak om alles goed vast te leggen en te documenteren, omdat we er niet vanuit kunnen gaan dat segment B hetzelfde is als segment A; Alles is anders 'by default'.
We kunnen nieuwe producten en technologieën snel en flexibel implementeren en verliezen geen tijd aan discussies over aanpassingen die benodigd zouden zijn als we willen voldoen aan onze rigide standaard (hetgeen tock ook weer specials zijn). Ook hoeven we geen tijd meer te steken in inhaalslagen om oude segmenten te laten voldoen aan de standaard en kunnen we die uren steken in implementaties die direct de business ondersteunen.
Natuurlijk hoeven we niet volledig afstand te doen van het streven naar standaardisatie. Echter laten we de standaardisatieregels louter op hoofdlijnen en functionaliteit vastleggen, in plaats op detailniveau en het voorschrift van een bepaald merk, model en type component.
Het is een allegaartje en het blijft een allegaartje. Laten we dit gewoon accepteren en er pragmatisch mee omgaan. Wij zijn trots op onze unieke organisatie en ons onderscheidend vermogen. Laten we dit ook zijn op onze it-structuur die zich aan onze unieke omgeving heeft aangepast. Wel netjes en gedetailleerd in kaart brengen en de documentatie voortdurend blijven onderhouden en bijwerken…
Het meest wenselijke niveau van standaardisatie hangt m.i. af van de context. Ik ben het er mee eens dat er regelmatig doorgeschoten wordt, en standaardisatie dan een blok aan het been wordt. Maar er zijn ook legio situaties waarin standaardisatie niet genoeg tot in detail is uitgewerkt en voorgeschreven, waardoor er in praktijk zaken mis blijven gaan. Bijv. als 2 verschillende leveranciers ‘de standaard volgen’, maar dit niet tot een goed werkende oplossing leidt.
Een variant die nuttig kan zijn is de en-en aanpak: een standaard die wordt gedetailleerd, vergezeld van een lichtgewicht versie voor waar dat voldoende is. Die lichtgewicht versie wordt helaas vaak ‘vergeten’. Bijv. met het argument dat immers alles mogelijk is met de uitgewerkte standaard. Dat is jammer voor al die situaties waarin een lichtgewicht versie acceptabel is, en er in korte tijd goed (genoeg) werkende oplossingen mee gemaakt zouden kunnen worden. Heb zelf vorig jaar een aanzet hiertoe gedaan voor de binnen de overheid gebruikte StUF standaard, maar poging daartoe is helaas gestrand.
Oef, persoonlijk vind ik dit niet zo’n goed artikel van je.
Wanneer een organisatie ervoor gekozen heeft om onder architectuur te werken, dan is je artikel een nagel aan de netwerkinfra doodskist.
Vanuit een managementview bezien vind ik het ook wat minder geslaagd moet ik zeggen.
Ik accepteer het in ieder geval niet van mijn medewerkers om op deze wijze te implementeren.