Community på Sveriges dataportal

Bra seminarium om "Affärsmodeller och leverantörsaspekter kopplat till open source" idag. Och bra diskussioner. Tack för det!

Jag tror att inspelningen kommer landa bra hos flera hos oss.

Jag tänker - helt allmänt - att en stor orsak till lågt nyttjande av OSS är okunskap och att man som upphandlare förväntas vara den med koll på läget. Och den förväntan gör det bara svårare att säga att man inte vet eller hade koll på alternativa lösningar/angreppssätt.

Vi intalar oss att våra egna behov är helt unika och att vi behöver en unik lösning (vilket resulterar i anbud från den leverantör som bäst säljer in att de kan lösa dessa unika behov - vilket de självklart kommer att säga så övertygande som de bara kan).
Det vi behöver hjälp med är att se att våra behov ofta är ganska allmänna och att det finns generiska OSS-projekt som kan lösa dem. Och som konstaterades under seminariet så är några av de mest långlivade och framgångsrika OSS-projekten just de som löser mer generiska behov (OS, CMS, wiki, programmeringsspråk, containerplattform etc).

Men det är sällan ett enskilt OSS-projekt som löser behovet helt och fullt. Här behövs stödet från leverantörer och communityt att se möjliga integrationer mellan olika OSS-projekt (säg, en lösning för åtkomstkontroll - som sällan inkluderas out of the box).

offentligkod.se (som jag tidigare sett men inte riktigt tagit fasta på) är en superbra del i detta. Väldigt användbar för oss som redan är bekväma i termerna och OSS-communityt, tänker jag.

Vad jag letar efter är nog olika modeller för öppen, prestigelös, säljfri dialog om de lokala behoven och hjälp att se beröringspunkter med mer generiska behov i andra organisationer. Först därefter kan man vara redo att ta till sig tips om vilka OSS-projekt som utvecklats för att tillfredsställa dem behoven.
Det kan ju som bekant vara läskigt att ställa "dumma frågor" så här öppet på nätet och t.o.m. i en chatt under ett onlineseminarium. Allt på nätet är ju för evigt!

Så... jag vet inte om jag frågar efter ett anonymt reddit.com för offentlig sektor, men det kanske är just det jag gör...

Mitt första inlägg här och jag vill höra mig för om hur det tänks och tycks kring DevOps och DevSecOps?

Jag har följt rörelsen under ett antal år som serverdriftare och utvecklare och har väl en del tankar och åsikter.

Några formuleringar om DevOps och DevSecOps:
Cloud Native Computing Foundation:
"En metodik där team tillsammans äger hela processen från systemutveckling till drift i produktion, därav namnet DevOps. . . . DevOps kräver att utvecklare och drifttekniker fokuserar på mindre komponenter (inte större funktioner) vilket leder till mindre överlämningar (en vanlig felkälla)."

Google Cloud:
“En organisatorisk och kulturell rörelse som syftar att öka takten på mjukvaruleveranser, förbättra tillgängligheten och pålitligheten för tjänster och att bygga ett delat ägarskap emellan intressenter.”

Department of Defense:
"DevSecOps är en samling aktiviteter och förmågor inom systemutveckling som kombinerar utveckling, säkerhet och IT-drift med syftet att göra leveranser säkrare och att korta ned utvecklingsprojektens livscykler. Ny funktionalitet, buggrättningar, säkerhets- och andra uppdateringar ska kunna ske oftare och på ett mer automatiserat sätt. Säkerhet appliceras i alla faser av utvecklingsprojekten."

DevOps är ju inget som ersätter Lean och Agile, men delar av det kan (potentiellt) hjälpa oss att jobba enligt Lean- och Agile-principer.

Den årliga State of DevOps Report som gjorts sedan 2014 menar att de bästa måtten för en organisations utvecklingskapacitet är:

1. Ledtid till release (från incheckad källkod till driftsättning)
2. Hur ofta driftsätter vi nya releaser
3. Tid det tar att återställa en tjänst (MTTR - Mean Time To Restore)
4. Hur ofta orsakar en förändring/release problem

Och det låter väl i alla fall sunt?

Jag läste boken Accelerate förra hösten (från initiativtagarna bakom rapporten) och skrev ner några meningar...

Några dåliga sätt att mäta utvecklingskapacitet i organisationer:

• Vad man använder för teknik. Det spelar en viktig roll men kultur och processer är viktigare föga förvånande, sedan kan verktyg hjälpa till i en kulturförflyttning

• Om man har en CAB-funktion. Det visade sig t.o.m. att många org som förlitade sig på mer flexibla processer som parprogrammering eller peer review ofta var bättre både på att leverera OCH tillgänglighet och stabilitet i drift

• Att mäta antal rader kod. Föga förvånande är det ett ruskigt dåligt mått. En lösning med 10 rader kod är - givetvis - ofta att föredra än samma lösning med 1000 rader kod (om den korta lösningen samtidigt är läsbar och inte för komprimerad). Det bästa är förstås om vi kan lösa ett problem helt utan kod eller genom att ta bort kod! Vem älskar inte att få radera kod ibland?

• Snabbaste leveranserna. Undvik att fokusera så mycket på det. Det kan leda till att team nedprioriterar samarbete med andra team för att det tar tid från kodknackning och leverans.

Undvik att belöna utvecklare för mängden mjukvara som levereras och att belöna driftteam för stabilitet. Det leder gärna till att utvecklare "kastar kod" på drift och drift sätter upp plågsamma processer för att förhindra förändring.
Vad ger det att ha en hög utvecklingskapacitet då? God förmåga att ta fram och bygga nya lösningar, anpassa sig till förändring, leverera värde till användarna, osv.

Man kom fram till att mått på utvecklingskapacitet bör fokusera på två nyckelaspekter:

• Maximal verksamhetsnytta
• Goda resultat, inte hur mycket det jobbas.

En bör inte uppmuntra att maximera mängden utfört arbete om det ändå inte hjälper organisationens mål (vad sa ni?! )
Därav är genuin förståelse för vision och mål så himla viktigt!

Något som inte är med bland dem måtten är tiden det tar att identifiera problem och att designa/ta fram potentiella lösningar. De kom fram till att det var många variabler i denna fas så att det var svårt att följa metodiskt (inte att det är mindre viktigt). Det är hög osäkerhet på estimat och resultat.
Det får bli en annan tråd en annan dag...

Hur ser ni på DevOps? Anammar ni denna lära? Tycker ni mest att det är ett nytt modeord på vad ni redan gjort i 3000 år? (vilken sorts vampyr är du?!)
Låter det som namnet på en hel massa produkter som leverantörer försökt sälja in för att lösa alla era problem?
Personligen tycker jag nog att det är på tok för mycket brus kontra signal. Men känner ändå att det finns mycket bra stoff här som jag gärna ställer mig bakom och drar nytta av. Som sagt, intressant att höra era tankar!

@Maria_Dalhage Kul och bra initiativ @lfvjimisola!

Jag kan absolut tänka mig att prata kring frågeställningar hos en organisation som tar sina första steg mot DevOps. Vi står inför att utforma uppdrag kring DevOps-etablering och är mitt i en omorganisation som formellt startas 2023. Jag ska höra runt lite här om vi kan sätta ihop något gemensamt. Prel.boka!

Vi sitter idag med ett växande Excel-dokument för de krav som används vid upphandling. Vi har under en tid pratat om att API:fiera den. Jag handledde även ett projekt med en LIA-student för att bygga en prototyp med C#/dotnet core API. Vår kära student gjorde ett fantastiskt jobb men vi var inte riktigt framme i våra egna tankar i tid till LIA-perioden.

Nu är det hög tid att inspireras av er som gjort en liknande resa. Jag har ju svårt att tro att vi har jättemånga krav i vår egen lista som är helt unika för oss. Kanske någon enstaka punkt.

Jag har sett Umeås öppna dataportal. Och har sett någon diskussion om wikidata här på forumet men hade lite svårt att relatera det till vårt behov.

Var börjar vi? Utveckla ett eget REST API, nyttja något populärt ändamålsenligt projekt, nyttja en färdig produkt (SaaS, egen drift)?

@Nina_Berlin Jo men det finns en hel massa best practice och tekniska förmågor som brukar förknippas med DevOps som jag tror på. Versionshantering av allt: kod, konfiguration, dokumentation, infra som kod m.m. Kontinuerlig integration (trunk based, med testautomation), kontinuerliga leveranser i pipelines som är förståeliga för både drift och utv (oavsett hur du bygger upp det tekniskt).

I slutändan vill vi leverera värde och vi vill att utvecklare/designers/UX får möjlighet att fokusera på affärslogik/användbara gränssnitt och att göra det iterativt med massor av actionable feedback från både driftsystem och användare (med mycket kontext). Sen behöver vi kunna byta kurs och pivotera vid nya insikter. Om vi gör det bäst i någon form av low code plattform, varför inte! Men jag tror mer på en mix av REST API:er uppepå plattformar som abstraherar underliggande infra (tänk serverless, även om begreppet används rätt slarvigt och kanske bara kan realiseras mha en ganska komplex Kubernetes-plattform om du behöver köra in prem, likt som många av oss ju måste).

Containers i sig är nyttigt för utvecklare för att få mer empati och förståelse för drift, med fördelar som att slippa "works on my computer" osv. Jag är själv rätt djupt insatt i Kubernetes och tycker att det har varit fantastiskt värdefullt att lära sig - både för att lära sig hur big tech & friends gör och att se hur folk mycket smartare än mig och med en helt annan skala än jag kanske någonsin kommer att vara i närheten av löser en hel del svåra problem. Och jag uppskattar verkligen alla barriärer som k8s tar bort när man väl kommit över inlärningströskeln. Så, om man inte kastar sig in i k8s och micro services för egen del, lär dig iaf vad det handlar om. Det är ett svindlande lyckat OSS projekt om inte annat! Även ekosystemet runt.

Hm.. stannar där för ikväll
Blir svårt att hålla sig inom ämnet Arbetssätt här

Intressanta länkar och intressant att höra om era erfarenheter!

Förra hösten letade jag efter strukturerad dokumentation kring detta (mycket brus och svårt att pejla in signal med allt säljsnack om DevOps-produkter!). Jag hittade till slut Fundamentals Playbook för DevSecOps från Department of Defense.

Och deras DevSecOps Reference Design.

Så under en tid har jag översatt den senare (så gott jag kunnat) och lagt in den i ett exceldokument för att börja prata om det här med en större förståelse för helheten. Och för att kunna se kopplingar mellan en given aktivitet (ex versionshantering av källkod) till ett lämpligt verktyg (git) och hitta en realistisk väg framåt för en organisation som vill anamma arbetssättet. Excel har väl inte riktigt visat sig vara det roligaste formatet, varken att jobba i eller som diskussionsunderlag. Och inte optimalt för ev publicering och samarbete/diskussion externt. Så jag bestämde mig för att knacka ner innehållet i webbformat istället. Initialt mha dokumentationsgeneratorn mkdocs (men jag är inte övertygad än om att jag gillar verktyget).
Jag har valt att kalla resultatet för DevOpsGuiden.

Först och främst är jag bara väldigt tacksam att höra er tankar om formatet och innehållet och om det finns intresse att tillsammans ta det här vidare i det öppna. Jag känner att jag uppnått mitt första mål som var att lära mig om hur DevOps/DevSecOps bedrivs inom en offentlig verksamhet där detta är livsviktigt (bokstavligen). Och det har hjälpt mig med det interna arbetet med att forma rutiner och se oss om efter nödvändiga verktyg. Jag tänker att detta eller något liknande behöver underhållas och säkert kan ta nya former och uppfylla syften som jag inte tänkt på.

Jag tänker, pragmatiskt, att en konkret koppling till faktiska verktyg och varför man behöver dem är det som verkligen skulle vara värt att jobba vidare med. Företrädelsevis med tips på öppen källkodsmjukvara.

Vill bara säga att det är himla kul att få chansen att vara med i ett större sammanhang, att bidra till den digitala arenan, för ett så viktigt syfte. Fantastiskt! Ser fram emot att engagera mig och bidra mer!

@Nina_Berlin
Intressant och inte förvånad att höra utmaningarna kring PM3

@Maria_Dalhage Tror ni tänker helt rätt med öppna forum och med oinspelad tid under seminarier. Jag försöker själv förstå bättre varför frågor som känns självklara för mig inte ställs i god tid. Varför öppen källkod öht inte ens tas med som byggkloss.

Att fånga in frågor innan seminarier/workshops tror jag på. Ett sätt att fånga upp en och besvara allmänna frågor.

Jag har sett att vissa molnleverantörer börjar prata om kurerad open source (testad, kvalitetssäkrad, uppdaterad) och de har numera app stores som kan köras on prem (eller i molnet givetvis). Hur bra det funkar i praktiken kan jag inte svara på men jag tror att den här modellen kommer att bli populär. Snabbt och enkelt att direktupphandla och testa.

Och i den andra änden det här behovet av att lyfta blicken och få utifrånperspektivet, att få hjälp att se vilka utmaningar som vi delar med många andra org.

@Maria_Dalhage
Har inte läst allt här än men tänkte be dig ändra i texten till David, inte Anders Berglund. Jag är visserligen också musikintresserad så det var en glad överraskning att se namnet.

@jonass Hmm, nosad.se/tips parsar markdown från en wikisida på Gitlab? Ursäkta om jag är helt ute och cyklar...

@tove trevligt! Gillar formatet. Jag vill utveckla DevOpsGuiden mer åt det hållet. Verktygslåda > Uppslagsverk. Alltså mer verktygslåda än uppslagsverk.

@Maria_Dalhage

skapa en sida på NOSAD som heter Exempelkrav.

Nu hänger jag inte med, har sett att man kan begära behörighet att editera vissa sidor där men skapa egna sidor, hur och var? Har du något exempel?

Har uppdaterat texten på startsidan efter diskussion med @lfvjimisola och @Maria_Dalhage igår. Många bra synpunkter. Ska även byta ut bilden till den vanliga oändlighetsbilden som vi förknippar med DevOps och hålla min interna "pedagogik" för mig själv. Sedan vill jag utvidga första sidan åt att vara en mer allomfattande introduktion till DevOps-rörelsen. Så att man inte får en felaktig uppfattning att "grejen" med DevOps är alla verktyg. Den delen är viktig men det ska inte ligga längst fram på en sida som kallar sig "DevOps-guide". Den delen kanske borde ha rubriken referensarkitektur eller liknande.

@Nina_Berlin
Jag har en del jobb innan det kan bli dags för publicering men jag tänkte ändå flagga för att en trasig länk på

Den här länken:
"I Sverige har vi valt att förregistrera alla offentliga aktörer, man kan enkelt kolla om man är
förregistrerad på registrera"

Tänkte se om jag kan få lite handledning i att sätta en RDF-struktur enl DCAT-AP-SE för ett exempelkrav från våran kravkatalog.

Ett exempelkrav, enl <Fält>: <Data>
ID: 012
Kravgrupp: Loggning
Rubrik: Loggning av åtkomst
Kravformulering: Loggning ska ske av åtkomst till lösningen
Prioritet: Ska
Bevis: Genom att svara Ja i anbudssvaret

OBS: detta är ett exempel och är inte det kompletta kravet som vi har formulerat det.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:dcterms="http://purl.org/dc/terms/"
	xmlns:vcard="http://www.w3.org/2006/vcard/ns#"
	xmlns:dcat="http://www.w3.org/ns/dcat#"
	xmlns:foaf="http://xmlns.com/foaf/0.1/">
<dcat:Catalog rdf:about="https://example.com/catalog1">
	<dcterms:title xml:lang="sv">Kravkatalog</dcterms:title>
	<dcterms:description xml:lang="sv">Kravkatalog för IT-upphandlingar</dcterms:description>
	<dcterms:publisher rdf:resource="https://example.com/publisher1"/>
	<dcat:dataset rdf:resource="https://example.com/dataset1"/>
	<dcterms:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/"/>
</dcat:Catalog>
<foaf:Agent rdf:about="https://example.com/publisher1">
	<foaf:name>Exempelkatalog</foaf:name>
</foaf:Agent>
<dcat:Dataset rdf:about="https://example.com/dataset1">
	<dcterms:id xml:lang="sv">0012</dcterms:group>
	<dcterms:group xml:lang="sv">Loggning</dcterms:group>
	<dcterms:title xml:lang="sv">Loggning av åtkomst</dcterms:title>
	<dcterms:description xml:lang="sv">Loggning ska ske av åtkomst till lösningen</dcterms:description>
	<dcterms:priority xml:lang="sv">Ska</dcterms:priority>
	<dcterms:proof xml:lang="sv">Genom att svara Ja i anbudssvaret</dcterms:proof>
	<dcterms:publisher rdf:resource="https://example.com/publisher1"/>
	<dcat:distribution rdf:resource="https://example.com/distribution1"/>
	<dcat:contactPoint rdf:resource="https://example.com/contactpoint1"/>
</dcat:Dataset>
<dcat:Distribution rdf:about="https://example.com/distribution1">
	<dcat:accessURL rdf:resource="http://example.com/api"/>
	<dcat:accessService rdf:resource="https://example.com/dataservice1"/>
</dcat:Distribution>
<vcard:Organization rdf:about="https://example.com/contactpoint1">
	<vcard:fn>Exempelorganisation</vcard:fn>
	<vcard:hasEmail rdf:resource="mailto:oppnadata@example.com"/>
</vcard:Organization>
<dcat:DataService rdf:about="https://example.com/dataservice1">
        <dcterms:title xml:lang="sv">Exempel API</dcterms:title>
        <dcat:endpointURL rdf:resource="http://example.com/api"/>
</dcat:DataService>
</rdf:RDF>

Hur ser det ut för nästa krav? Hur nestar jag in kravlistan?

Jag vet ju hur jag skulle gjort med JSON eller YAML. Kan se hur det kontinuerliga arbetet med katalogen kan hämmas av det "omständiga"/pratiga formatet, även om jag förstår syftet.

@Maria-Söderlind
Var bor er masterdata någonstans? Hur ser gränsnittet ut för de som matar in nya krav eller ändrar i kraven? Excel?

@tove

"det var EXAKT denna kravlista jag satt och tittade på när vi diskuterade idag (men hade inte sett denna tråd)."

Jag misstänkte det Inget svar ännu ang hemvist för metadata och hur Umeå matar in detta. Men blir inte förvånad om det är Excel och att man extraherar datan i säg nattliga jobb inför publicering via API, CSV och JSON.

Jag gillar ju mitt YAML-exempel här i tråden men jag är inte de flesta.