Polku 06Oppitunti 1 / 6

Vertaa vastuita ennen tuotteita

Vertaa coding assistantia, sisäistä toimitusalustaa ja ohjelmistotehdasta. Selvitä vaihtoehdon tekemä työ ja organisaatiolle jäävät vastuut.

Perusteet10 minTarkistettu

Julkaisija Näin kirjoitamme

Mitä opit

  • Vertaat vaihtoehtoja samaan vaadittuun lopputulokseen.
  • Erotat työn tekemisen sen seurausten hyväksymisestä.
  • Tunnistat toimintamallin aukot ja päällekkäisyydet.

Vertaa samaa lopputulosta

Prototyypin työkalun ei tarvitse määrätä tuotannon toimintamallia. Ihmiset voivat tutkia ideoita omaan työhönsä sopivilla työkaluilla. Organisaatio tarvitsee silti tuetun tavan suojata, julkaista, ylläpitää ja operoida hyödyllisiä tuloksia.

Coding assistant, sisäinen platform ja ohjelmistotehdas voivat ratkaista ongelman eri osia. Pelkkien palvelumaksujen vertailu ilman rajausta voi johtaa harhaan.

Aloita vaaditusta lopputuloksesta: sisäinen palvelu toimitetaan ja ylläpidetään yrityksen data-, tietoturva- ja luotettavuusvaatimuksilla. Tunnista sitten koko elinkaaren työ. Ota mukaan ensimmäisen onnistuneen demon jälkeinen vastuu.

Kuvitteellinen sopimuspalvelu tarvitsee hyväksytyt vaatimukset, työntekijöiden pääsyn, yksityiset tiedot, tarkastetut julkaisut, häiriötoiminnan ja jatkuvat päivitykset. Endpointin generoiva työkalu käsittelee osan listasta.

Kuvaa kolme mahdollista toimintamallia

Coding assistantia käyttävät kehittäjät toimivat nykyisessä engineering-järjestelmässä. Organisaatio tarjoaa ympäröivät prosessit, integraatiot, platform-kyvykkyydet ja näytön keräyksen. Malli voi sopia kypsät yhteiset palvelut rakentaneelle organisaatiolle.

Itse kootussa toimitusjärjestelmässä organisaatio yhdistää agentit, kontekstin, tarkistukset, deploymentin ja ylläpidon palautteen. Se hallitsee rakennetta ja omistaa myös integraatiotuotteen, tuen sekä päivitykset.

Ostetussa ohjelmistotehtaassa toimittaja tarjoaa laajemman yhdistetyn työnkulun. Varmista todellinen rajaus ja tuetut integraatiot. Organisaatio tarvitsee edelleen tuotepäätökset ja nimenomaisen vastuunjaon.

Nämä ovat vertailumalleja, eivät yleispäteviä tuotekategorioita. Yksittäinen toimittaja tai sisäinen platform voi yhdistää kyvykkyyksiä eri tavoin.

Varmenna reitti prototyypistä toimivaksi palveluksi

Käytä jokaisen vaihtoehdon arviointiin samaa konkreettista tilannetta. Aloita pankkisovelluksen prototyypissä synteettisistä tilitapahtumista ilman tuotanto-oikeuksia. Pyydä tiimiä tai toimittajaa näyttämään seuraavat kyvykkyydet ennen oikeuksien laajentamista:

  1. Arvioi prototyyppi ja tunnista muutoksia tai korvaamista tarvitseva koodi.
  2. Vie sovellus vaadittuun infraan, myös omille cloud-tileille, jos politiikka sitä edellyttää.
  3. Varmenna sovelluksen oikeudet, salaisuuksien käsittely sekä kehityksen ja runtimen tietovirrat.
  4. Tuota näyttö sovellettavia vaatimuksia vasten ja kirjaa julkaisupäätös.
  5. Valvo palvelua, korjaa haavoittuvuuksia, testaa palautuminen ja reagoi häiriöihin.

Koodin siirtäminen omalle tilille on yksi osa työtä. Selvitä, kuka voi hallita ympäristöä ja mihin ulkoisiin palveluihin dataa päätyy. Sovita kontrollit velvoitteisiisi: pelkkä deployment-kohde ei osoita vaatimustenmukaisuutta.

Vertaa Taigan vastuunjakokuvausta omaan karttaasi yhden toimittajan esimerkkinä. Aineisto on tämän sivuston julkaisijan omaa. Varmenna sovellettava sopimus ja konfiguraatio ennen Taigan käyttöönottoa.

Erota tekeminen, tarkistaminen ja päättäminen

Kirjaa jokaiselle tehtävälle tekijä, tarkastaja ja seurausten hyväksyjä. Sama osapuoli voi hoitaa useita rooleja, mutta tyhjä rooli on aukko.

TehtäväVastuunjaon kysymys
VaatimuksetKuka ratkaisee epäselvän liiketoimintasäännön?
TietojenkäsittelyKuka hyväksyy vastaanottajat ja käsittelyehdot?
ToteutusKuka ylläpitää generoitua koodia hyväksynnän jälkeen?
TarkistusKuka varmistaa näytön koskevan todellista julkaisua?
DeploymentKenen identiteetti muuttaa mitä ympäristöä?
YlläpitoKuka reagoi palvelun häiriöön?
Platform-päivityksetKuka mukauttaa integraatiot riippuvuuksien muuttuessa?

Myös cloud-palveluissa vastuu jakautuu toimittajan ja asiakkaan välille. Tarkka jako riippuu palvelusta. Pyydä täsmällinen kuvaus sen sijaan, että olettaisit kaikkien hallittujen tuotteiden rajat samoiksi. AWS:n vastuunjako.

Etsi aukot ja päällekkäinen työ

Toimittaja saattaa generoida pipelinen, vaikka platform-tiimi ylläpitää hyväksyttyä deployment-reittiä. Päätä, käyttääkö toimittaja sitä. Kaksi erillistä pipelinea voi synnyttää ristiriitaisia kontrolleja ja turhaa kustannusta.

Toimittaja voi myös olettaa asiakkaalla olevan häiriötiimin samalla kun asiakas olettaa ylläpidon sisältyvän palveluun. Ratkaise aukko ennen käyttäjien riippuvuutta.

CNCF:n platform-ohje käsittelee sisäisten ja hallittujen kyvykkyyksien yhdistämistä. Olennaista on käyttäjätarpeen täyttävä kokonaisuus ja selkeä omistajuus. CNCF:n ohje.

Käytä karttaa hankintapäätöksessä

Liitä vastuunjako arviointiin ja selvennä se soveltuvassa sopimuksessa. Hinnoittele organisaatiolle jäävä työ. Laske mukaan komponenttien välisten yhteyksien ylläpito.

Laaja toimittajaratkaisu voi olla arvokas, kun se poistaa integraatiotyötä ja säilyttää näytön elinkaaren läpi. Sisäinen toteutus voi olla perusteltu, jos erityisvaatimukset oikeuttavat jatkuvan omistamisen. Päätä vaaditun lopputuloksen ja tarkistetun rajauksen perusteella.

Sovella käytäntöön

Tee kolme saraketta: coding assistant, itse koottu toimitusjärjestelmä ja ostettu ohjelmistotehdas. Lisää vaatimukset, politiikat, toteutus, tarkistus, julkaisu, ylläpito ja päivitykset. Kirjaa kunkin tekijä, tarkastaja ja hyväksyjä. Merkitse kaikki tuntemattomat vastuut.

Lataa työpohja (Markdown)

Testaa, mitä opit

Toimittaja automatisoi toteutuksen ja testien ajon. Kuka vastaa liiketoimintavaatimuksesta?

Lähteet ja lisälukeminen

Aiheesta Taigan sivuilla