Rubix levert naar volle tevredenheid van haar klanten een Service Oriented Factory (SOFa). Een veel gehoord punt van twijfel om hierop over te gaan is het idee dat dit een grote, complexe last gaat leggen op de organisatie. Daarnaast heerst er vaak een beeld van een waterval methode, die niet aansluit bij de ambitie om Agile/Scrum te gaan werken. Rubix is van mening dat deze werelden juist uitstekend op elkaar aansluiten en gecombineerd voor een grote meerwaarde kunnen zorgen. In dit artikel beschrijven we deze overtuiging. Om dit goed te kunnen duiden, zullen we eerst dieper ingaan op beide concepten en de specifieke uitdagingen die men ervaart wanneer deze concepten worden toegepast in de complexe wereld van integratie.

Waarom een Service Oriented Factory (SOFa)?

De Rubix SOFa is gestoeld op dezelfde principes en doelstellingen als de meer traditionele software factory, namelijk het ontwikkelen van software componenten en applicaties met behulp van een gestandaardiseerd en gestructureerd ontwikkelproces en bijbehorende tools. Hergebruik van kennis, kunde en componenten staat voorop waardoor efficiënt (in termen van tijd en geld) en met continu de juiste en voorspelbare kwaliteit, componenten en zelfs volledige applicaties gerealiseerd kunnen worden. Als we deze principes vertalen naar de Rubix SOFa, dan biedt Rubix kwaliteit (Q), snelheid (S) èn flexibiliteit (F) aan het proces voor het ontwikkelen van services en adapters (de zgn. QSF-criteria). De continuïteit van beschikbare capaciteit is verzekerd, iets wat veelal een actueel probleem is bij bedrijven met een groeiend integratielandschap. 

Hierdoor vereist het voortbrengen van software, als zijnde het een fabriek, discipline in combinatie met een strak proces waarin duidelijke afspraken zijn gemaakt in termen van architectuur, templates, standaarden en richtlijnen. Dit lijkt misschien bijzonder, maar uiteindelijk zou iedere zichzelf respecterende IT-afdeling, die zich bezig houdt met de ontwikkeling van software, op die manier moeten werken. Het enige wat een Service Oriented Factory  onderscheidt, is de extra druk die wordt gelegd op de koppelvlakken tussen de factory en de rest van de organisatie. Denk bijvoorbeeld in termen van requirements en ontwerpen, als input voor de realisatie en de opgeleverde code inclusief unit testen als eindproduct van de factory. De factory dwingt daarmee automatisch de opdrachtgever en de opdrachtnemer de afspraken expliciet vast te leggen én zich beiden te houden aan deze afspraken. Immers de ontwerpen in combinatie met de architectuur en de standaarden en richtlijnen bepalen de scope voor de factory, maar beschrijven tevens het te verwachten eindproduct in termen van functionaliteit en kwaliteit dat door de factory moet worden opgeleverd. Een exercitie die de kwaliteit van het eindproduct sterk bevordert. Mocht dit beeld uw afschrikken omdat uw organisatie dat niveau maar niet lijkt te bereiken, troost u met de wetenschap dat uw organisatie hierin zeker niet uniek is en de introductie van een factory dan juist een middel kan zijn om dit stapsgewijs te gaan bereiken. Rubix heeft de ervaring dat de adoptie van een Service Oriented Factory  vaak een groeiproces is dat gezamenlijk doorlopen wordt.

Maar tot op welk detailniveau moet je zaken dan vastleggen? En wordt het dan niet een ouderwetse waterval? Of kan je dit nog steeds in combinatie met Agile/Scrum? Vanuit Rubix zijn we ervan overtuigd dat een SOFa prima past bij een Agile/Scrum aanpak. De meerwaarde van Agile/Scrum zit ondermeer in een kort cyclische aanpak en de betrokkenheid van de business tijdens de realisatie van business functionaliteit. Een integratie oplossing heeft in zijn algemeenheid de uitdaging dat het (uiteindelijk) wel degelijk business functionaliteit oplevert, maar deze, vanuit het perspectief van de business gebruikers, verborgen zit achter oplossingen zoals schermen, processen en services. Binnen een modern IT-landschap met een Enterprise Service Bus is daardoor de rol van een Solution Architect (of wellicht sluit de term Integratie Architect beter aan) cruciaal. Vanuit die rol wordt namelijk bepaald welke services en aanverwante componenten moeten worden gerealiseerd en wordt de aansluiting met de business requirements geborgd. Vervolgens kunnen de werkzaamheden worden opgedeeld in kleinere ontwerpen met specifieke (deel)wijzigen per service of component, zonder het totaal overzicht te verliezen. Hoe kleiner de opdracht richting de fabriek hoe kleiner de kans op afwijkingen en hoe groter de mogelijkheid om de ‘productielijn’ bij te sturen. Wijzigingen én incidenten zullen dan als items op de backlog van het SOFa team worden opgenomen en, op basis van de gestelde prioriteiten, ook gerealiseerd.

Wat is DevOps?

Eenvoudig gezegd staat DevOps voor het samen gaan van Development en Operations. Waar dit voorheen twee gescheiden werelden met eigen verantwoordelijkheden en processen waren, gaat dit concept ervan uit dat dit één wereld is met gedeelde processen en gezamenlijke verantwoordelijkheid richting de business. DevOps gaat verder waar Agile/Scrum ophoudt, namelijk het betrekken van operations bij het development proces of wellicht wel andersom: het betrekken van development bij het operations proces. Immers vanuit de lifecycle management gedachte van een applicatie, component of service is deze langer in beheer bij operations dan in ontwikkeling bij development. Daarmee wordt de overgang naar beheer vanuit een DevOps team (in theorie) eenvoudiger, er is immers geen handover meer naar beheer (het team doet dit zelf) en de standaarden en richtlijnen vanuit beheer zijn al onderdeel van de ontwikkeling geweest. Als er problemen zijn, dan heeft het team daar dus zelf last van. Een mooi voorbeeld van “Eat Your Own Dogfood”.

Andere concepten die een succesvolle implementatie van DevOps mogelijk ondersteunen zijn:

  • Agile/Scum; kortcyclisch proces van ontwerp, ontwikkeling en test in multidisciplinaire teams inclusief directe betrokkenheid van de business.
  • Continuous Integration; het gebruiken van een volledig geautomatiseerde ontwikkelstraat vanaf het versiebeheer, code kwaliteit en bundelen tot en met het (unit) testen op de testomgeving.
  • Continuous Testing; het geautomatiseerd uitvoeren van testen, beginnend bij code kwaliteit- en unit testen tot en met regressie- en acceptatie testen.
  • Continuous Delivery; het volledig geautomatiseerd uitrollen van software (componenten) over de OTAP straat heen, inclusief alle (geautomatiseerde) testen en tot en met de productie omgeving.

DevOps in multidisciplinaire teams

Omdat Agile/Scrum een belangrijk uitgangspunt is voor het succesvol implementeren van DevOps, is ook de samenstelling van de DevOps teams gebaseerd op de principes van Agile/Scrum. Tijdens de selectie van de teamleden zijn termen als multidisciplinair en multi-inzetbaar belangrijk (iedereen moet alles kunnen), mede omdat een team een maximale omvang van 9 leden heeft. Het te onderhouden landschap wordt daardoor meestal noodzakelijkerwijs opgeknipt en verdeeld over de verschillende teams. Hoewel er tevens andere opties zijn, wordt hierbij meestal gekozen voor het opknippen van het landschap in (groepen van) applicaties, vaak corresponderend met een functioneel business domein. Hierdoor worden één of meerdere teams volledig verantwoordelijk voor dat domein. Voordeel van deze verdeling is dat de domeinkennis in de teams zit en daarmee de aansluiting met de business over het algemeen zeer goed is. Uitgaande van een modern op middleware technologie gebaseerd landschap heeft deze verdeling echter als groot nadeel dat de kennis en ervaring rondom generieke componenten zoals de Enterprise Service Bus (ESB) verdeeld zijn over verschillende teams. Dit leidt tot:

  • een sub-optimale inzet van capaciteit; niet ieder team heeft per sprint altijd evenveel werk voor ieder component uit de applicatie architectuur. Daarbij blijkt het multidisciplinaire uitgangspunt vanuit Agile/Scrum over de as van verschillende technische componenten vaak onrealistisch (een front-end specialist heeft immers een wezenlijk andere technische skillset in vergelijking met een integratie specialist).
  • minder zicht op het naleven van de architectuur en de afgesproken standaarden en richtlijnen; met andere woorden de governance over het integratie landschap heen.
  • het claimen van dezelfde generieke services of componenten van meerdere teams tijdens dezelfde sprint, waardoor afhankelijkheden tussen de teams ontstaat en de teams zonder goede afstemming mogelijk commitments aangaan die niet waargemaakt kunnen worden.
  • een vermindering van het hergebruik van services en componenten, wat de realisatie van de business case voor de inzet van een generiek component als een Enterprise Service Bus onder druk zet.

Een (en misschien zelfs wel dé) manier om deze problemen aan te pakken is het bundelen van de benodigde specialistische kennis in een apart team. Dit noemen we met een mooi ouderwets woord ‘Gilde’. Een gilde verschilt verder niet van de andere DevOps teams, behalve dat het zich richt op één specialisme in het landschap, zoals bijvoorbeeld de Enterprise Service Bus. Extra voordeel van deze aanpak is dat kennisborging en kennisdeling direct en continue plaatsvindt tussen de verschillende leden.

Interactie vanuit het Gilde met de andere DevOps teams zal als vanzelfsprekend moeten blijven plaatsvinden, immers de realisatie en uitrol van de volledige gevraagde business functionaliteit ligt gewoon nog bij die teams. Het Gilde is ondersteunend aan de DevOps teams, maar is vanuit de DevOps gedachte wel volledig verantwoordelijk voor (in dit voorbeeld) de Enterprise Service Bus. Qua development maar zeker ook operationeel en inclusief alle (regressie)testwerkzaamheden en deployments. De afhankelijkheden tussen de Devops-teams en het Gilde moeten bewust afgestemd worden. Functioneel, bijvoorbeeld op het gebied van releases: wat wordt wanneer voor welke user story opgeleverd en wat betekent dit aan opleveringen vanuit het Gilde? Maar zeker ook technisch; hoe wordt gedeployed? Welke afhankelijkheden zijn er? Welke scripts zijn noodzakelijk? Wederom is dit niet iets nieuws, dit moesten de teams ook doen als ze het specialisme in hun eigen DevOps team zouden hebben zitten, echter vanuit het Gilde wordt dit allemaal expliciet(er) gemaakt.

DevOps in de Service Oriented Factory

Vanuit dit concept van een Gilde, dat verantwoordelijk is voor de ontwikkeling en beheer van een Enterprise Service Bus, is de stap naar de eerder beschreven Service Oriented Factory niet zo groot meer: alleen het beheer component uit het Gilde ontbreekt in de SOFa. Dit is perfect op te lossen door de SOFa dienst te combineren met de beheerdienst van Rubix. Beiden diensten opereren nu al vanuit dezelfde locatie, waardoor er eenvoudig een team ontstaat waarin de ontwikkeling op basis van de SOFa wordt gecombineerd met het beheer van de gerealiseerde services, adapters en andere componenten; het initiële uitgangspunt van DevOps. Dit geeft u als klant de mogelijkheid om maximaal te profiteren van beide concepten, denk daarbij ondermeer aan:

  • kort cyclisch werken met regelmatige feedbackloops
  • sterke governance op processen
  • standards en guidelines
  • sterke focus op hergebruik
  • tijdige opleveringen
  • ontzorging op het gebied van resourcing
  • snellere time-to-market met directe beheeraansluiting
  • verlaging van de kosten
  • … en dat alles met een hoge kwaliteit en garantie!

Houd jij je kennis graag up to date?

Mis niets meer van onze kennisdocumenten, events, blogs en cases: ontvang als eerste het laatste nieuws in je inbox!

Fijn dat we je op de hoogte mogen houden!