Bij een architect denken we al snel aan iemand die de tekeningen maakt. Als het project eenmaal begonnen is, loopt de architect misschien nog rond op de bouwplaats, maar alleen om te controleren of het ontwerp goed wordt uitgevoerd. In organisaties die in een cloudmigratie zitten, werkt dit niet. Hier moet de Cloud Architect actief betrokken blijven bij initiatieven en projecten, zeker als gewerkt wordt met multidisciplinaire DevOps teams. Dankzij deze actieve rol van de Cloud Architect actualiseren standaarden, patronen en bouwblokken voortdurend en wordt architectuur zelf ook agile. Waarom dat nodig is, bespreek ik in dit artikel.
100% praktijk
De stellingen in dit artikel zijn geen louter theoretisch idee, maar zijn gestoeld op mijn persoonlijke, jarenlange ervaring als participerend Cloud architect bij klanten uit de dienstensector, de financiële sector en uit de industrie. Zo ben ik momenteel betrokken bij de cloudmigratie van Alfen N.V., een innovatief en snel groeiend bedrijf in de energiesector. Hier draag ik bij aan onder andere cloud solution development, pipeline automation en het ontwerpen en bouwen van het cloudplatform. Daarnaast ben ik betrokken bij het opstellen van solution en referentie architecturen, enterprise architectuur alignment en ondersteuning van operations en security operations. Door dit brede pallet aan taken fungeer ik als verbindingsofficier tussen alle partijen en kunnen we grote stappen zetten in cloud native development, in automatisering en in het gebruik van geavanceerde technieken.
Dat was de noot vooraf, nu duiken we de materie in!
De klassieke rol van de Cloud Architect
Cloud computing is in een digitale transformatie onmisbaar. Om maar een paar voordelen te noemen: er is selfservice voor alles, veel kan geautomatiseerd worden, de meest moderne technieken zijn beschikbaar, opschalen is geen probleem én de beveiligingsdiensten en beschikbaarheid zijn van zeer hoog niveau. Dat klinkt mooi (en dat is het ook), maar de nieuwe situatie in de Cloud moet je als organisatie wel zelf ontwerpen. Hier komt de Cloud Architect direct om de hoek kijken. Hij of zij is betrokken bij het initiële ontwerp en de implementatie van het cloudplatform- de “landing zones”- en het klaar voor gebruik maken van Cloud voor DevOps teams. Deze landing zones baseert de Cloud Architect op geldende en op nieuwe standaarden en richtlijnen en daarnaast ontwikkelt hij of zij blauwdrukken van diensten-bouwblokken, waarmee de innovatiesnelheid verhoogt.
Van ontwerper naar deelnemer
Tot zover de ideale wereld. De praktijk is weerbarstiger zoals iedereen weet. Enerzijds zijn er initiatieven die gaan vliegen voordat voor iedereen duidelijk is welke standaarden en patronen ontwikkeld zijn, anderzijds zijn er medewerkers die nog niet vertrouwd zijn met de nieuwe concepten, technieken en mogelijkheden en die daarom afwachten wat er gaat gebeuren.
Wat helpt om alle betrokkenen op één lijn te krijgen is een actieve participatie van de Cloud Architect bij concrete projecten en initiatieven. Geen theoretische architectuur op afstand dus, maar iemand die praktisch meedenkt en meewerkt aan projecten en initiatieven met DevOps teams, business-vertegenwoordigers en andere stakeholders. Die actieve houding is ook aan te raden voor het Cloud Center of Expertise (CCoE): ook zij moeten niet wachten tot iemand aan hun deur klopt, ze moeten zorgen dat ze bij lopende en komende zaken betrokken raken.
De vele voordelen van de participerende Cloud Architect
Doordat de Cloud Architect meedenkt en meewerkt, worden de ontwikkelde standaarden en patronen, de do’s en don’ts direct in praktijk gebracht en wordt duidelijk wat daaraan nog ontbreekt en ook wat niet werkt. Op deze manier wordt de Cloud Architect bovendien ook zelf in aanraking gebracht met nieuwe concepten, technieken en methoden. Hierdoor blijft hij of zij goed op de hoogte en ontstaat er een dynamische en agile architectuur die je zonder participerende Cloud Architect nooit zou krijgen. Deze participatie zorgt er daarnaast voor dat vastgestelde standaarden en bouwblokken niet verstoffen maar actueel blijven. Als kers op de taart kan de participerend architect fricties wegnemen terwijl compliance normen en aanvaarde best-practices gehandhaafd blijven.
Verbindende factor tussen Dev en Ops
Actieve participatie van de agile Cloud Architect betekent niet dat deze persoon alleen samenwerkt met gevestigde DevOps teams, maar ook engineering- en beheerrollen betrekt om de Ops-kant in DevOps in te vullen, want die is regelmatig onderontwikkeld. Engineering en beheer is immers een vak dat je er niet even bijdoet als developer. Belangrijk hierbij is het inregelen en borgen van de beveiliging, beschikbaarheid en prestaties van IT-oplossingen. Was het boven water krijgen en realiseren van niet-functionele eisen altijd de tweede natuur van de architect, nu komt dit de DevOps teams toe en de Cloud Architect helpt deze teams dit tot hun tweede natuur te maken. Zo kunnen DevOps teams ook meer en meer verantwoordelijkheden worden toevertrouwd.
De rol van externe leveranciers, zoals een netwerkpartij of een softwareontwikkelpartij die betrokken zijn bij het voortbrengen van applicaties en diensten, verandert mee met bovengeschetste beweging. Ook zij moeten bereid zijn mee te draaien in de multidisciplinaire teams en dat is gelukkig steeds meer het geval. Voor een digitaal transformerende organisatie wordt het duidelijk dat leveranciers die deze samenwerking en openheid niet kunnen opbrengen en blijven hangen in de oude “schiet maar een ticket in” patronen geen plaats meer is.
De Cloud Architect is nooit klaar- en zo moet het ook
De gedachte kan ontstaan dat als de DevOps teams volwassen zijn geworden en er sprake is van zelfsturing, dat de rol van de Cloud Architect uitgespeeld is. Voor de architect ontstaan echter nieuwe uitdagingen. In deze eerste digitale transformatiegolf waar we nu middenin zitten, worden de traditionele silo’s (zoals development, networking, databasebeheer, integratiediensten en beveiliging) doorbroken door in multidisciplinaire teams te werken rond een softwareoplossing. Maar wat daarmee ook ontstaat, is dat de DevOps teams en hun oplossingen en de bijbehorende data zelf de nieuwe silo’s zijn geworden. Dat zit met name de groeiende behoefte om met data slimme dingen te kunnen doen in de weg. Er is dus een architectuur nodig waarbij de datasilo’s moeten worden doorbroken. Op naar de volgende transformatie dus!
Vragen? Stel ze!
Ben jij bezig met de digitale transformatie van jouw organisatie, misschien zelfs als Cloud Architect? Stuur me gerust een bericht- ik kijk graag met je mee.
