Dit proces begint bij een ontwikkelaar met zijn IDE (integrated development environment) en lokale ontwikkeldatabase. Dit is een omgeving waar hij zijn code ontwikkelt. Meestal doet hij dit niet alleen maar in teamvorm. Als je met een team ontwikkelaars te maken hebt, neemt de complexiteit toe en moet je zaken gaan regelen als het mergen van verschillende stukken code, versiebeheer en om er zorg voor te dragen dat bij in productiename alles goed gaat, moet je configuratiebeheer inregelen. Vervolgens moet de build of release in productie genomen worden. Zo'n release bestaat uit programmacode, databasescripts maar bijvoorbeeld ook scheduler script, stamgegevens, web service authorisatie of code voor een middleware platform voor integraties. Alleen al zorgen dat al die componenten op het juiste moment op de juiste plek komen, is een kunde. En dan heb ik het nog niet eens over het feit dat tussen ontwikkeling en producite vaak nog meerdere omgevingen zitten.
Op productieniveau moeten ook verschillende taken worden uitgevoerd die essentieel zijn voor het beheer. Er moeten schedulers draaien, applicaties moeten voorzien worden van logging en auditing. Nog belangrijker is het beheer van availability en als deel daarvan performance management. Het monitoren van systemen en applicaties is cruciaal geworden met de huidige n-tier omgevingen, omdat zonder deze het zoeken naar problemen gelijk is aan het zoeken van een speld in een hooiberg.
Alles bij elkaar heb ik nu al minimaal zeven functies genoemd waar vaak aparte tools of suites voor gebruikt worden om deze taken te vergemakkelijken. Deze tools zijn nodig om complexiteit uit handmatige processen te halen. Het toverwoord (of eigenlijk toverwoorden) is het reduceren van complexiteit, maar hoe komt het dan dat organisaties al snel met maandelijkse of halfjaarlijkse releases werken?
Blijkbaar is er nog genoeg complexiteit over om dit proces moeilijk te maken. De hoofdreden voor dit is dat de gebruikte methoden en tools vaak niet aansluiten op de behoefte om de business snel op te leveren. Bijvoorbeeld wanneer een trage javamethode ontdekt wordt in een applicatie door een performance management-oplossing, dan weet je nog niet waar die methode geprogrammeerd is in de code. Als je de code dan aan wil passen weet je vaak niet wat voor gevolgen dit gaat hebben op de rest van de applicatie. Het kan bijvoorbeeld voorkomen dat de ene actie het razendsnel maakt wordt terwijl je een andere actie vertraagd. Dit komt doordat we net geen tool hadden voor impactanalyse. Organisaties zijn vaak huiverig dit soort aanpassingen te maken omdat het terugdraaien hiervan niet altijd even makkelijk is. Vooral als we met complexe n-tier omgevingen te maken hebben.
De oplossing is de menseljke schakel zo veel mogelijk uit het operationeel beheerproces te halen. Dit betekent het verregaand automatiseren en hufterproof maken van de beheersprocessen. Het belangrijkste hierbij is integratie en intelligientie. Onze beheersoplossingen moeten intelligenter zijn en zoveel mogelijk zelf afhandelen, maar nog belangrijker is dat ze zoveel mogelijk handmatige interventie voorkomen en over de gehele keten ingevoerd worden.
Reacties
Helemaal mee eens, al vraag ik me af wie je met de hufter bedoelt.
De losse tools voor de verschillende functies zijn volgens mij onderdeel van het probleem. Ik wil nog iets verder gaan. In plaats van een geintegreerde set hulpmiddelen moeten de componenten intelligenter worden en uitgebreid met functies voor beheer. We weten al heel lang hoe we procesmatig willen ontwikkelen. Een "ontwikkelstraat" is vooral gericht op het proces van ontwikkelen en testen en spreekt de interfaces van de componenten aan. Hiermee kunnen we in een evolutionair traject terecht komen en voortbouwen op eerdere ervaringen in plaats van op het revolutionaire pad te blijven waarmee we steeds opnieuw beginnen.