De DevOps beweging lijkt onomkeerbaar te zijn en doet steeds vaker zijn intrede in het bedrijfsleven en de overheid. De toenemende vraag naar DevOps-engineers en de populariteit van DevOps-events onderstreept deze beweging. Maar wat betekent dit voor it en enterprise architectuur ?
Het is nog niet zo lang geleden dat organisaties sceptisch waren over cloud. Inmiddels zijn organisaties vertrouwd geraakt met cloud, software as a service en platform as a service en het succesvol laten werken van DevOps is daarbij een logische stap. Het is overigens wel een ingrijpende stap en kan gezien worden als een reorganisatie en culturele transformatie.
Onlangs heb ik zelf de ‘DevOps Days’ in Amsterdam bezocht en heb ik zelf kunnen aanschouwen welke enorme voordelen DevOps biedt. Daarnaast is de DevOps-community enorm aan het groeien en draagt deze actief bij aan het ontwikkelen en het delen van kennis en best practices. In dit artikel deel ik mijn inzichten over de mogelijkheden van DevOps.
Beter, sneller, goedkoper en veiliger
De bijdrage van de opensource community en de adoptie van cloud versnellen het DevOps gedachtengoed en zorgen voor een steeds bredere acceptatie binnen it-afdelingen van de profit en non-profit sector. Als je de mogelijkheden van bijvoorbeeld Elastic Stack, Chef, Puppet, Amazon webservices en Docker (om maar wat te noemen) aanschouwt, krijg je snel de indruk dat alles beter, sneller, goedkoper en veiliger wordt. Tot groot genoegen van bestuurders die ervoor moeten zorgen dat hun organisatie snel en flexibel in kan spelen op steeds sneller veranderende eisen vanuit de markt.
Technologie is echter niet de enige driver achter de DevOps beweging. Aangezien het succes van de tooling staat of valt met de mensen die het gebruiken, is de menselijke factor (en de ontwikkeling daarvan) enorm belangrijk. Randvoorwaardelijk voor continuous delivery is continue planning, continue integratie, continue deployment, continue testing én continue releasing en monitoring. Een glimp van het werkveld van de it-professional van de toekomst (en de toekomst is morgen!).
De architectuur functie
De grote vraag die ik me echter stel is, wat de impact van de DevOps beweging op (enterprise) architectuur is. Heldere governance structuren, afstemming met bedrijfsdoelen en een toekomstbestendige (doel)architectuur klinken logisch maar blijken in de praktijk een enorme uitdaging. Vanuit de regieorganisatie dan wel de architectuurfunctie binnen organisaties wordt er alles aan gedaan om werken onder architectuur gemeengoed te maken en alle bloedgroepen binnen de IT afdeling hierin mee te krijgen. Werken onder architectuur wordt gezien als randvoorwaardelijk bij de totstandkoming van een robuust en toekomstbestendig systeemlandschap en de rationalisatie en standaardisatie van het applicatie landschap. Is DevOps hierbij een versnellende factor of is er een ogenschijnlijke tegenstelling? Organisaties die geconfronteerd worden met digitale transformatie hebben behoefte aan een meer agile benadering van enterprise architectuur
DevOps is moeilijk te definiëren. In mijn optiek is DevOps een benadering van softwareontwikkeling die ervoor zorgt dat de ’time to market’ van applicaties en services korter wordt en meer ‘Agile’. Het cyclische proces van softwareontwikkeling wordt efficiënter door een betere samenwerking met operations, betere integratie en een hoge mate van automatisering. Een architect in een DevOps-omgeving zal dan ook diepgaande kennis moeten hebben van automation, container management, webservices, PaaS-concepten (platform as a service), configuratie management en applicatie ontwikkeling.
Sleutel tot succes
De visie van Gene Kim, een DevOps visionair is interessant. Tijdens zijn indrukwekkende carrière en zoektocht naar high performing organisations heeft hij ondervonden dat de samenwerking tussen operations, ontwikkeling en security (en het ontbreken van grenzen tussen deze afdelingen) de sleutel tot succes is.
Dit is ook precies de kern van het DevOps gedachtengoed en Gene Kim kan dan ook zeker gezien worden als een van de grondleggers van DevOps zoals wij dit vandaag de dag kennen. Hij is voorstander van het samenbrengen van cloud, mobile, Agile-softwareontwikkeling en DevOps om snelle productontwikkeling te faciliteren in multidisciplinaire teams die zelf verantwoordelijk zijn voor continuous delivery.
Architecten worden evangelisten
Vandaag de dag is technologie het hart van de moderne onderneming. Om aan de eisen van de digitale business tegemoet te komen wordt van architecten verwacht visie en strategieën te kunnen ontwikkelen binnen onder andere het applicatie, informatie en security domein. Ten overvloede; deze domeinen zijn grensoverschrijdend en zullen derhalve in samenhang moeten worden gecoördineerd.
De behoefte aan high-level sturing en coördinatie van it vanuit bedrijfsdoelstellingen (enterprise architectuur) zal altijd blijven bestaan. De invulling van architectuur en het gebruik van referentie architecturen veranderd wel degelijk door de samensmelting van ontwikkeling en beheer. Is er behoefte aan een zogenaamde DevOps referentie architectuur en hoe zou deze eruit moeten zien? Een belangrijk aspect lijkt het sturen op gewenst gedrag, waarbij architectuur ervoor moet zorgen dat het DevOps-team de juiste dingen doet, zonder te veel ingeperkt te worden (vertragen) in wat ze bouwen. Architecten worden evangelisten.
(Enterprise) Architectuur heeft een net zo grote erosie ondergaan als Consultancy. Als je het zo bekijkt zijn het lege containers en dus nauwelijks de moeite waard om te adresseren. Ik zie spreek de laatste tijd veel organisaties over (Enterprise) Architectuur en kan mij niet aan de indruk onttrekken dat iedereen er maar het zijne van maakt. Ik probeer het altijd als volgt te visualiseren: aan de ene kant van het spectrum de super techneut die compleet de binding met de werkelijkheid (en zeker de business van de eigen organisatie) is kwijtgeraakt. Aan de andere kant de glazenhuis enterprise architect, die nog steeds bezig is met architectuurplaat 0.0.1 en binnen de organisatie is deze functionaris compleet onzichtbaar. Beiden zijn uitersten waar tussen hele waardevolle zaken worden geproduceerd en gecommuniceerd.
En ik snap ook wel waar het vandaan komt, men associeert pure architectuur met ICT. De vraag is of dat wel zo is. Natuurlijk heeft ICT een enorme impact op organisaties en soms zou je denken dat alles om ICT draait. Bij de grote automobielbouwers gaat het toch echt om het bouwen van auto’s. Dat daar veel ICT bij komt kijken is een feit, maar er komt ook heel veel materiaalkennis bij kijken, compliancy (ga even met Volkswagen praten), usability (rijdt de auto wel lekker), security (is het apparaat wel veilig, zie alle terugroepacties), etc… Jaja, ik weet de zelfrijdende auto is toch puur ICT. Klopt, maar de grootste discussie gaat over aansprakelijkheid. Zie hier veel activiteiten binnen een organisatie hebben te maken met ICT (of het nou onderdeel is van het primaire product of ondersteunend), maar zaken als security, veiligheid, usability zijn ook relevant, maar nog heel dicht tegen ICT aan. Maar juridisch, imago en materiaalkennis zijn toch echt andere domeinen. Dan heb ik het nog niet eens over het eigen personeel en de financiën gehad.
Ik vind het goed dat in het kader van DevOps eindelijke de infrastructuurgasten met die ontwikkelaars om een tafel gaan zitten. Natuurlijk laten waar daar vooral een berg producten tegenaan smijten. We blijven ICT-ers. Maar noem mij een DevOps specialist die het overzicht heeft bij het complete beeld van het product of dienst van een organisatie. Dus die ook de net genoemde gebieden (die elk een vakgebied op zich zijn, met net zoveel complexiteit en grootte als ICT) kan duiden en in alle bedrijfsprocessen.
De huidige architectuurmethodieken (Togaf, Dya, etc,,,) hebben maar bar weinig handvatten om daarmee om te gaan: zij hebben een groot ICT gehalte. De enige methodiek die ik ken die dit alles samenbrengt is GEA (General Enterprise Architecting). Daarin wordt tenminste een poging gemaakt om alle facetten van een dienst of product (of keten) of welk bedrijfsvraagstuk dan ook in relatie met elkaar gebracht. En nee, dat kost geen jaren, zoiets bouw je op. Net zoals ICT-ers dat doen met al hun software in al die jaren. Hoe noemden we dat ook al weer: legacy?
Ik denk dat zowel die supertechneuten als die glazenhuis architecten wat meer naar het midden moeten bewegen en daadwerkelijke enterprise architectuur gaan bedrijven voordat ze zich weer (vaak door compleet idiote tijdsdruk, vaak nergens op gebaseerd, maar in hoofden van hongerige managers) storten in zinloze stukken ICT die niemand gaat gebruiken. Of vooral “disruptive” willen zijn, want dat trekt veel bekijks. De wereld snakt naar zingeving, en het zou een verademing zijn als een organisatie zijn primaire product of dienst niet verkwanselt. Natuurlijk rekening houdend met de eigen visie, missie en doelstellingen en de context waarin zij acteren. Je moet de boot natuurlijk niet missen. Voorbeeld van een bedrijf dat zichzelf redelijk goed heeft heruitgevonden: Philips. Bedrijf dat compleet de boot heeft gemist: Kodak. Maar als Shell morgen – ingegeven door een of andere agile, devops, cloud, bigdata, disruptive zweefverhaal – stofzuigers gaat produceren en uit de olie en gas business verlaat, vraag ik mij welk bestaansrecht Shell dan überhaupt ooit heeft gehad en waar het DNA (verankerd in de architectuurprincipes) is gebleven?
Het volk wil 5 tools en 2 ontwikkelmethoden.
En je kon er 12 containers mee vullen.
Architecten worden evangelisten.
“Beter, sneller, goedkoper en veiliger”. Zeg dat tegen een gefrusteerde directeur en die reageert even enthousiast als een jochie dat net 72 maagden was beloofd. Beiden hebben weinig benul. Hoeft ook niet. De cultuur is er klaar voor en de buren hebben het ook. Voor veel mensen genoeg reden om ook zo’n leuk stenen boeda beeldje in de vensterbank te zetten. Staat leuk en misschien helpt het. Waarom dan geen DevOps ?
Atilla doet er nog een schepje bovenop. “De wereld snakt naar zingeving”.
Tis ook allemaal niet meer zo duidelijk als vroeger.
De kerken lopen leeg en de social media vol.
Multidiplinair maar wel bimodal. Gurus wegen zijn ondoorgrondelijk.
Architectuur die overal rekening mee houdt. Geloof jij het ?
@ Atilla, je noemt TOGAF, Dya en GEA. Hoe zit het met Enterprise Engineering / DEMO? Naar mijn idee zou enterprise engineering uitstekend gebruikt kunnen worden om de brug te slaan van organisatie ontwerp naar Enterprise / IT architectuur.
Bedankt voor de interessante reacties en toevoegingen. DevOps zorgt in mijn ogen primair voor een betere samenwerking in multidisciplinaire teams, betere integratie en een hoge mate van automation en heeft zonder twijfel impact op de manier waarop sturing wordt gegeven aan bedrijfsdoelen en strategie. Dit maakt het een interessant gespreksonderwerp waarbij verschillende perspectieven op architectuur (IT architectuur en Enterprise Architectuur) belicht kunnen worden.
Dat de IT architectuur vooral zit in het opbouwen van het platform (de fysieke wereld) en de wijze waarop het platform opgezet wordt uiteindelijk bepaalt welke mogelijkheden en beperkingen er zijn in het deployen van de virtuele systemen middels alle automation tools is een mening die ik zeker deel. IT is echter slechts een deelcomponent van Enterprise architectuur dat als doel heeft om op een coherente en consistente wijze sturing te geven aan de ontwikkeling van de complete organisatie in de gewenste richting. Het opstellen van principes, uitgangspunten en richtlijnen en het gebruik van standaarden en raamwerken geeft hierbij praktische handvatten. Vanzelfsprekend zijn er persoonlijke voorkeuren en situationele aspecten die een rol spelen bij de keuze voor een bepaalde methodiek. Dit blijkt ook uit de discussie waarbij o.a. Togaf, Dya, GEA en Enterprise Engineering / DEMO wordt genoemd. Het klopt dat veel methodieken gestoeld zijn op een (te) groot ICT gehalte wat niet bevorderlijk is voor Business IT alignement. Er is echter wel duidelijk een kentering zichtbaar. Als voorbeeld noem ik de nieuwe NORA 3.0 norm (Nederlandse Overheid ReferentieArchitectuur) die volgt op de 2.0 versie uit 2007 en waarbij duidelijk meer aandacht wordt besteed aan het verbinden van organisatie ontwerp en Enterprise / IT architectuur. Zo is de nieuwe norm meer dan voorheen gericht op praktische ondersteuning van ‘het werken onder architectuur’ door een brede doelgroep van bestuurders, projectleiders èn architecten. Waar de norm voorheen nog uitsluitend was gericht op architecten stelt de nieuwe norm een brede groep van gebruikers in staat om, ieder op het eigen niveau, te sturen op het vermogen van hun organisatie of project om samen te werken met andere overheidsorganisaties en goede diensten te verlenen. Het gebruik van NORA in transformatieprocessen (bijvoorbeeld DevOps) van overheidsorganisaties, op strategisch en tactisch niveau wordt toegelicht.
Is een bepaalde standaard heilig? Wat mij betreft helemaal niet. In een bepaalde situatie kijk je welke standaard (of gecombineerde standaarden) het beste werkt en soms (vaak) is het ook helemaal geen vrije keuze. Zolang er maar gestuurd kan worden op gewenst gedrag en het “architectuur evangelie” positief wordt uitgedragen.
Een boeiende discussie waarin EA in ieder geval niet ten grave wordt gedragen
(onder het motto: Enterprise Architecture is dead! Long live Business Design).
Mijns inziens moeten we niet naar een wendbare (benadering van) architectuur, maar naar een architectuur die wendbaarheid mogelijk maakt.
En daarmee worden enterprise architecten eerder filosofen dan evangelisten.
Architecten hebben het gat gevuld dat nodig was om het verleden ne het heden met elkaar in verbinding te brengen in lijn met de organisatie en bedrijfsfilosofie. In veel gevallen heeft dit wel geleidt tot een betere huishouding in het IT landschap, maar de mogelijkheden om te veranderen werden en worden ernstig beperkt. De wendbaarheid van IT is door Architecten beperkt. Maar de business drive richting de digitale organisatie vergt juist wendbaarheid, directe aanpassing aan de markt, direct inspelen op nieuwe behoeften, actualiteit of sociale media…En dan niet eerst langs een PSA, architectuur board, changeboard, stuurgroep en andere loketten.
Devops sluit perfect aan op een wendbare competitieve organisatie met een hoog IT gehalte.
De architect zal een ander rol krijgen waarbij hij/zij meer de verbindende rol zal krijgen tussen verschillende devops teams en/of de integratie met andere businessprocessen om de digitale transformatie in organisaties vorm te geven. Maar dan meer met een organisatie/business bril, dan met een technische bril. De techniek zit achter de wolken…
Mooie discussie mensen.
Hoe zorg je ervoor dat de Business de gewenste snelheid kan maken en de IT stabiliteit gehandhaafd blijft? DevOps is mijn inziens een mooi voorbeeld waarmee (zoals Maarten beschrijft) de samenwerking tussen Operations, Ontwikkeling, Security en wat mij betreft ook de Business verbeterd. De Enterprice Architectuur zorgt voor richtinggevende architectuur principes waarop de DevOps teams acteren en de Domein en Solution architecten een steeds prominentere rol binnen het DevOps team krijgen.
Samenwerken, snelheid maken en stabiliteit aan de onderkant van de IT stack handhaven zijn wat mij betreft de sleutelwoorden in een steeds onrustiger wordende (mobile) markt waarin klanten bij minder goed functionerende apps makkelijk overstappen.
Mooi artikel Daan en erg relevant op dit moment.
Uit je artikel:
“Een architect in een DevOps-omgeving zal dan ook diepgaande kennis moeten hebben van automation, container management, webservices, PaaS-concepten (platform as a service), configuratie management en applicatie ontwikkeling.”
Eens, en dat is toch ook niet anders als je naar de architecten van fysieke bouwwerken kijkt? Die moeten ook steeds bij blijven bij de nieuwe technieken op het gebied van duurzaamheid, snelheid & veiligheid.
De verschuiving die ik zie is dat de (Enterprise) Architect steeds meer de eigenschappen van een engineer (in de sense zoals Google en dergelijke deze toepast) krijgt en de goede engineers steeds meer groeien naar architect. Alleen is het fundament waarop je alles bouwt en in hoge mate automatiseert wat meer vloeibaar geworden. De kaders verschuiven worden abstracter en er ontstaan subtiele afhankelijkheden. Soms word een DevOps omgeving zo complex dat het een risico word. Iets wat je bijvoorbeeld in de blockchain architecturen ziet. Alsof je de structuur van een gebouw moet aanpassen tijdens het bouwen. Hoe test je nog je risico’s aangezien het vlak tussen ontwikkelen / testen en productie vervaagd in een omgeving die steeds meer “hyper”-connected is?
Weet je nog dat een tijdje terug een ontwikkelaar zijn code terugtrok naar een verschil van inzicht? Dit was een spaak in de DevOps wielen en een fundamentele zwakheid in de DevOps architectuur. Nu zou dat probleem niet meteen doorgesijpeld zijn naar de productie omgeving, maar het gaf wel aan dat je met al die lagen op lagen heel weinig nodig had om het er onderuit te trekken en dit keer ging het om een heel simpel iets.
DevOps is ook bouwen onder architectuur. Alleen met een twist 🙂
Wat een leuke en goede reacties. Ben het ook zeker eens met de stelling dat er fundamentele zwakheden zitten in een zogenaamde DevOps architectuur. Er zijn duidelijk twee kampen. Of je bent van mening dat DevOps (nog) te weinig waarde voor de business realiseert en meer problemen oplevert dan het oplost of je bent van mening dat het een enorme verrijking is voor de organisatie.
Ik behoor zelf tot het tweede kamp, met name vanuit de overtuiging dat DevOps een driver voor innovatie is. Agile Scrum heeft ook zijn opstartproblemen gekend en kreeg initieel veel weerstand. Het merendeel van de software ontwikkelaars moet er inmiddels echter niet meer aan denken om terug te keren naar een waterval methodiek. Ook de architectuur heeft zich prima aan deze ontwikkeling aangepast en zo zal het m.i. ook met DevOps gaan. Of de beloftes zich ook uit gaan betalen zullen we de komende jaren ervaren. Ik ben in ieder geval erg benieuwd naar jullie ervaringen, met name vanuit architectuur oogpunt.
Kennelijk is die DevOps visionair Gene Kim ook een van de schrijvers van Tripwire geweest destijds. Toch klein wereldje soms. 🙂