For at understøtte en hurtigere gennemløbstid fra idé til produkt og til produktion så kan det give mening for de fleste store organisationer at få etableret tættere bånd mellem organisationens udviklingsafdelinger og organisationernes driftsenheder inden for IT-området. DevOps er på mange måder et interessant koncept der kan findes inden for “agil” systemudvikling, og denne er i høj grad blevet brugt af software- og systemleverandører til at omhandle software der kan anvendes til understøtte koordinering, men DevOps må være mere end det, det må også omhandle ordinær koordinering, hvor “man” forsøger at nedbryde siloerne mellem IT-udviklingsenheden og IT-driftsenheden samt de interessenter der repræsentere forretningsenhederne. Dette blogindlæg tager sit udgangspunkt i den organisatoriske del og ikke i systemunderstøttelses delen.

Hvorfor?

Der findes ofte forskellige prioriteter hvis en enterprise arkitekt stiller spørgsmål til en systemudvikler, eller en systemadministrator. Systemadministratoren vil ofte prioritere sikker og stabil drift frem for nye produkter der bliver sat i produktion. Systemudvikleren eller forretningsarkitekten eller projektlederen vil ofte vurdere at få sat det nye produkt er mindst lige så højt som sikker og stabil drift.

De to måder at anskue verdenen på støder ofte sammen, hvilket kan betyde forsinkelser med leverancerne fra organisationens IT-udviklingsenhed, hvilket kan have den konsekvens af forretningsenhederne ikke får nytte af de investeringer der er foretaget i IT-løsningerne. Dette kan have betydning for organisationens evne til at konkurrere eller til at leve op til kundernes forventninger.

Derfor er det vigtigt at få IT-udviklingsenheden og IT-driftsenheden til at samarbejde bedre.

Hvordan påvirker det service-orienteret arkitektur (SOA)? DevOps påvirker i høj grad SOA ved at der ofte skal udvikles nye integrationer mellem fagsystemer og disse integrationer skal gå fra “udvikling”, “test” og “præproduktion” til “produktion”. For “præproduktion” og “produktion” vil det ofte betyde at IT-driftsenheden skal stå for “deployment” af integrationerne, og dermed skal de involveres i forhold til at understøtte en hurtig og effektiv proces for leverancerne. IT-udviklingsenheden vil på den anden side (sammen med projektlederne) også skulle koordinere bedre med IT-driftsenheden for at sikre at integrationerne kan deployes til de rette miljøer på de rette tidspunkter.

Hvordan?

Der findes flere måder til at få DevOps til at fungere og dette blogindlæg omhandler kun en af disse. Fremgangsmåden tager udgangspunkt i en slags “top-down” fremgangsmåde:

• Få ledelsesopbakning i IT-udviklingsenheden og i IT-driftsenheden.
• Få etableret en møderække mellem udvalgte personer i IT-driftsenheden og i IT-udviklingsenheden.
• Få talt udfordringerne for projektet (og dvs. projektet med at udvikle integrationerne igennem).
• Få aftalt leverance-deadlines mellem IT-driftsenheden og IT-udviklingsenheden og få bestilt dem bagefter via de officielle kanaler, så det er muligt for begge enheder at få styr på bestillinger og fakturering.
• Få de relevante input til udvikling og tilpasning af integrationerne inden IT-løsningen bliver udviklet og sat i drift.
• Få den fornødne opfølgning på svartider og fejl der opstår, når integrationsplatformen anvendes.
• Kommunikerer om udviklingen på integrationsplatformen til interessenterne i både IT driftsenheden og i IT udviklingsenheden.

Konklusioner

Det er vigtigt at få skabt det relevante netværk internt i organisationen, og få de rette interessenter til at deltage på møderne og sørg for at få koordineret med interessenterne jævnligt så ændringer som skal behandles på forkant i projekterne skal etableres.

Sørg for at specialisterne fra IT-driftsenheden og specialisterne fra IT-udviklingsenheden får mulighed for at komme med deres synspunkter for projektet og de tekniske leverancer.