Organisaties die DevOs hanteren zien zich gedwongen een oplossing te vinden voor het beheer van elk van hun (vele) DevOps-teams. Hoe ziet een universeel managementsysteem voor zo’n DevOps-team er dan uit? En hoe voorkom je dat DevOps de ESM-boot mist?

DevOps is een organisatiestructuur met een bijbehorende werkwijze die steeds meer in zwang is bij agile ontwikkelteams in de informatievoorziening. Dat zijn vaak teams die een scrum-techniek hanteren voor het kortcyclisch ontwikkelen van nieuwe IT-functionaliteit. Een product owner vertegenwoordigt de belangen van de stakeholders, een scrum master ondersteunt de werkwijze. DevOps brengt daarbij dan de betrokken stakeholders samen in één team.

Zo’n DevOps-aanpak heeft twee belangrijke voordelen: [1] het benut de kortcyclische ontwikkeltechnieken van scrum, en [2] het verbetert op een gestructureerde wijze de vaak gebrekkige communicatie tussen stakeholders in de IT: de ontwikkelaars die gericht zijn op verandering (‘Dev’), de beheerders die gericht zijn op continuïteit en stabiliteit (‘Ops’), en de business die gericht is op het benutten van de potentie van IT.

DevOps-teams kunnen nog gebonden zijn door een gemeenschappelijk platform waarop de ontwikkelde voorzieningen draaien, maar ze kunnen ook een volledige domeinscheiding doorvoeren (zie onderstaande figuur). Elk DevOps-team is dan feitelijk een onafhankelijk serviceorganisatie, die een eigen productieomgeving beheert voor de beschikbaar gestelde voorzieningen, en een eigen deel van de business ondersteunt.

Ze leiden tot nauwe contacten tussen business, Dev en Ops, en tot snelle aanpassingen van de IT-ondersteuning.

Maar leidt dit ook tot betere dienstverlening? En op de meest effectieve en efficiënte manier?

Waar in de klassieke aanpak een IT-organisatie er naar streefde om één gezicht te trekken naar de business, heeft DevOps vele gezichten: elke squad heeft een eigen gezicht. Die squads kunnen dan nog in tribes gesorteerd zijn om per business-domein enige samenhang te bewerkstelligen.

Om verdere wildgroei tussen DevOps-teams te voorkomen grijpen organisaties vervolgens toch weer naar uniformiteit en standaardisatie. Dat heeft immers zo z’n voordelen: het voorkomt dat ieder DevOps-team z’n eigen wiel gaat uitvinden. Er ontstaat in DevOps-organisaties dus behoefte aan een verticale binding tussen de verschillende horizontale DevOps-teams. Dat noemen we chapters. Die kunnen we indelen naar bijvoorbeeld de aard van werkzaamheden (denk aan een chapter Testen) of naar de aard van technieken (denk aan een chapter Tooling).

Als dat nog niet voldoende samenhang en uniformiteit in de prestaties van DevOps-teams teweeg brengt kunnen we nog een derde interventie plegen: met guilds brengen we squad-leden samen op basis van hun expertise, kennis of specialisme. In hun guild kunnen ze dan samenwerken om weer wat meer standaardisatie van methoden en technieken te bereiken. Een guild is daarmee een soort van special interest group, een expertisecentrum, bijvoorbeeld rond het thema requirements management, of rond architectuur of het gebruik van documentatiesystemen.

Al deze interventies in de oorspronkelijk squad-structuur moeten weer worden gemanaged. Net als ‘vroeger’… Wat hebben we met al deze inspanningen nu eigenlijk gewonnen?

Het antwoord op de laatste vraag is weer terug te voeren op de eerstgenoemde twee voordelen: betere communicatie in een kortcyclische ontwikkelstraat.

Maar had datzelfde effect niet op een andere, universeler manier kunnen worden bereikt?

Wat al deze interventies, van tribe tot chapter en guild teweeg brengen is uiteindelijk immers niet meer dan optimalisatie door middel van standaardisatie. Feitelijk is deze DevOps-structuur (ook wel het Spotify-model genoemd) niet meer dan een poging een gestandaardiseerd managementsysteem per squad te bereiken.

Maar als dat de onderliggende driver is voor de hele set interventies, had een DevOps-organisatie dan niet beter meteen naar een standaard managementsysteem kunnen gaan kijken? En dan niet een managementsysteem waarbij de ontwikkeling van IT-producten centraal staat, maar een managementsysteem waarbij dienstverlening centraal staat? Een retorische vraag…

DevOps-teams zijn kleine IT-fabriekjes, en dus IT-dienstverleners. Daarmee kunnen ze uitstekend gebruik maken van de kennis die in de afgelopen decennia is opgebouwd over dienstverlening. En dus ook van het universele servicemanagementsysteem dat kan worden ingericht met de Universele Service Management methode (USM). Onderstaande figuur illustreert dit op eenvoudige wijze.

Herhaalde USM-toepassing in een DevOps organisatiestructuur

Het uniformeren van een squad-managementsysteem lijkt dus eenvoudig. Maar hoe zit het dan met de integratie tussen IT en andere facilitaire taakgebieden?

Enterprise Service Management

De DevOps-organisatiestructuur was al langer bekend onder de naam serviceteams, maar DevOps voegt daar de bijbehorende agile houding, gedrag en cultuur aan toe, met technieken en instrumenten. Waar DevOps echter niet in voorziet, is de expliciete integratie tussen IT en andere taakgebieden, in een Enterprise Service Management benadering (ESM). En dat is toch echt de toekomst. IT en de andere facilitaire taakgebieden integreren steeds meer met elkaar en met de business. Er gaat geen ziekenhuisdeur meer open zonder een pasje. Met IoT wordt alles aan elkaar geknoopt.

Wie nu focust op een techniek waarbij IT weer centraal staat, mist de ESM-boot.

Het onderkennen van het probleem leidt ook hier weer tot het benoemen van de oplossing. Elke DevOps-squad kan immers haar managementsysteem afstemmen op het uniforme USM-managementsysteem. Datzelfde geldt voor alle andere facilitaire teams. USM levert voor alle serviceorganisaties het universele managementsysteem, of dat IT of gebouwenbeheer is, catering of personeelszaken, beveiliging of fleet management. En daarmee borgen we dat er een eenvoudig ‘clickable’ bouwwerk van uniforme managementsysteem-bouwblokken ontstaat.

Kennis

Wil je ook gebruik kunnen maken van die USM-architectuur bij het verbeteren van de bestuurbaarheid van je serviceorganisatie, voor DevOps of ESM, of voor een combinatie van beide? Wil je leren je tooling daarbij slimmer af te stemmen op die integrale benadering? Geen probleem. Dat leer je in twee dagen in de USM-training. Daarna kun je het zelf toepassen in je eigen DevOps- en/of ESM-aanpak, zonder dure consultants te hoeven inzetten. Het enige dat je nodig hebt is kennis. Kennis van een eenvoudige, universele aanpak die alle voordelen van DevOps combineert met de wens om een organisatiebrede, geïntegreerde ESM-doelstelling na te streven.

Vanaf 1 februari 2019 is versie 2 van het boek “De USM-methode” beschikbaar. Versie 2 is sterk uitgebreid t.o.v. versie 1, en meer toegesneden op het ondersteunen van hbo-opleidingen in ICT en Facility Management. De USM-training van 7-8 maart 2019 is de eerste training die op versie 2 gebaseerd is.