DevOps tools, praktijken en principes kunnen het tempo van innovatie radicaal versnellen. Continuous Innovation komt binnen bereik. Het onderstaande plaatje is een voorbeeld van de weg die we dan afleggen. Persoonlijk zou ik daarin echter DevOps vervangen door Continuous Innovation als een hoger principe.

DevOps is namelijk ook te beschouwen als een middel en een consequentie van Agile / Scrum. Daarin zit immers het idee dat een Scrum team steeds meer verantwoordelijkheid neemt voor het product, uiteidelijk tot en met productie - de “expanding definition of done”. Voor Continuous Innovation is dan nog meer nodig. Voor mij, vanuit mijn specieke rol, is dit veel concreter en praktischer onderwerp. Het is ook een onderwerp waar engineers ( i.p.v. transformatie managers ) een verschil kunnen maken.

Continuous Innovation verbind ik bij voorkeur met de Open Source revolutie. Er zijn twee belangrijke punten die we nu kunnen maken m.b.t. ICT:

1. Het tempo van innovatie neemt alsmaar toe.
2. Open Source is de drijvende kracht achter deze versnelling.

Er is steeds meer open source software en deze software moet steeds sneller en vaker een weg vinden op de infrastructuur. Organisaties zijn zich soms onvoldoende bewust van deze revolutie is mijn ervaring. En maken bijna automatisch vaak nog de “leap of faith” en kiezen bijvoorbeeld voor een vendor lock-in met de selectie van leveranciers met bedrijfsmodellen waarbij een Open Source benadering compleet ontbreekt.

Zo vechten we echter een verloren strijd. Zo participeer ik bijvoorbeeld in de Chef community van rond 74.000 engineers . Daar is zelfs door de allergrootste bedrijven niet meer tegenop te boksen met een proprietary closed-source benadering.

Een ander aandachtspunt is bijvoorbeeld het automatiseren van application deployments waar veel aandachts voor is. De verwachtingen zijn hier echter te onrealistisch. Het wordt een leer-evaring die hopelijk zal leiden tot aantal inzichten:

1. Application deployments zijn maar klein onderdeel zijn van het op te lossen probleem. Het onderliggende platform verandert namelijk continue.
2. Dure closed-source niche producten die continuous deployment mogelijk moeten maken bieden geen oplossing voor het grotere / echte probleem. Het vraagstuk is dan denk ik of men via licenties en consultancy opdrachten de productontwikkeling wil financieren.

De uitdaging waar organisatie en bedrijven voor staan is de adoptie van cloud en virtualisatie technologieen en praktijken die Continuous Innovation mogelijk maken. Er is sprake van een paradigma verschuiving. In grotere, complexere organisaties drijft adoptie een wig. Noodzakelijkerwijs denk ik. Er ontstaan twee werelden.

Zelf heb ik ook mijn manier van werken getransformeerd. Deze weg is lang geleden begonnen Continuous Integration, eerst met CruiseControl, vervolgens Hudson, en daarna Jenkins. Er komen echter steeds meer hulpmiddelen en technogieën bij; het eco systeem waarmee ik typisch Scrum / Agile teams ondersteun groeit en verandert steeds sneller. Deze infrastructuur wordt ook steeds kritischer bij kort-cyclisch software ontwikkeling.

De enige manier om het tempo bij te benen is systematisch automatiseren met open source cloud en virtualisatie technologieen en praktijken. Dat doe ik op dit moment in een SAFe System Team. Vanuit dit team bedienen we echter ook nog de “oude” wereld met ad hoc automatiseren . Het werk verandert, de “applicatiebeheerder” van de toekomst is een programmeur. Engineers komen in beweging: van Dev richting Ops of andersom.

De twee werelden kunnen m.a.w. prima samenkomen in een System Team. I.t.t. de infrastructuur waar adoptie echter wel noodzakelijkerwijs een wig drijft want een compleet nieuw ontwerp met nieuwe regels is nodig. Maar vervolgens is het de fundamentele opdracht voor een System Team om de applicaties over te zetten van de oude naar de nieuw wereld; de stap te maken van ad hoc naar systematisch automatiseren en zo Continuous Innovation mogelijk te maken.