Q
terug

Regie op DevOps

Het blijft maatwerk

Steeds meer organisaties willen terecht hun regie zo lean mogelijk inrichten en specifiek wanneer ze overgaan naar DevOps-werken. Ze vragen zich daarbij af of er überhaupt nog regie nodig is en zo ja, wat er dan minimaal nodig is. In dit artikel geven we daarop een kort antwoord. Uiteraard is ook een langer antwoord voorhanden en vanzelfsprekend is elke situatie anders. In dit artikel leest u:

  • Wat er nodig is aan regie indien uw organisatie DevOps is ingericht.
  • Wat dit betekent voor de DevOps-organisatie.
  • Hoe de regie zich verder kan ontwikkelen als DevOps geïmplementeerd wordt.

De case: DevOps-teams die werken op outsourced infrastructuur

Als voorbeeld nemen wij een organisatie die al jaren geleden de infrastructuur heeft uitbesteed aan een serviceprovider en de afgelopen jaren daarnaast steeds meer cloudoplossingen heeft geïntroduceerd. Ondertussen is applicatieontwikkeling en -beheer steeds meer DevOps geworden: Product owners stellen prioriteiten en de DevOps-teams zijn verantwoordelijk voor nieuwe functies en het beheer. Schoorvoetend bereiden de teams hun beheer naar een 7×24 uurs service uit. Dit beheer houdt echter wel op bij de infrastructuur. Hiervoor zijn dus leveranciers en interne infrateams verantwoordelijk. De organisatie vraagt zich af wat men nog aan regie nodig heeft.

De vier vormen van regie die nodig zijn bij DevOps

DevOps-diensten hebben het grote voordeel dat deze in samenhang met de business worden ontwikkeld en beheerd. Hierop is in principe geen regie nodig. Omdat er echter vrijwel altijd een omgeving is, bestaande uit andere diensten, in- en externe normen, én leveranciers, zien wij de volgende vier mogelijke aanvullingen door regie, die meestal nodig zijn (zie ook figuur):

  1. Centrale besturing: op strategisch niveau is (altijd) regie nodig die de randvoorwaarden schept voor de leveringsstromen. Denk hierbij aan de enterprise architectuur, de sourcingkeuzes, de financiële afspraken, de in- en externe regelgeving en het managen van het overall risicobeeld.
  2. Customer service management: Om te zorgen dat afnemers alle IT-services gemakkelijk kunnen afnemen (ook de diensten die collectief worden afgenomen) is servicemanagement nodig voor bijv. beheer van de service catalogus en beheersing en eventuele verrekening van servicekosten.
  3. Afstemming bij changes: Om te zorgen dat de verschillende services op elkaar blijven aansluiten qua data en functionaliteit c.q. elkaar niet hinderen bij wijzigingen is afstemming nodig. Met name om de centrale vraag ‘wanneer mag wat wijzigen’ te beantwoorden.
  4. Leveranciersmanagement: Om te zorgen dat de sturing op de betrokken leveranciers optimaal blijft en het schaalvoordeel van de totale organisatie uitgenut kan worden is gezamenlijke sturing op de leveranciers nodig. Ook bij cloudgebruik levert centraal inkopen en besturen van het verbruik voordelen op.

Figuur: Mogelijke regie bij DevOps

Hoe regie zich ontwikkelt terwijl de organisatie verandert door DevOps en Cloud

Ook onze voorbeeldorganisatie heeft vier vormen van regie nodig. Wel beseffen we dat de meeste DevOps-teams dit als een beperking van hun autonomie zien. Op termijn verwachten wij daarom de volgende verschuivingen:

  • Naarmate de centrale besturing explicieter de kaders aangeeft, kunnen de DevOps-teams meer aan zelfsturing doen. Voorbeelden van kaders die gesteld moeten worden zijn: een enterprise architectuur en een integraal sourcingsbeleid.
  • Naarmate de business de DevOps-teams meer integraal aanstuurt neemt de behoefte aan Servicemanagement af. Echter, gezamenlijke diensten blijven gewenst zoals een beheerde werkplek. Ook moet regie borgen dat diensten van elkaars data en interfaces gebruik kunnen maken en dat de bijvoorbeeld de financiële verrekening c.q. het gebruik van het gehele financiële budget op orde is.
  • Naarmate de applicaties meer via SaaS- of Paas-oplossingen gerealiseerd worden, kan de verantwoordelijkheid voor change management bij de DevOps-teams gelegd worden. Centraal change management wordt dan minder belangrijk, behalve als er interfaces tussen de diensten worden geraakt.
  • Naarmate de DevOps-teams specifieke eigen leveranciers hebben, is er ten slotte minder overall leveranciersmanagement nodig. Er is nu nog regie nodig over het infrastructuurcontract om te voorkomen dat door alle cloudoplossingen de totale infrastructuurkosten oplopen. Bovendien zien we het nut van mantelcontracten die de inhuur van DevOps-medewerkers regelen en waarmee de groei van de samenwerking met de leveranciers wordt ondersteund.

Regisseren is en blijft een werkwoord, waarbij de organisatie waarin dit plaatsvindt continu moet mee veranderen met de objecten waarover regie wordt gevoerd. Regie blijft maatwerk!


Auteurs: Roos Uffink, Menzo Meijer en Ronald Israels (Consultants bij Quint)