Under huven

Tre lager. Från self-service till infrastruktur.

En IDP som faktiskt fungerar är inte ett verktyg — det är en arkitektur i tre lager. Överst: det utvecklarna ser. I mitten: det plattformen kan göra. Underst: var det körs. Vi levererar alla tre — och kopplar dem till er styrning.

Boka Discovery Workshop

Målarkitektur

Tre lager. En plattform.

AI är acceleratorn. Plattformen är styrningen. Vi levererar hela plattformen — orkestreringslagret först, portalen sedan — med AI-governance, compliance och kostnadskontroll inbyggt. Klicka på varje lager för att se vad som ingår.

Produkt- och utvecklingsteam
Platform interfaces Det utvecklarna ser och interagerar med

Self-service-lagret. Utvecklare ska kunna hitta, skapa och deploya utan att lämna in en biljett. Allt samlat bakom en portal — men portalen är bara skalet.

Developer Portal (IDP)

Tjänstekatalog, scorecards, self-service-åtgärder. Kopplat till riktig orkestrering.

Golden Paths

Fördefinierade vägar för vanliga arbetsflöden. Säkerhet och compliance inbyggt.

API:er & CLI

Automation-first. Inga manuella steg som inte går att scripta.

Dokumentation & search

Levande dokumentation från plattformen — alltid aktuellt, alltid sökbart.

Platform capabilities Orkestreringslagret — vad plattformen kan göra

Det osynliga lagret som avgör om plattformen fungerar. Här sker provisionering, säkerhetsskanning, bygg-automation och observability. Det som de flesta portal-implementationer missar.

Miljöer & infrastruktur

Compute, nätverk, storage, databaser. Standardiserat, versionshanterat, repeterbart.

Identitet & åtkomst

SSO, RBAC, secrets management. Kopplat till Entra ID, Okta eller era befintliga system.

Säkerhetsskanning & policy

SAST, DAST, SCA, container-scanning. Körs automatiskt i varje pipeline.

Bygg, test & delivery

CI/CD med kvalitetsgrindar. Blue-green, canary. Rollback inbyggt.

Observability & FinOps

Loggning, metrics, tracing, alerting. Kostnadsgrindar och budgetägarskap per team.

★ Policy as Code — governance inbyggt i varje capability

Policies definieras som kod och tillämpas automatiskt — inte som manuell granskning, utan som en grind i pipeline.

IT-policy: "All data krypteras" → Azure Policy: deny unencrypted storage
ISMS A.8.24: Säker utveckling → Golden Path: SAST + SCA i varje PR
NIS2 art 21: Leverantörskedja → SCA: deny deploy med kända CVE:er
Kostnadsbudget: 50k/mån/team → Budget alert + deploy-grind
Landing zones Färdiga miljöer med governance inbyggt

En landing zone är inte bara "en subscription i Azure". Det är en komplett, fördefinierad miljö med nätverk, säkerhet, identitet, kostnadsbudgetar och policies — redo att användas.

Platform management

Monitoring, dashboards, kostnadsöversikt för hela plattformen.

Identity & connectivity

VPN, DNS, hub-nätverk, Entra ID. Centrala nätverksresurser.

Produktion

Hård policy: obligatorisk kryptering, begränsade regioner, loggning till SIEM.

Dev / test

Lättare policy, kostnadsbudgetar och säkerhetsbaseline.

Sandbox

Experimentmiljöer. Tidsbegränsade. Automatisk upprensning.

Molnleverantörer & infrastruktur

Azure AWS GCP Sovereign EU On-prem

Kopplat till ISMS · QMS · Riskregister · Intern revision · Operativ modell

Soda Labs differentiator: plattformen lever inte i en isolerad ö

Landing Zones

Infrastruktur som styr sig själv. Oavsett var den körs.

Varje gång ett team behöver en ny miljö — för utveckling, test, staging eller produktion — provisioneras den via en Landing Zone. Nätverkskonfiguration, säkerhetspolicies, kostnadsbudgetar, loggning och åtkomstkontroll är redan på plats. Ingen manuell konfiguration. Inga avvikelser. Inga "det fixar vi sen."

Nätverk

  • —Hub-spoke eller mesh-topology
  • —NSG:er och brandväggsregler
  • —DNS-konfiguration
  • —Peering till centrala resurser
  • —Dataresidenskontroll (EU/sovereign)

Identitet & åtkomst

  • —RBAC med minsta-privilegium
  • —Service principals för automation
  • —Managed identities
  • —Conditional access policies
  • —Break-glass-konton med audit

Säkerhet

  • —Defender / Security Center aktiverat
  • —Vulnerability assessment
  • —Kryptering at-rest och in-transit
  • —Key Vault för hemligheter
  • —Container registry scanning

Kostnad & taggning

  • —Budgetgrindar per subscription
  • —Obligatorisk taggning: team, projekt, miljö
  • —Kostnadsalerter vid tröskel
  • —Automatisk rightsizing-rekommendation
  • —FinOps-rapportering till CFO:s format

Loggning & observability

  • —Centraliserad log analytics
  • —Activity logs till SIEM
  • —Diagnostic settings per resurs
  • —Alerting och anomaly detection
  • —Audit trail för compliance

Policy as Code

  • —Azure Policy / AWS SCP / OPA
  • —Blockerar icke-compliant resurser
  • —Audit-mode för mjuk införning
  • —Policies versionshanterade i Git
  • —Mappade mot ISMS Annex A-kontroller

Policy as Code

Era regler. Som kod. Tillämpade automatiskt.

Policy as Code innebär att organisationens styrningskrav — säkerhetspolicies, kostnadsbudgetar, nätverksregler, compliance-krav — definieras som versionshanterad kod och tillämpas automatiskt i plattformen. Inte som ett dokument i SharePoint. Inte som en manuell checklist. Som en grind som inte går att passera utan att uppfylla kraven.

Preventive

Blockerar innan det sker

Icke-compliant resurser skapas aldrig. Inga virtuella maskiner utan kryptering. Inga storage accounts med public access. Inga resurser utanför EU-regioner.

Azure Policy (deny) · AWS SCP · OPA/Gatekeeper

Detective

Identifierar avvikelser

Flaggar befintliga resurser som inte uppfyller kraven. Databaser utan backup. Resurser utan obligatorisk taggning. Rapporteras automatiskt.

Azure Policy (audit) · AWS Config Rules · Checkov

Corrective

Åtgärdar automatiskt

Aktiverar loggning om det saknas. Lägger till saknad taggning med default-värde. Avvikelser åtgärdas utan manuell intervention.

Azure Policy (deployIfNotExists) · AWS Auto Remediation

Från styrdokument till automatisk grind

IT-policy: "All data ska krypteras at-rest"

→Azure Policy: deny storage accounts without encryption — verifieras i realtid

ISMS Annex A.8.24: "Säker utveckling"

→Golden Path: SAST + SCA körs i varje PR — blockerar vid high/critical

NIS2 artikel 21: "Leverantörskedjesäkerhet"

→SCA-policy: deny deployment med kända CVE:er i dependencies

Kvalitetspolicy ISO 9001: "Processer ska följas"

→Golden Path ÄR processen — avvikelser detekteras automatiskt

Kostnadsbudget: "Max 50k/mån per team"

→Budget alert + deploy-grind vid överskridande

DORA artikel 8: "ICT risk management"

→Riskflöde: policy-överträdelser → riskregister automatiskt

"Policy as Code omvandlar era styrdokument från PDF:er som ingen läser till grindar som ingen kan passera utan att uppfylla kraven. Styrning som lever i koden — inte i en mapp."

Platform Engineering

Plattformen som produkt. Utvecklarna som kunder.

Platform Engineering handlar inte om att bygga verktyg. Det handlar om att bygga en intern produkt — en plattform — med era utvecklare som kunder. Med roadmap, prioritering, adoption-mätning och kontinuerlig förbättring.

Product mindset

Plattformen har en roadmap, en backlog och en Product Manager. Funktioner prioriteras baserat på utvecklarbehov och affärsvärde — inte på teknikchefens favoritverktyg.

Self-service first

Varje åtgärd som idag kräver en biljett ska bli en self-service-åtgärd. Ny miljö? Klick. Ny databas? Klick. Ny pipeline? Golden Path.

Golden Paths — inte gyllene burar

Golden Paths ska vara det snabbaste och enklaste sättet att göra saker — inte det enda. Avvikelse är en signal att pathen behöver förbättras.

Mätbar Developer Experience

Adoption, tid-till-första-deployment, toil-reduktion. Om ni inte mäter vet ni inte om plattformen gör skillnad.

Enabler, inte gatekeeper

Guardrails istället för grindvakter. Automatiserade kontroller istället för manuella godkännanden. Friktion ska minskas, inte flytta.

Rollerna i ett plattformsteam

Head of Platform Engineering
Strategi, roadmap, förankring hos ledning
Platform Product Manager
Prioritering, adoption, DevEx-mätning
Infrastructure Platform Engineer
Landing Zones, IaC, molnarkitektur
DevEx Platform Engineer
Developer portal, Golden Paths, self-service
Security Platform Engineer
Säkerhet i pipeline, Policy as Code
Observability / FinOps Engineer
Loggning, metrics, budget-grindar

De flesta organisationer kan inte rekrytera alla sex roller. Vi levererar plattformen som tjänst — med alla roller inbyggda. Eller vi fyller specifika luckor via fractional-modell.

Prata med oss

Molnagnostiskt

Samma plattform. Oavsett var den körs.

Landing Zones, Golden Paths och Policy as Code ska fungera identiskt oavsett molnleverantör. Byter ni från Azure till AWS — eller lägger till en europeisk sovereign cloud — ska plattformsarkitekturen inte byggas om.

Capability Azure AWS GCP Sovereign / On-prem
Landing Zones Azure Landing Zones (ALZ) AWS Control Tower GCP Landing Zones Terraform + custom
Policy as Code Azure Policy SCP + Config Rules Organization Policies OPA / Gatekeeper
Identitet Entra ID IAM + SSO Cloud Identity Keycloak / AD
Nätverk Hub-spoke VNet Transit Gateway Shared VPC Custom overlay
Secrets Key Vault Secrets Manager Secret Manager HashiCorp Vault
IaC Terraform / Bicep Terraform / CDK Terraform Terraform
Container platform AKS EKS GKE Rancher / OpenShift
Observability Monitor + Log Analytics CloudWatch Cloud Monitoring Grafana + Prometheus
CI/CD Azure DevOps / GitHub CodePipeline / GitHub Cloud Build / GitHub GitLab / Jenkins / Argo

"Molnagnostiskt betyder inte 'fungerar sämre överallt.' Det betyder att arkitekturen är designad så att molnleverantören är en parameter — inte en förutsättning. Ni väljer moln. Plattformen anpassar sig."

Redo att bygga er plattform?

Vi börjar med en Discovery Workshop där vi kartlägger ert systemlandskap, compliance-status och molnstrategi — och designar en plattformsarkitektur anpassad till er verklighet.

Boka Discovery Workshop info@sodalabs.se