Smidig utvikling muliggjør DataOps

Det er flere måter å være smidig på, men de har alle felles verdier og prinsipper. Imidlertid er grunnideen for smidig utvikling å utføre utviklingen inkrementelt i små iterasjoner, levere ofte og få konstant tilbakemelding for å sikre at du utvikler de riktige tingene. Kommunikasjon og samarbeid er kjernen i smidig utvikling.

Den naturlige veien for DataOps

Vi vil argumentere for at de fleste elementene i DevOps og DataOps bare er en naturlig evolusjon basert på smidig utvikling. Under vil vil gå gjennom hver av de fire kjernepåstandene i det smidige manifestet og forklare hvordan de gjenspeiles i DataOps.

Individer og interaksjoner fremfor prosesser og verktøy

I DataOps er verktøy og prosesser en av hovedbidragsyterne til utviklingen. Imidlertid vil et godt fungerende team bare fungere bra med effektiv kommunikasjon internt og eksternt. Selv de beste prosessene og verktøyene vil ikke hjelpe hvis produktet ikke leverer det som forventes.

Dette får man til ved å tydeliggjøre roller og organisere i tverrfaglige team som kan levere ende-til-ende det som skal til for å levere forretningsverdi. Det høres kanskje vanskelig ut, men for å komme i gang trenger man bare å plassere alle i samme rom og definere mål og oppgaver sammen.

Funksjonelle løsninger fremfor dokumentasjon

Utvikling skal alltid fokusere på å produsere funksjonell programvare over omfattende dokumentasjon. For nye løsninger snakkes det ofte om MVPer - Minimum Viable Product. Det gjelder også dataprodukter. Så kan MVPene eller utvides senere basert på en forretningsmessig prioritering.

I et godt organisert DataOps-team er det også en ‘Ops’-del. Dette betyr at utvikleren innenfor teamet er ansvarlig for produksjonsstøtte eller drift, og bør være i stand til å løse mange av de potensielle problemene som kan oppstå selv. Trolig har hen vært med på å utvikle produktene, og da blir også kodeforbedring, feilsøking og -retting mer effektiv.

Det vil være i utviklernes interesse å utvikle gode nok dataprodukter slik det ikke betyr konstant brannslukking. Det betyr også at dokumentasjonen må være på riktig nivå, eller tilstrekkelig god. Den kan videreutvikles og itereres på, i takt med at behovene for mer presisjon eller forklaring øker.

Samarbeid fremfor kontrakter

Den grunnleggende ideen er at teamet skal tilby resultatet som en tjeneste. Dataeiere, datautviklere, databrukere og IT-infrastruktur jobber sammen mot et felles resultat. Dette samarbeidet er avgjørende for å sikre at dataene blir håndtert på en effektiv, sikker og kvalitetsmessig god måte. Siden vi jobber sammen, der alle kommer med sin kompetanse og bakgrunn, vil ikke kontrakter være særlig relevant.

Respons på endring fremfor følge en plan

I DataOps praksis innebærer respons på endring å utvikle systemer og prosesser som raskt kan tilpasse seg nye datakilder, nye analytiske verktøy, endrede forretningskrav eller nye regulatoriske krav. Gjennom automatisering, kontinuerlig integrasjon og levering, og robust samarbeid, er DataOps designet for å håndtere endring effektivt.

Styring av kvalitet i DataOps

Lean-utvikling og Total Quality Management har over tid påvirket hvordan vi utvikler programvare. Her er det noen nøkkelprinsipper som bør brukes i datautvikling, driftskvalitetsstyring og i kvalitetsstyringen av dataprodukter:

• Som i Lean, bør det være kontinuerlig forbedring og eliminering av sløsing med produktene og prosessene - lag minimumsdataprodukter og ikke lag kode, dataplattformer og løsninger mer komplekse enn det som er nødvendig akkurat nå
• Optimaliseringen bør gjøres for hele prosessen fra design til leveranse, i stedet for bare individuelle deler av prosessen.
• Beslutningenr om optimalisering bør baseres på data og målinger, for hvordan kan man forvente å optimalisere noe uten fakta og forståelse. Dette er et gjentakende problem hvor overvåkning, logging og varsling ikke er tilstrekkelig på plass.