Indien al in de ontwerpfase aandacht zou worden geschonken aan de eindfase en verwijdering van een it-infrastructuursegment, dan zal dat in de toekomst een snelle uitfasering makkelijker maken. Hierdoor kunnen vervolgens kosten worden bespaard op stroom, koeling, vloerruimte, racks, switches, patchpanelen, wan-links, et cetera.
Een it-infrastructuur is voortdurend in beweging. De projecten en wijzigingen volgen elkaar in hoog tempo op. Meestal is er sprake van groei. Indien dit gelijk op gaat met de groei van de organisatie is er niets aan de hand. Maar ook in andere gevallen blijft de infrastructuur groeien. Er komt alleen maar bij; er gaat niks weg. Het opruimen van spullen is lastig en het is het 'stiefkindje' in het operationele proces.
Er zijn twee belangrijke redenen die het moeilijk maken om spullen weg te halen. Om te beginnen is op het moment dat de hardware moet worden opgeruimd, de documentatie zoek of is hopeloos achterhaald en verouderd. Tussentijdse wijzigingen zijn niet meer verwerkt en de contactpersonen die met naam en gegevens vermeld staan zijn al lang uit de organisatie vertrokken. Een andere reden is dat een segment in de loop van de jaren is gebruikt voor meer dan één functionaliteit, dienst of aangesloten partij. De apparatuur is dan teveel verweven in het geheel van de infrastructuur en het verwijderen ervan heeft een impact op een te groot deel van de business. Om één component weg te halen moet er worden afgestemd met vele interne maar ook externe partijen die er gebruik van maken. In veel gevallen is het al een hele opgave om zowieso de impact van een verwijdering en de betrokken partijen te inventariseren en in kaart te brengen.
Het bijhouden van documentatie moet in het operationele beheerproces worden geborgd. Dat is kwestie van discipline en handhaving. Wat betreft het voorkomen van te veel verwevenheid en complexiteit kan al veel eerder in het proces, de ontwerp en bouwfase, aandacht worden besteed aan de 'verwijderbaarheid' of 'uitfaseerbaarheid' van je technische oplossing.
De ontwerper dient bij het maken van keuzes voor een hardware-implementatie de volgende vraag in het achterhoofd te hebben: 'kan deze dienst apart fysiek worden verwijderd zonder dat een andere dienst daar last van heeft?' In veel gevallen kom je dan uit op afzonderlijke hardware per dienst of verkeersstroom: aparte routers per wan-link, aparte servers, aparte bekabeling, eigen uplinks naar de backbone en het bij elkaar plaatsen van hardware in een rack. In de software-ontwikkeling is men al lang gewend aan het modulair ontwerpen. Een zelfde werkwijze zou ook gemeengoed moeten zijn in de infrastructuur architectuur. Niet alleen vanuit het oogpunt van beschikbaarheid en de redundante uitvoering van componenten maar ook vanuit het oogpunt van het tegengaan van verwevenheid en complexiteitsreductie.
Deze keuzerichting staat haaks op de huidige marktontwikkelingen van service-integratie en virtualisatie. Ook zal het veel overtuigingskracht vergen om het, initieel duurdere, boodschappenlijstje van hardware er doorheen te krijgen. Echter als het op het einde van de levenscyclus eenvoudiger is om apparaten uit te kunnen zetten en te verwijderen, dan zal dat ook eerder gebeuren. Dit zal dan een toekomstige investering met betrekking tot uitbreiding van de serverruimte, koeling, stroomvoorziening, racks en switches overbodig kunnen maken of op zijn minst kunnen uitstellen.
ik zie een parallel met werknemers binnen een groeiende organistatie. Op een gegeven moment weet niemand meer wat ze precies doen. Misschien wel niets, maar als je er eentje verwijdert heeft dat misschien wel flinke impact op de organisatie..
Bedrijven lossen dat op door gewoon de hele afdeling te outsourcen 😉
Dream on.
Dit wordt al jaren door de IT-afdelingen verteld, maar zolang het niet zichtbaar is voor de business zal het opruimen van de “oude troep” niet gebeuren. Vaak heeft de business een korte termijn visie, waarbij alleen naar de kosten van het personeel gekeken wordt. De lange termijn visie van de IT-afdeling wordt dan niet gevolgd.
Er zijn zat voorbeelden in het bedrijfsleven te vinden waarbij verouderde programmatuur nog draait, zonder dat deze programmatuur echt gebruikt wordt. De business betaald vaak liever voor vervuiling van systemen dan voor het schonen van systemen. En als we eerlijk zijn is dit een eigenschap van de mens. Als mens verzamelen we spullen en we hebben als mens moeite om deze spullen weer weg te doen.
Ik kan me absoluut niet vinden in deze stelling. Alsof je bij het bouwen van een huis er al vanuit gaat dat de CV ketel vervangen gaat worden door stadsverwarming.
Je bouwt hetgeen gevraagd is, tegen een zo gunstig mogelijke prijs. Als de aannemer tegen me zegt: ik kan uw huis wel bouwen, maar ik ben wel €50000 duurder dan de concurrent. Daarentegen bent u dan wel voorbereid om uw verwarming uit te besteden aan de stadsverwarming, mocht die nog ooit komen.
3 keer raden wat mijn reactie zal zijn…….
Goed artikel. Dit probleem kreeg al te weinig aandacht toen de dropveters van de gesloten legacy systemen aangelegd werden. De situatie is niet veel beter geworden. Een netwerk is net zo goed een systeem met een livecycle als een softwaresysteem.
De opdrachtgever moet daarvan op de hoogte gebracht worden. De opdrachtgever heeft echter het recht op ongelijk. Dus de nieuwe manager krijgt meestal een lijk in de kast. En misschien is dat net zo’n lijk als hij elders achtergelaten heeft.
Bij een geregistreerd partnerschap maak je toch ook afspraken die bij een scheiding of overlijden van kracht worden?
Ooit had ik een droom waarbij in de software metertjes zaten waarbij je bij uitlezen kon zien wat niet (meer) gebruikt wordt en daarna op een knopje kon drukken om dit stuk software weg te gooien. Het kost zoveel om te voldoen bij wijzigingen aan “de rest moet blijven draaien zoals het altijd deed”.
De gedachte vertoont een grote overeenkomst met de nieuwere software ontwikkelingsmethoden. In het bijzonder met de layering en isolation aspecten, die eenvoudige refactoring en in/uitfasering van elementen mogelijk maken.
Zoals reeds aangegeven blijft kennisborging(.nl) essentieel. Door deze technieken te gebruiken kan ook documentatie beter worden onderhouden, zodat er bij de uitfasering van elementen minder (geen?) vragen overblijven.