Q
terug

Regievoering anno 2018: Service integratie als enabler voor Agile en DevOps

De muur die lang tussen ‘build’ en ‘run’ heeft gestaan, wordt afgebroken nu organisaties steeds vaker agile gaan werken en nieuw ontwikkelde software direct naar productie brengen (DevOps). Dit brengt nieuwe uitdagingen met zich mee op het vlak van service integratie, contractering van leveranciers en ketenorkestratie. Hoe ga je het best met deze vraagstukken om? De masterclass die Quint Group en Paphos Group organiseerden, geeft antwoord.

De uitdagingen waar organisaties vandaag de dag tegenaan lopen als het gaat om Service Integration and Management (SIAM) binnen een DevOps-omgeving laten zich het best schetsen aan de hand van een case. Daarom hadden Quint en Paphos Jacco van der Weerd uitgenodigd, manager IT Beleid, Architectuur & Support bij de NS. Hij vertelt: “In het verleden had de NS een versnipperd IT-landschap, wat leidde tot hoge kosten en een te lage betrouwbaarheid van de omgeving. In drie fases hebben we vervolgens een nieuw IT-landschap aanbesteed dat er aanzienlijk eenvoudiger uitziet.”

De eerste fase fase had betrekking op de IT-infrastructuur. Dit contract is gewonnen door KPN. Van der Weerd: “KPN is onze hoofdaannemer én service integrator voor infrastructuur. Daaronder hangen onderaannemers voor de diverse deelgebieden.”
De nieuwe manier van werken is een succes als het gaat om IT operations, zegt Van der Weerd. “De kosten voor IT zijn flink lager en de beschikbaarheid van de infrastructuur is fors hoger. We hebben de afgelopen twee jaren geen treinstoringen meer gehad die het gevolg waren van een IT-storing.”

Behoefte aan sterke service integratie-functie

Wat echter nog verbetering behoeft, is de samenwerking met leveranciers als het gaat om agility, vernieuwing en innovatie. En dat komt doordat het contract is getekend in 2014, toen de visie nog was dat ‘run’ en ‘build’ gescheiden werelden zijn met daartussen ITIL-processen. Met Agile en DevOps komen die werelden bij elkaar, maar daar houdt het contract en de samenwerkingsrelatie nog geen rekening mee. Daar komt bij dat NS in de tussentijd veel meer is gaan ontwikkelen en deployen in de cloud, denk bijvoorbeeld aan allerhande smartphone apps voor conducteurs. “En dat staat op gespannen voet met de reden waarom we onze IT-omgeving hebben vernieuwd, namelijk het tegengaan van versnippering”, zegt Van der Weerd. “Voor je het weet ben je weer terug in de situatie van voor 2014.”

Deze beide ontwikkelingen versterken de roep om een sterke service integratie-functie. “De huidige ontwikkelingen schuren met de oude visie en de bijbehorende contracten. Soms laten contracten best ruimte om op een andere manier samen te werken met leveranciers, maar daar moeten we wel nadrukkelijk naar op zoek gaan. Dat gebeurt niet vanzelf”, weet Van der Weerd.

DevOps stelt nieuwe eisen

Hij geeft een voorbeeld. “We hebben in-house DevOps-teams die aan onze reisinformatiesystemen werken. Dev is al volledig agile, maar Ops nog niet. Het aanvragen van een infrastructuur bij onze externe leveranciers kost nu nog best veel tijd. De DevOps-teams willen de infrastructuuromgeving het liefst volledig geautomatiseerd kunnen afroepen. Dit past bovendien in de DevOps filosofie van “infrastructure as code” waarbij configuratie in een script is vastgelegd en met een druk op de knop automatisch geinstalleerd kan worden. Dit zit echter nog niet in de contracten die we met KPN en de onderliggende leveranciers hebben.”

Daarom is NS nu in gesprek met KPN en de onderaannemers over hoe ze ‘build’ en ‘run’ beter kunnen integreren. Van der Weerd: “Dit heeft natuurlijk impact op de manier waarop we met onze infrastructuurproviders gaan samenwerken. Waar leggen we bijvoorbeeld de regie neer voor service management? Wat betekent dit voor de contracten? Wat wordt de rol van de change manager als ‘build’ en ‘run’ één proces zijn geworden?”

Waar beleg je service integratie?

Om met het regievraagstuk te beginnen: “Je kunt de service integratie-rol in onze ogen niet volledig buiten de deur neerleggen”, vindt Van der Weerd. “Kennis over de samenhang van applicaties in ketens is daarvoor zeer belangrijk en dat zit dicht tegen de core business aan. Tegelijkertijd is het in ons geval ook niet logisch om die rol volledig zelf te vervullen, te meer daar KPN onze hoofdaannemer is voor infrastructuur. Wij hebben daarom gekozen voor een hybride model: het technisch beheer van de onderliggende infrastructuur wordt door KPN gemanaged en de regie op het applicatiebeheer ligt primair bij ons. Die keus hebben we gemaakt omdat ons applicatielandschap veel maatwerk bevat en er bovendien veel samenhang is tussen de verschillende applicaties. Die kennis kun je haast niet buiten de deur neerleggen. Je moet als service integratie manager snappen: als dit fout gaat, dan werkt het daar en daar in door. “

De verantwoordelijkheden worden uiteraard vastgelegd in het contract, maar tegelijkertijd is zo’n contract niets waard als de mensen die moeten samenwerken zich niet in elkaars situatie verdiepen en elkaar niet volledig vertrouwen. Van der Weerd geeft een voorbeeld: “Het team dat verantwoordelijk is voor de reisplanner had bedacht dat klanten het wellicht wel fijn zouden vinden als ze wat meer reisadviezen zouden krijgen. Wat ze niet hadden bedacht is dat dit meer rekenwerk vraagt en dat het dan maar zo kan zijn dat er ergens een server uitvalt omdat de onderliggende infrastructuur hier niet op is berekend. Functioneel verandert er niets aan de applicatie, maar je vraagt wel meer capaciteit van het onderliggende netwerk en de servers. Dit type vergissingen voorkom je niet met contracten maar alleen met goede samenwerking in de keten.

Onderling vertrouwen

Ook de relatie tussen service integrator en de onderaannemers is soms een lastige. “Want bij andere klanten zijn die bedrijven concurrenten, terwijl ze bij ons moeten samenwerken. Natuurlijk ligt daar een gevoeligheid, dat moet je ook open kunnen bespreken. Het hoort bij een volwassen relatie dat je ondanks die gevoeligheid toch op een professionele manier met elkaar samenwerkt. Van der Weerd benadrukt daarom dat voor service integratie in een DevOps omgeving natuurlijk een goed service integratie model, goede contracten en de juiste tooling nodig zijn. “Maar uiteindelijk is het mensenwerk. Het gaat om goed onderling vertrouwen.”

Drie randvoorwaarden voor succesvolle SIAM in een DevOps-omgeving

Frank Grift (Global Lead SIAM bij Quint) gaf een helder overzicht van de drie belangrijkste
randvoorwaarden voor succes van SIAM.

  1. Welke service integrator rol past bij mijn situatie? De meeste organisaties werken zowel met DevOps als met waterval. Ze doen een deel van de ontwikkeling zelf, maar ze werken ook samen met externe leveranciers. Ze hebben bovendien applicaties die nog volop in ontwikkeling zijn en applicaties die zich aan het eind van hun levenscyclus bevinden en waar nauwelijks nog ontwikkeling op plaatsvindt. De vraag is: waar leg ik de service integratie-rol neer? Neem ik die intern op me, plaats ik die volledig buiten de deur of kies ik voor een hybride vorm? En als ik kies voor een externe service integrator, kies ik dan voor een hoofdaannemer die primus inter pares is. Of benoem ik een service integrator die zelf geen vendor is in mijn omgeving?
  2. Hoe sluit mijn contractering hierbij aan? Zowel van softwareleveranciers als van leveranciers van infrastructuur verwacht je vandaag de dag dat zij een proactieve rol pakken. Dat wil zeggen dat ze proactief signaleren als iets niet goed loopt in plaats van dat ze afwachten tot ze concreet opdracht krijgen om actie te nemen. Toch zit er wel een verschil in de aansturing van beide typen partijen, denkt Blaauboer. “Met softwareleveranciers wil je waarschijnlijk graag de richting van cocreatie op, terwijl het voor platformleverancier voldoende is om te contracteren op aspecten als voorspelbaarheid, betrouwbaarheid en snelheid.”
  3. Welke tooling hoort hierbij? SaaS, IaaS, PaaS; IT-omgevingen worden steeds gevarieerder en complexer, met als gevolg dat er steeds meer tooling nodig is om de gehele levenscyclus van applicaties goed aan te sturen, zeker nu organisaties ook nog eens agile gaan werken. Blaauboer adviseert om te kiezen voor één overkoepelende tool voor de ketenorkestratie. Deze tool haalt real-time de voor regie benodigde data op uit de onderliggende service tools. Zie ook kader Tooling kan regievoering ondersteunen.

Tooling kan regievoering ondersteunen

Mark Elbertsen en Robin Marchand van Paphos Group gaan dieper in op de benodigde SIAM-tooling. Zij zijn gespecialiseerd in de implementatie van ServiceNow, Microfocus & AppDynamics, maar in principe geldt de aanpak die zij uit de doeken doen ook voor alle andere tools. Marchand zegt: “Uiteindelijk draait service integratie om voor een groot deel op vertrouwen. Vertrouwen kweek je alleen als iedereen real-time beschikt over dezelfde juiste data en deze data ook als enige waarheid ziet. Want anders blijf je discussies houden over of de lijstjes wel kloppen. Daarom is het zo belangrijk te werken met een SIAM-tool die ervoor zorgt dat data real-time in de keten kan worden gedeeld. Op die manier kun je de governance borgen op één platform. Je bekijkt per onderliggende tool en/of leverancier welke informatie op integraal niveau belangrijk is om te delen met het oog op een goede regievoering en welke data je juist niet wil delen met het oog op de vertrouwelijkheid of mate van detail.”

Elbertsen geeft een demonstratie van ServiceNow, zodat alle aanwezigen een goed beeld hebben van hoe je SIAM inricht in software. Het wordt al snel duidelijk dat de tooling nooit het probleem vormt. “Regievoering is echter meer dan het goed inrichten van een tool. Je zult vooral goed met alle leveranciers moeten afstemmen hoe je met elkaar communiceert. Bijvoorbeeld: welke informatie deel je bij een incident? Een ander punt is het woordgebruik. Verschillende tools gebruiken soms verschillende benamingen voor hetzelfde. Dat is geen enkel probleem voor het inrichten van je regietool, maar je kunt wel in Babylonische spraakverwarringen belanden als je onderling telefonisch contact opneemt om een case door te spreken.” Daarnaast dient de focus te liggen op het automatiseren van het werk i.p.v het verplaatsen naar de leveranciers. Hier is nog veel winst te behalen.

Een ander aandachtspunt is het feit dat er vaak veel afhankelijkheden zitten tussen leveranciers die betrokken zijn bij één dienst. “Het is niet altijd duidelijk bij welke leverancier het probleem ligt. Je kunt dan wel een tool inrichten die automatisch een ticket doorzet, maar soms is eerst overleg nodig tussen de verschillende betrokken partijen. Soms moet je taken ook opknippen: eerst moet dit worden gedaan voordat vervolgens dat kan worden opgelost. Je kunt dit soort dingen op termijn allemaal automatiseren, zeker als je hiervoor zelflerende algoritmes voor gebruikt die van iedere case leren. Maar uiteindelijk ligt de kern van het succes in goed samenwerken. Als de service integrator een ticket doorzet naar partij A, maar partij B denkt ‘dit probleem ligt eigenlijk bij mij’, dan wil je dat partij B aan de bel trekt. Dat zal alleen gebeuren als de betrokkenheid hoog is, de transparantie groot en als mensen bereid zijn elkaar te helpen. De techniek kan dit allemaal ondersteunen, maar het valt of staat bij mensen die intrinsiek gemotiveerd zijn om samen te werken.”

En daarmee bevestigt hij de woorden van Van der Weerd: natuurlijk zijn het samenwerkingsmodel, de contracten en de tooling belangrijk bij service integratie, maar uiteindelijk is het mensenwerk.