<commit_before><!doctype html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <title>Orkestrering av IT-utvikling i store organisasjoner</title>
  <meta name="description" content="Smidig Digitalisering 2016">
  <meta name="author" content="<NAME>">
  <meta name="apple-mobile-web-app-capable" content="yes" />
  <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
  <link rel="stylesheet" href="css/reveal.min.css">
  <link rel="stylesheet" href="lib/css/zenburn.css">
  <link rel="stylesheet" href="css/theme/bekk.css" id="theme">
  <link rel="stylesheet" href="css/custom.css" id="custom">
  <script>
    document.write('<link rel="stylesheet" href="css/print/' + (window.location.search.match(/print-pdf/gi) ? 'pdf' : 'paper') + '.css" type="text/css" media="print">');
  </script>
</head>

<body>
  <div class="reveal">
    <div class="slides">

    <section>
      <h1 style="float: left;">Orkestrering av IT-utvikling<br>i store organisasjoner</h1>
      <img src="img/dirigent.png" style="background: #222; border: 0px; float: right; width: 400px;">
      <!--<p style="float: right;">Smidig digitalisering 2016</p>-->
      <aside class="notes">
           <NAME> og jobber i BEKK.
      </aside>
    </section>

    <section>
      <img src="img/slutt_med_it-prosjekter.png">
      <footer style="font-size: 0.5em;"><a href="http://open.bekk.no/slutt-med-it-prosjekter">http://open.bekk.no/slutt-med-it-prosjekter</a></footer>
      <aside class="notes">
      <ul>
        <li>I fjor høst skrev jeg en bloggpost og holdt et foredrag her på Smidig om at man bør slutte med IT-prosjekter.
        <li>Den fikk en del oppmerksomhet og startet en del gode diskusjoner.
        <li>Det er mange gode grunner for å slutte med IT-prosjekter, men den jeg skal snakke om i dag er
        <li>hvordan man kan få bukt med all koordinering, synkronisering og orkestrering som må håndteres.
        <li>Ikke bare i IT-prosjekter, men også i store organisasjoner generelt.
      </ul>
      </aside>
    </section>

    <section>
      <img src="img/avhengigheter.jpg">
      <aside class="notes">
        I store organisasjoner er det mange avhengigheter
        <ul>
          <li>mellom leveranseteam
          <li>linjeorganisasjonen
          <li>mellom avdelinger
          <li>til forvaltning
          <li>til forretning
          <li>til ledere
          <li> og mellom IT-systemer
        </ul>
      </aside>
    </section>

    <section>
        <img style="width: 900px;" src="img/gantt.png">
        <aside class="notes">
          Derfor bruker man masse tid på omfattende planlegging, dokumentasjon, løpende koordinering, overleveringer, møter og endringsanmodninger.<br><br>
          Det koster mye tid og krefter og bidrar ikke til å løse de reelle utfordringene.<br><br>
          Effektene av dårlig organisering løses best ved OMORGANISERING, ikke ved mer koordinering og kontroll.
        </aside>
    </section>

    <section>
        <h2>Hva har prosjektledere i verktøykassa?</h2>
        <img src="img/toolbox.png">
        <aside class="notes">
        En av årsakene til at planlegging oppfattes som eneste mulighet for orkestrering av aktiviteter og instanser er at det innenfor prosjektleder-faget ikke finnes noe godt alternativ til 
        <ul>
          <li>omfattende planlegging
          <li>mange roller
          <li>mange aktiviteter
          <li>sjekkpunkter og milepæler.
        <ul>
       </aside>
    </section>

    <section>
        <img style="background: #222; border: 0px; width: 900px;" src="img/prince2_tube_map_v2.3.png">
        <aside class="notes">
          Prince2 har mange verktøy for prosjektledelse, men ikke <b>ett</b> sted er IT-arkitektur beskrevet som et virkemiddel.<br><br>
          Alle virkemidlene handler om prosesser, sjekkpunkter, milepæler, dokumenter, overleveringer, og planer.
        </aside>
    </section>

    <section>
        <img src="img/bekkelund.png" style="background: #222; border: 0px; float: left;">
        <blockquote cite="http://www.bekkelund.net/2014/12/11/livssykluser/" style="float: right;">&ldquo;...<div style="color: #35bdb2; display:inline;">hus og programvare er to forskjellige ting</div>. Huset er konkret og må planlegges før det bygges, fordi det er vanskelig å endre det i etterkant. <div style="color: #35bdb2; display:inline;">Programvare</div>, derimot, er abstrakt og <div style="color: #35bdb2; display:inline;">trenger liten grad av planlegging før det bygges</div>, fordi det er enkelt å endre det i etterkant.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="http://www.bekkelund.net/2014/12/11/livssykluser/"><NAME>, Livssykluser, 2014</a></footer>
        <aside class="notes">
          Det som er fint med software og IT-arkitektur er at det er veldig fleksibelt.<br><br>
          Det er ikke som å bygge hus.<br><br>
          Og endringer i IT-arkitektur vil påvirke organisasjonen.<br><br>
          Det kan til og med brukes for å unngå alle disse avhengighetene som er så vanskelige å planlegge, orkestrere og koordinere.
        </aside>
    </section>

    <section>
      <h2>Men prosjektene er jo Smidig!</h2>
      <aside class="notes">
      Smidig er bra, og smidig skal vi være, men det er ikke nok!
      </aside>
    </section>

    <section>
        <img style="background: #222; border: 0px; width: 800px;" src="img/safe4.png">
        <aside class="notes">
          Etter min mening har det vært et alt for stort fokus på PERSONER OG SAMSPILL at de tekniske forutsetningene for å lykkes med Smidig blir helt borte.<br><br>
          Alt fokus blir også med Smidig fokusert rundt å bekjempe avhengigheter med *prosess*.
          Smidig funker derfor bra i småskala, men blir det stort må du se andre steder for å finne ut hvordan det skal skalere.
        </aside>
    </section>

    <section>
        <h2>Kommuniser mindre!</h2>
        <aside class="notes">
          Den store synderen er alt fokuset på kommunikasjon.<br><br>
          Kommunikasjon på tvers av team ender fort opp med misforståelser, uenigheter, tidkrevende møter og omfattende dokumentasjon.<br><br>
          Man bør derfor se etter løsninger hvor teamene er mindre avhengige av å måtte kommunisere med andre team.
          Teamene bør være mest mulig autonome.
        </aside>
    </section>

    <section>
      <h2>Autonome team</h2>
      <blockquote>&ldquo;<div style="color: #35bdb2; display:inline;">Autonome team</div> er team som kan <div style="color: #35bdb2; display:inline;">løse alle oppgaver</div> som skal til for å videreutvikle produkter <div style="color: #35bdb2; display:inline;">uten ekstern innblanding</div> eller behov for å henvende seg til utenforstående personer.&rdquo;</blockquote>
      <footer style="font-size: 0.5em;"><a href="https://radar.bekk.no/tech2016/prosess-og-kvalitet/autonome-team">BEKK Radar 2016</a></footer>
      <aside class="notes">
        Autonome team er team som kan løse alle oppgaver som skal til for å videreutvikle tjenester uten ekstern innblanding eller behov for å henvende seg til utenforstående personer.<br><br>
        Får du til fullstendig autonomitet, så vil tjenesteutvikling per team foregå raskest mulig.
      </aside>
    </section>

    <section>
        <h2>Vi må kommunisere <u>mindre!</u></h2>
        <img src="img/bezos.jpg" style="float: left;">
        <blockquote cite="http://www.amazon.com/The-Everything-Store-Bezos-Amazon/dp/0316219266" style="float: right;">&ldquo;Communication is a sign of dysfunction... We should be trying to figure out a way for teams to communicate less with each other, not more.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="http://www.amazon.com/The-Everything-Store-Bezos-Amazon/dp/0316219266"><NAME>, CEO i Amazon</a></footer>
        <aside class="notes">
          Vi må derfor redusere behovet for kommunikasjon mellom team.<br><br>
        </aside>
    </section>

    <section>
        <h2>All kommunikasjon skal foregå over API-er!</h2>
        <img src="img/bezos.jpg" style="float: left;">
        <blockquote cite="" style="float: right;"> &ldquo;The only communication allowed is via service interface calls over the network.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="https://plus.google.com/+RipRowan/posts/eVeouesvaVX"><NAME>, CEO Amazon, i følge en tidligere ansatt i Amazon</a></footer>
        <aside class="notes">
          Derfor påla Bezos i 2002 alle i Amazon å <b>kun</b> kommunisere mellom systemer over veldefinerte API-er.
        </aside>
    </section>

    <section>
        <h2>Ellers får du sparken!</h2>
        <img src="img/bezos.jpg" style="float: left;">
        <blockquote cite="https://plus.google.com/+RipRowan/posts/eVeouesvaVX" style="float: right;"> &ldquo;Anyone who doesn’t do this will be fired.
        <br>Thank you; have a nice day!&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="https://plus.google.com/+RipRowan/posts/eVeouesvaVX"><NAME>, CEO Amazon, i følge en tidligere ansatt i Amazon</a></footer>
        <aside class="notes">
          Og han mente det!
        </aside>
    </section>


    <section>
        <img src="img/teams_api.png">
        <footer style="font-size: 0.5em;"><a href="https://www.youtube.com/watch?v=_wnd-eyPoMo">Fra Architecting for Continuous Delivery, <NAME>, 2015</a></footer>
        <aside class="notes">
          Hvorfor gjorde han så det? Hva betyr det?<br><br>
          Smidige team kommuniserer veldig tett internt.<br><br>
          Men med en gang de må synkronisere seg med andre team blir det problemer.<br><br>
          Derfor bør man lage IT-arkitektur på en sånn måte at det å legge til ny funksjonalitet påvirker én tjeneste og ett team.<br><br>
          Data og funksjonalitet implementeres der hvor det i et forretningsperspektiv hører best hjemme.<br><br>
          All kommunikasjon mellom systemer foregår over API-er. Det gjør at hvert team kan kjøre full fart uten avhengigheter til andre team.
        </aside>
    </section>

    <section>
      <h2>Conway's lov</h2>
      <img src="img/how_do_committees_invent.png" style="float: left;">
      <blockquote cite="https://en.wikipedia.org/wiki/Conway%27s_law" style="float: right;">
        &ldquo;Organizations which design systems ... are constrained to produce designs which are copies of the communication structures<br>of these organizations&rdquo;
      </blockquote>
      <footer style="float: right; font-size: 0.5em;"><a href="http://www.melconway.com/research/committees.html"><NAME>, How Do Committees Invent, 1968</a></footer>
      <aside class="notes">
          <NAME> sa i 1968 at systemene dine vil gjenspeile organisasjonen din.
          Det er derfor måten vi er organisert på som fører til at IT-arkitekturen blir som den blir.
      </aside>
    </section>

    <section>
      <h2>Silo-organisasjon</h2>
      <img src="img/silos.jpg" alt="siloer" width="600px">
      <footer style="font-size: 0.3em;"><a href="https://www.flickr.com/photos/nakrnsm/3898381742">Photo by <NAME></a></footer>
      <aside class="notes">
        <ul>
          <li>Det er ikke uvanlig at team er organisert etter teknologi (web-team, backend-team, integrasjons-team).
          <li>Eller etter funksjon (utvikling, test, drift, sikkerhet, ux, forretning).
          <li>Slike inndelinger kalles silo-organisasjon og kompliserer kommunikasjonen enormt.
          <li>Det er dessuten veldig lite effektivt fordi oppgaver må løses på tvers av flere enheter
          <li>noe som medfører overleveringer, venting og misforståelser.
        </ul>
      </aside>
    </section>

    <section>
      <h2>Monolitten</h2>
      <img src="img/microservices1.png">
      <footer style="font-size: 0.5em;"><a href="http://martinfowler.com/articles/microservices.html">Microservices, a definition of this new architectural term, <NAME> og <NAME>, 2014</a></footer>
      <aside class="notes">
        Om utviklingsteamene er organisert lagdelt for eksempel vil resultatet bli monolittiske applikasjoner<br><br>
        Det vil si at all forretningsfunksjonalitet blir implementert i en gigantisk applikasjon med en gigantisk database.<br><br>
        Problemet med denne arkitekturen er at den til slutt faller over av sin egen tyngde og at endringer blir værre og værre å implementere.<br><br>
        En liten endring ett sted kan påvirke mange andre deler av systemet.
      </aside>
    </section>

<!--    <section>
      <h2>Avmystifisering av Conway's lov</h2>
      <img src="img/sam_newman.jpeg" style="float: left;">
      <blockquote cite="https://www.thoughtworks.com/insights/blog/demystifying-conways-law" style="float: right;">&ldquo;Microservices allow organizations to align the architecture of their systems to the structure of their teams.&rdquo;</blockquote>
      <footer style="font-size: 0.5em;"><a href="https://www.thoughtworks.com/insights/blog/demystifying-conways-law"><NAME>, Demystifying Conway’s Law, 2015</a></footer>
      <aside class="notes">
        Isteden bør man lage mindre systemer organisert rundt forretningsbehov.<br><br> 
        Man splitter rett og slett opp systemene basert på forretningsområdene i organisasjonen.
      </aside>
    </section> -->

    <section>
      <h2>Mikrotjenester</h2>
      <img src="img/microservices2.png">
      <footer style="font-size: 0.5em;"><a href="http://martinfowler.com/articles/microservices.html">Microservices, a definition of this new architectural term, <NAME> og <NAME>, 2014</a></footer>
      <aside class="notes">
         Isteden bør man lage mindre systemer organisert rundt forretningsbehov.<br><br>
         Man splitter rett og slett opp systemene basert på forretningsområdene i organisasjonen.
         Da vil systemene og teamene dine speile de forretningsbehovene du har<br>
         og en endring i <b>ett</b> forretningsbehov vil kun påvirke <b>ett</b> system.
      </aside>
    </section>

    <section>
      <h2>En teknisk løsning på en organisatorisk utfordring</h2>
       <footer style="font-size: 0.5em;">Eksemplet er hentet fra <a href="http://blog.jessitron.com/2016/05/tradeoffs-in-coordination-among-teams.html">"Tradeoffs in Coordination Among Teams"</a> av <NAME></footer>
      <aside class="notes">
        I store organisasjoner må du derfor se på IT-arkitektur for å bli mer effektiv.<br><br>
        Det holder ikke med Smidig.<br><br>
        Smidig skalerer dårlig uten å gjøre noe med de teknologiske forutsetningene.
      </aside>
    </section>

    <section>
        <h2>Et team med et stort potensiale</h2>
        <img src="img/arrow.png">
        <aside class="notes">
        La oss si at vi har ett team på 2-7 folk.<br>
        Den tomme pilen representerer potensialet eller kapasiteten til teamet.
        </aside>
    </section>

    <section>
        <h2>Full fart! &#9786;</h2>
        <img src="img/filled-arrow.png">
        <aside class="notes">
        La oss is at vi skal lage en byggesøknads-applikasjon.<br><br>
        Teamet kjører full fart og bygger en skjemaløsning som lagrer søknader i en database.
        </aside>
    </section>

    <section>
        <h2>Skalering til to team som jobber på samme system.</h2>
        <img src="img/two-arrows-coordinating.png">
        <aside class="notes">
        Etter en stund så trenger de et system for saksbehandlere som skal behandle søknadene så de danner to Smidig-team.<br><br>
        Vi bruker fortsatt samme database og bygger en saksbehandlerapplikasjon på den samme plattformen.<br><br>
        Derfor må de to teamene samarbeide. Flere folk fører til mer kommunikasjonsoverhead.
       </aside>
    </section>

    <section>
        <h2>Vi må skalere mer!</h2>
        <img src="img/four-arrows-coordinating.png">
        <h2>... men fremdriften er dårlig &#9785;</h2>
        <aside class="notes">
        Så skal det integreres mot kartverket, det skal lastes opp tegninger, og det skal skilles mellom bedrifter og privatpersoner.<br><br>
        Nå begynner det å bli et salig rot.<br><br>
        Hvis bedriftsteamet endrer databasen ødelegger det for privat-teamet.<br><br>
        Oppgraderinger av rammeverk og systemer kan ikke gjøres fordi det vil ødelegge for de andre<br><br>
        Konsensus og koordinering begynner å bli uoverkommelig og utviklerne har ikke oversikt over systemet som et hele lenger.<br><br>
       </aside>
    </section>

    <section>
        <h2>Brooks' lov</h2>
        <img src="img/brooks.jpg" style="float: left; height: 400px;">
        <blockquote cite="https://en.wikipedia.org/wiki/Brooks%E2%80%99_law" style="float: right;">&ldquo;Adding manpower to a late</br>software project makes it later.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="https://en.wikipedia.org/wiki/Brooks%E2%80%99_law"><NAME>, The Mythical Man-Month, 1975</a></footer>
        <aside class="notes">
        På grunn av kommunikasjons-overhead.
       </aside>
    </section>

    <section>
        <img src="img/api.jpg">
        <aside class="notes">
        Noe må gjøres så vi splitter opp monolitten i deler med:<br><br>
        <ul>
          <li>Hver sin database og dupliserer data om det er nødvendig.
          <li>Hver sin applikasjon med veldefinerte API-er for kommunikasjon mellom de
        </ul>
        </aside>
    </section>

    <section>
        <h2>Autonome team med mye ansvar (DevOps)</h2>
        <img src="img/wide-arrows-coordinating.png">
        <aside class="notes">
        Dette er en annen type overhead. Den er teknisk fordi alle teamene må vedlikeholde hvert sitt system.<br><br>
        Derfor er pilene tykkere. Farten er omtrent den samme som før.<br><br>
        Forskjellen er at det skalerer. Vi kan legge til flere team uten at kommunikasjon blir en hindring igjen.<br><br>
        Det er ingen koordinering av releaser og alle kjører på i sitt eget tempo.<br><br>
        Merk at retning og overordnet visjon er et forretningsanliggende, så der må det være konsensus.
        </aside>
    </section>

    <section>
        <h2>Ingen vits i å finne opp hjulet på nytt (&ldquo;DevOps&rdquo;-teams)</h2>
        <img src="img/organized-arrows.png">
        <aside class="notes">
        Hvis alle teamene gjør alt forskjellig og bruker helt forskjellige teknologier så forblir pilene tykke.<br><br>
        Det *kan* være mer effektivt å ha egne team som er tjenesteytere til de andre teamene.<br><br>
        For eksempel å lage deployskript, automatisere opprettelse av miljøer, supportere velprøvde databaser osv.<br><br>
        Merk at det er fremdeles separate databaser og separate applikasjoner.
        Dette fungerer bare om infrastruktur-teamene er som kundeservice.
        </aside>
    </section>

    <section>
        <h2>Ikke standardiser teknologi eller lag felleskomponenter!</h2>
        <aside class="notes">
        Viktig å kunne velge riktig teknologi for det du skal lage.
        Teamene må ha frihet til å velge riktig verktøy for jobben.
        Felleskomponenter bør unngås for enhver pris.
        Disse skaper bare trøbbel med bakoverkompatibilitet og krever mye vedlikehold.
        I tillegg vil endringer som er påkrevd av ett system potensielt ødelegge for andre systemer.
       </aside>
    </section>

    <section>
        <h2>NoOps</h2>
        <img src="img/cloud-arrows-coordinating.png">
        <aside class="notes">
        NoOps er et konsept hvor du bruker tjenester hos en public cloud leverandør.<br><br>
        Da trenger du ikke å bekymre deg over drift selv. Det er overlatt til verdens beste driftere<br><br>
        Det er naivt å tro at din egen driftsavdeling kan konkurrere med de store public cloud leverandørene.<br><br>
        Og i den verdenen er *alt* API-er så derfor er det veldig lett å bruke disse tjenestene.
        </aside>
    </section>

    <section>
        <h2>Eksempler</h2>
    </section>

    <section>
        <h2>Amazon: A shared nothing infrastructure</h2>
        <img src="img/wide-arrows-coordinating.png">
        <blockquote cite="https://queue.acm.org/detail.cfm?id=1142065"> &ldquo;You build it, you run it&rdquo;</blockquote>
       <footer style="font-size: 0.5em;"><a href="https://queue.acm.org/detail.cfm?id=1142065"><NAME> (CTO i Amazon) </a></footer>
        <aside class="notes">
          Alle team kan peise på i eget tempo.<br><br>
          Ingenting er delt.<br><br>
          Har ganske mye teknisk overhead fordi ingenting er delt.
        </aside>
    </section>

    <section>
        <h2>Spotify: Squads &amp; Tribes</h2>
        <img src="img/organized-arrows.png">
        <ul>
          <li>Squad: mini-startup (unike tjenester)</li>
          <li>Tribe: mini-startup inkubatorer (forretningsområder)</li>
        </ul> 
        <aside class="notes">
        Har vært organisert sånn frem til nå, men er på vei til Google Cloud. Det koster *mye* å drifte sin egen infrastruktur.
        </aside>
    </section>

<!--    <section>
      <img src="img/spotify_containers.png">
      <aside class="notes">
        Hvert team jobber med sitt forretningsområde.
        Før var Spotify en monolitt, men nå har de team som har ansvar for selve spilleren, spillelista, artistinformasjon, mobilapp og så videre.
      </aside>
    </section> -->

    <section>
        <h2>Skatt: Infrastruktur som en intern tjeneste</h2>
        <img src="img/organized-arrows.png">
        <aside class="notes">
        Infrastruktur team tilbyr verktøy og infrastruktur som tjenester i en privat sky.<br><br>
        Har i stor grad mikrotjenestearkitektur.<br><br>
        Det er en kraftig forbedring, men det koster mye å hoste sin egen sky, og mye blir standardisert på en sånn måte at friheten til utviklingsteamene ikke er stor nok.<br><br>
        DevOps-teamet blir fort en flaskehals når det er så mange behov. Så her får du også et skaleringsproblem.
        </aside>
    </section>

    <section>
        <h2>FINN.no: We are now removing the Ops teams</h2>
        <h1><img src="img/organized-arrows.png"> &rarr; <img src="img/wide-arrows-coordinating.png"></h1>
        <aside class="notes">
        </aside>
    </section>

    <section>
        <h2>Gov.uk: Cloud first</h2>
        <img src="img/govuk-cloud-arrows-coordinating.png">
        <aside class="notes">
Sky gir fantastiske muligheter for å effektivisere systemutvikling. Gov.uk har egne sky-driftere som legger til rette for utviklingsteam.
        </aside>
    </section>

    <section>
        <h2>Netflix: NoOps</h2>
        <img src="img/netflix-cloud-arrows-coordinating.png">
        <aside class="notes">
 Netflix påstår at de har bare utvilkere og abstraherer bort plattformen. Litt som skatt, men i public cloud hvor innovasjonstakten er ekstrem. Du har ikke sjans til å drifte like effektivt i egen datahall.
        </aside>
    </section>

<!--
    <section>
      <img src="img/ultimate_team.png">
      <aside class="notes">
        Den hellige treenighet. Den moderne IT-organisasjonen.
        Kunden, brukerne og et kryssfunksjonelt team som kan løse alt som trengs for å utvikle, drifte og forvalte applikasjoner.
      </aside>
    </section>

    <section>
      <img src="img/scaling.png">
      <aside class="notes">
        Og det skalerer utrolig bra.
        Autonome team som fokuserer på sin del. Hvert team kan løse alle oppgaver som skal til for å videreutvikle sitt forretningsområde uten å ha noen avhengigheter til andre utenfor teamet.
        Og så har du virksomhetens visjon som er som en ledestjerne for alt virksomheten foretar seg.
      </aside>
    </section>
-->
    <section>
       <img src="img/orkestrering_av_it.png">
       <footer style="font-size: 0.5em;"><a href="http://open.bekk.no/orkestrering-av-it-utvikling-i-store-organisasjoner">http://open.bekk.no/orkestrering-av-it-utvikling-i-store-organisasjoner</a></footer>
       <aside class="notes">
       </aside>
    </section>

    <section>
      <h1>Takk for meg!</h1>
      <img width="252" height="235" src="img/me_bart.png" alt="<NAME>"/>
      <p><a href="https://twitter.com/steinim">@steinim</a></p>
      <p><a href="mailto:<EMAIL>"><EMAIL></a></p>
    </section>

</div>
</div>

    <script src="lib/js/head.min.js"></script>
    <script src="js/reveal.min.js"></script>

    <script>
        // Full list of configuration options available here:
        // https://github.com/hakimel/reveal.js#configuration<commit_msg>forkortet ennå mer<commit_after><!doctype html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <title>Orkestrering av IT-utvikling i store organisasjoner</title>
  <meta name="description" content="Smidig Digitalisering 2016">
  <meta name="author" content="<NAME>">
  <meta name="apple-mobile-web-app-capable" content="yes" />
  <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
  <link rel="stylesheet" href="css/reveal.min.css">
  <link rel="stylesheet" href="lib/css/zenburn.css">
  <link rel="stylesheet" href="css/theme/bekk.css" id="theme">
  <link rel="stylesheet" href="css/custom.css" id="custom">
  <script>
    document.write('<link rel="stylesheet" href="css/print/' + (window.location.search.match(/print-pdf/gi) ? 'pdf' : 'paper') + '.css" type="text/css" media="print">');
  </script>
</head>

<body>
  <div class="reveal">
    <div class="slides">

    <section>
      <div style="float: left;">
      <h1>Orkestrering av IT-utvikling<br>i store organisasjoner</h1>
      </div>
      <img src="img/dirigent.png" style="background: #222; border: 0px; float: right; width: 400px;">
      <aside class="notes">
           <NAME> jobber i BEKK.
      </aside>
    </section>

    <section>
      <img src="img/slutt_med_it-prosjekter.png">
      <footer style="font-size: 0.5em;"><a href="http://open.bekk.no/slutt-med-it-prosjekter">http://open.bekk.no/slutt-med-it-prosjekter</a></footer>
      <aside class="notes">
      <ul>
        <li>I fjor høst skrev jeg en bloggpost og holdt et foredrag her på Smidig om at man bør slutte med IT-prosjekter.
        <li>Den fikk en del oppmerksomhet og startet en del gode diskusjoner.
        <li>Det er mange gode grunner for å slutte med IT-prosjekter, men den jeg skal snakke om i dag er
        <li>hvordan man kan få bukt med all koordinering, synkronisering og orkestrering som må håndteres.
        <li>Ikke bare i IT-prosjekter, men også i store organisasjoner generelt.
      </ul>
      </aside>
    </section>

    <section>
      <img src="img/avhengigheter.jpg">
      <aside class="notes">
        I store organisasjoner er det mange avhengigheter
        <ul>
          <li>mellom leveranseteam
          <li>linjeorganisasjonen
          <li>mellom avdelinger
          <li>til forvaltning
          <li>til forretning
          <li>til ledere
          <li> og mellom IT-systemer
        </ul>
      </aside>
    </section>

    <section>
        <img style="width: 900px;" src="img/gantt.png">
        <aside class="notes">
          Derfor bruker man masse tid på omfattende planlegging, dokumentasjon, løpende koordinering, overleveringer, møter og endringsanmodninger.<br><br>
          Det koster mye tid og krefter og bidrar ikke til å løse de reelle utfordringene.<br><br>
          Effektene av dårlig organisering løses best ved OMORGANISERING, ikke ved mer koordinering og kontroll.
        </aside>
    </section>

    <section>
        <h2>Hva har prosjektledere i verktøykassa?</h2>
        <img src="img/toolbox.png">
        <aside class="notes">
        En av årsakene til at planlegging oppfattes som eneste mulighet for orkestrering av aktiviteter og instanser er at det innenfor prosjektleder-faget ikke finnes noe godt alternativ til 
        <ul>
          <li>omfattende planlegging
          <li>mange roller
          <li>mange aktiviteter
          <li>sjekkpunkter og milepæler.
        <ul>
       </aside>
    </section>

    <section>
        <img style="background: #222; border: 0px; width: 900px;" src="img/prince2_tube_map_v2.3.png">
        <aside class="notes">
          Prince2 har mange verktøy for prosjektledelse, men ikke <b>ett</b> sted er IT-arkitektur beskrevet som et virkemiddel.<br><br>
          Alle virkemidlene handler om prosesser, sjekkpunkter, milepæler, dokumenter, overleveringer, og planer.
        </aside>
    </section>

    <section>
        <img src="img/bekkelund.png" style="background: #222; border: 0px; float: left;">
        <blockquote cite="http://www.bekkelund.net/2014/12/11/livssykluser/" style="float: right;">&ldquo;...<div style="color: #35bdb2; display:inline;">hus og programvare er to forskjellige ting</div>. Huset er konkret og må planlegges før det bygges, fordi det er vanskelig å endre det i etterkant. <div style="color: #35bdb2; display:inline;">Programvare</div>, derimot, er abstrakt og <div style="color: #35bdb2; display:inline;">trenger liten grad av planlegging før det bygges</div>, fordi det er enkelt å endre det i etterkant.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="http://www.bekkelund.net/2014/12/11/livssykluser/"><NAME>, Livssykluser, 2014</a></footer>
        <aside class="notes">
          Det som er fint med software og IT-arkitektur er at det er veldig fleksibelt.<br><br>
          Det er ikke som å bygge hus.<br><br>
          Og endringer i IT-arkitektur vil påvirke organisasjonen.<br><br>
          Det kan til og med brukes for å unngå alle disse avhengighetene som er så vanskelige å planlegge, orkestrere og koordinere.
        </aside>
    </section>

    <section>
      <h2>Men prosjektene er jo Smidig!</h2>
      <aside class="notes">
      Smidig er bra, og smidig skal vi være, men det er ikke nok!
      </aside>
    </section>

    <section>
        <img style="background: #222; border: 0px; width: 800px;" src="img/safe4.png">
        <aside class="notes">
          Etter min mening har det vært et alt for stort fokus på PERSONER OG SAMSPILL innen smidig. De tekniske forutsetningene for å lykkes med Smidig blir helt borte.<br><br>
          Alt fokus blir også med Smidig fokusert rundt å bekjempe avhengigheter med *prosess*.
          Smidig funker derfor bra i småskala, men blir det stort må du se andre steder for å finne ut hvordan det skal skalere.
        </aside>
    </section>

    <section>
        <h2>Vi må kommunisere <u>mindre!</u></h2>
        <img src="img/bezos.jpg" style="float: left;">
        <blockquote cite="http://www.amazon.com/The-Everything-Store-Bezos-Amazon/dp/0316219266" style="float: right;">&ldquo;Communication is a sign of dysfunction... We should be trying to figure out a way for teams to communicate less with each other, not more.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="http://www.amazon.com/The-Everything-Store-Bezos-Amazon/dp/0316219266"><NAME>, CEO i Amazon</a></footer>
        <aside class="notes">
          Vi må derfor redusere behovet for kommunikasjon mellom team.
          Teamene bør være mest mulig autonome.
        </aside>
    </section>

    <section>
      <h2>Autonome team</h2>
      <blockquote>&ldquo;<div style="color: #35bdb2; display:inline;">Autonome team</div> er team som kan <div style="color: #35bdb2; display:inline;">løse alle oppgaver</div> som skal til for å videreutvikle produkter <div style="color: #35bdb2; display:inline;">uten ekstern innblanding</div> eller behov for å henvende seg til utenforstående personer.&rdquo;</blockquote>
      <footer style="font-size: 0.5em;"><a href="https://radar.bekk.no/tech2016/prosess-og-kvalitet/autonome-team">BEKK Radar 2016</a></footer>
      <aside class="notes">
        Autonome team er team som kan løse alle oppgaver som skal til for å videreutvikle tjenester uten ekstern innblanding eller behov for å henvende seg til utenforstående personer.<br><br>
        Får du til fullstendig autonomitet, så vil tjenesteutvikling per team foregå raskest mulig.
      </aside>
    </section>

    <section>
        <h2>All kommunikasjon skal foregå over API-er!</h2>
        <img src="img/bezos.jpg" style="float: left;">
        <blockquote cite="" style="float: right;"> &ldquo;The only communication allowed is via service interface calls over the network.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="https://plus.google.com/+RipRowan/posts/eVeouesvaVX"><NAME>, CEO Amazon, i følge en tidligere ansatt i Amazon</a></footer>
        <aside class="notes">
          Derfor påla <NAME> i 2002 alle i Amazon å <b>kun</b> kommunisere mellom systemer over veldefinerte API-er.
        </aside>
    </section>

    <section>
        <h2>Ellers får du sparken!</h2>
        <img src="img/bezos.jpg" style="float: left;">
        <blockquote cite="https://plus.google.com/+RipRowan/posts/eVeouesvaVX" style="float: right;"> &ldquo;Anyone who doesn’t do this will be fired.
        <br>Thank you; have a nice day!&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="https://plus.google.com/+RipRowan/posts/eVeouesvaVX"><NAME>, CEO Amazon, i følge en tidligere ansatt i Amazon</a></footer>
        <aside class="notes">
          Og han mente det!
        </aside>
    </section>


    <section>
        <img src="img/teams_api.png">
        <footer style="font-size: 0.5em;"><a href="https://www.youtube.com/watch?v=_wnd-eyPoMo">Fra Architecting for Continuous Delivery, <NAME>, 2015</a></footer>
        <aside class="notes">
          Hvorfor gjorde han så det? Hva betyr det?<br><br>
          Smidige team kommuniserer veldig tett internt.<br><br>
          Men med en gang de må synkronisere seg med andre team blir det problemer.<br><br>
          Derfor bør man lage IT-arkitektur på en sånn måte at det å legge til ny funksjonalitet påvirker én tjeneste og ett team.<br><br>
          Data og funksjonalitet implementeres der hvor det i et forretningsperspektiv hører best hjemme.<br><br>
          All kommunikasjon mellom systemer foregår over API-er. Det gjør at hvert team kan kjøre full fart uten avhengigheter til andre team.
        </aside>
    </section>

    <section>
      <h2>Mikrotjenester</h2>
      <img src="img/microservices2.png">
      <footer style="font-size: 0.5em;"><a href="http://martinfowler.com/articles/microservices.html">Microservices, a definition of this new architectural term, <NAME> og <NAME>, 2014</a></footer>
      <aside class="notes">
         Ved å lage mindre systemer organisert rundt forretningsbehov, så vil systemene og teamene dine speile de forretningsbehovene du har<br><br>
         og en endring i <b>ett</b> forretningsbehov vil kun påvirke <b>ett</b> system.
      </aside>
    </section>

    <section>
      <h2>En teknisk løsning på en organisatorisk utfordring</h2>
       <footer style="font-size: 0.5em;">Eksemplet er hentet fra <a href="http://blog.jessitron.com/2016/05/tradeoffs-in-coordination-among-teams.html">"Tradeoffs in Coordination Among Teams"</a> av <NAME></footer>
      <aside class="notes">
        I store organisasjoner må vi derfor se på IT-arkitektur for å bli mer effektive.<br><br>
        Det holder ikke med Smidig.<br><br>
        Smidig skalerer dårlig uten å gjøre noe med de teknologiske forutsetningene.
      </aside>
    </section>

    <section>
        <h2>Et team med et stort potensiale</h2>
        <img src="img/arrow.png">
        <aside class="notes">
        La oss si at vi har ett team på 2-7 folk.<br>
        Den tomme pilen representerer potensialet eller kapasiteten til teamet.
        </aside>
    </section>

    <section>
        <h2>Full fart! &#9786;</h2>
        <img src="img/filled-arrow.png">
        <aside class="notes">
        La oss is at vi skal lage en byggesøknads-applikasjon.<br><br>
        Teamet kjører full fart og bygger en skjemaløsning som lagrer søknader i en database.
        </aside>
    </section>

    <section>
        <h2>Skalering til to team som jobber på samme system.</h2>
        <img src="img/two-arrows-coordinating.png">
        <aside class="notes">
        Etter en stund så trenger de et system for saksbehandlere som skal behandle søknadene så de danner to Smidig-team.<br><br>
        Vi bruker fortsatt samme database og bygger en saksbehandlerapplikasjon på den samme plattformen.<br><br>
        Derfor må de to teamene samarbeide. Flere folk fører til mer kommunikasjonsoverhead.
       </aside>
    </section>

    <section>
        <h2>Vi må skalere mer!</h2>
        <img src="img/four-arrows-coordinating.png">
        <h2>... men fremdriften er dårlig &#9785;</h2>
        <aside class="notes">
        Så skal det integreres mot kartverket, det skal lastes opp tegninger, og det skal skilles mellom bedrifter og privatpersoner.<br><br>
        Nå begynner det å bli et salig rot.<br><br>
        Hvis bedriftsteamet endrer databasen ødelegger det for privat-teamet.<br><br>
        Oppgraderinger av rammeverk og systemer kan ikke gjøres fordi det vil ødelegge for de andre<br><br>
        Konsensus og koordinering begynner å bli uoverkommelig og utviklerne har ikke oversikt over systemet som et hele lenger.<br><br>
       </aside>
    </section>

    <section>
        <h2>Brooks' lov</h2>
        <img src="img/brooks.jpg" style="float: left; height: 400px;">
        <blockquote cite="https://en.wikipedia.org/wiki/Brooks%E2%80%99_law" style="float: right;">&ldquo;Adding manpower to a late</br>software project makes it later.&rdquo;</blockquote>
        <footer style="float: right; font-size: 0.5em;"><a href="https://en.wikipedia.org/wiki/Brooks%E2%80%99_law"><NAME>, The Mythical Man-Month, 1975</a></footer>
        <aside class="notes">
        På grunn av kommunikasjons-overhead.
       </aside>
    </section>

    <section>
        <img src="img/api.jpg">
        <aside class="notes">
        Noe må gjøres så vi splitter opp monolitten i deler med:<br><br>
        <ul>
          <li>Hver sin database og dupliserer data om det er nødvendig.
          <li>Hver sin applikasjon med veldefinerte API-er for kommunikasjon mellom de.
        </ul>
        </aside>
    </section>

    <section>
        <h2>Autonome team med mye ansvar (DevOps)</h2>
        <img src="img/wide-arrows-coordinating.png">
        <aside class="notes">
        Dette er en annen type overhead. Den er teknisk fordi alle teamene må vedlikeholde hvert sitt system.<br><br>
        Derfor er pilene tykkere. Farten er omtrent den samme som før.<br><br>
        Forskjellen er at det skalerer. Vi kan legge til flere team uten at kommunikasjon blir en hindring igjen.<br><br>
        Det er ingen koordinering av releaser og alle kjører på i sitt eget tempo.<br><br>
        </aside>
    </section>

    <section>
        <h2>Ingen vits i å finne opp hjulet på nytt (&ldquo;DevOps&rdquo;-teams)</h2>
        <img src="img/organized-arrows.png">
        <aside class="notes">
        Hvis alle teamene gjør alt forskjellig og bruker helt forskjellige teknologier så forblir pilene tykke.<br><br>
        Det *kan* være mer effektivt å ha egne team som er tjenesteytere til de andre teamene.<br><br>
        For eksempel å lage deployskript, automatisere opprettelse av miljøer, supportere velprøvde databaser osv.<br><br>
        Merk at det er fremdeles separate databaser og separate applikasjoner.
        Dette fungerer bare om infrastruktur-teamene er som kundeservice.
        </aside>
    </section>

    <section>
        <h2>Ikke standardiser teknologi eller lag felleskomponenter!</h2>
        <aside class="notes">
        Merk at teamene må ha frihet til å velge riktig verktøy for jobben.
        Felleskomponenter bør unngås for enhver pris.
        Disse skaper bare trøbbel med bakoverkompatibilitet og krever mye vedlikehold.
        I tillegg vil endringer som er påkrevd av ett system potensielt ødelegge for andre systemer.
       </aside>
    </section>

    <section>
        <h2>NoOps/Serverless</h2>
        <img src="img/cloud-arrows-coordinating.png">
        <aside class="notes">
        NoOps er et konsept hvor du bruker tjenester hos en public cloud leverandør.<br><br>
        Da trenger du ikke å bekymre deg over drift selv. Det er overlatt til verdens beste driftere<br><br>
        Det er naivt å tro at din egen driftsavdeling kan konkurrere med de store public cloud leverandørene.<br><br>
        Og i den verdenen er *alt* API-er så derfor er det veldig lett å bruke disse tjenestene.
        </aside>
    </section>

    <section>
        <h2>Eksempler</h2>
    </section>

    <section>
        <h2>Amazon: A shared nothing infrastructure</h2>
        <img src="img/wide-arrows-coordinating.png">
        <blockquote cite="https://queue.acm.org/detail.cfm?id=1142065"> &ldquo;You build it, you run it&rdquo;</blockquote>
       <footer style="font-size: 0.5em;"><a href="https://queue.acm.org/detail.cfm?id=1142065"><NAME> (CTO i Amazon) </a></footer>
        <aside class="notes">
          Alle team kan peise på i eget tempo.<br><br>
          Ingenting er delt.<br><br>
          Har ganske mye teknisk overhead fordi ingenting er delt.
        </aside>
    </section>

    <section>
        <h2>Spotify: Squads &amp; Tribes</h2>
        <img src="img/organized-arrows.png">
        <ul>
          <li>Squad: mini-startup (unike tjenester)</li>
          <li>Tribe: mini-startup inkubatorer (forretningsområder)</li>
        </ul> 
        <aside class="notes">
        Har vært organisert sånn frem til nå, men er på vei til Google Cloud. Det koster *mye* å drifte sin egen infrastruktur.
        </aside>
    </section>

    <section>
        <h2>Skatt: Infrastruktur som en intern tjeneste</h2>
        <img src="img/organized-arrows.png">
        <aside class="notes">
        Infrastruktur team tilbyr verktøy og infrastruktur som tjenester i en privat sky.<br><br>
        Har i stor grad mikrotjenestearkitektur.<br><br>
        Det er en kraftig forbedring, men det koster mye å hoste sin egen sky, og mye blir standardisert på en sånn måte at friheten til utviklingsteamene ikke er stor nok.<br><br>
        DevOps-teamet blir fort en flaskehals når det er så mange behov. Så her får du også et skaleringsproblem.
        </aside>
    </section>

    <section>
        <h2>FINN.no: We are now removing the Ops teams</h2>
        <h1><img src="img/organized-arrows.png"> &rarr; <img src="img/wide-arrows-coordinating.png"></h1>
        <aside class="notes">
        </aside>
    </section>

    <section>
        <h2>Gov.uk: Cloud first</h2>
        <img src="img/govuk-cloud-arrows-coordinating.png">
        <aside class="notes">
Sky gir fantastiske muligheter for å effektivisere systemutvikling. Gov.uk har egne sky-driftere som legger til rette for utviklingsteam.
        </aside>
    </section>

    <section>
        <h2>Netflix: NoOps</h2>
        <img src="img/netflix-cloud-arrows-coordinating.png">
        <aside class="notes">
 Netflix påstår at de har bare utvilkere og abstraherer bort plattformen. Litt som skatt, men i public cloud hvor innovasjonstakten er ekstrem. Du har ikke sjans til å drifte like effektivt i egen datahall.
        </aside>
    </section>

    <section>
       <img src="img/orkestrering_av_it.png">
       <footer style="font-size: 0.5em;"><a href="http://open.bekk.no/orkestrering-av-it-utvikling-i-store-organisasjoner">http://open.bekk.no/orkestrering-av-it-utvikling-i-store-organisasjoner</a></footer>
       <aside class="notes">
       </aside>
    </section>

    <section>
      <h1>Takk for meg!</h1>
      <img width="252" height="235" src="img/me_bart.png" alt="<NAME>"/>
      <p><a href="https://twitter.com/steinim">@steinim</a></p>
      <p><a href="mailto:<EMAIL>"><EMAIL></a></p>
    </section>

</div>
</div>

    <script src="lib/js/head.min.js"></script>
    <script src="js/reveal.min.js"></script>

    <script>
        // Full list of configuration options available here:
        // https://github.com/hakimel/reveal.js#configuration
{'fraction_non_alphanumeric': 0.1178420803355962, 'fraction_numerical': 0.01267507160738853, 'mean_word_length': 2.9967550027041643, 'pattern_counts': {'":': 0, '<': 1060, '<?xml version=': 0, '>': 1060, 'https://': 26, 'lorem ipsum': 0, 'www.': 14, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4672076', 'n_tokens_mistral': 15969, 'n_tokens_neox': 15075, 'n_words': 4368}