8.2 Verktygslandskap: att bygga kontra köpa

Översikt och motivation

Varje organisation som implementerar den här bokens vägledning möter så småningom ett praktiskt infrastrukturbeslut: bygga mätetalsverktyg internt, köpa en kommersiell ingenjörsanalysplattform, eller, vanligast i praktiken, någon kombination av båda. Det här ämnet behandlar det beslutet med samma rigör ämne 5.5 tillämpar på varje annan ingenjörsinvestering: en ärlig kostnads-nytta-analys specifik för er organisations skala, befintliga datakällor, och de specifika mätetalen från den här boken ni faktiskt avser spåra, snarare än ett standardsvar som tillämpas enhetligt oavsett kontext.

Den kommersiella ingenjörsanalysverktygsmarknaden har mognat betydligt, och många plattformar erbjuder nu solid, till stor del automatiserad instrumentering för DORA-mätetalen (del 2), pull-request- och granskningsdata (ämne 2.9), och alltmer, utvecklarupplevelseenkätinfrastruktur (ämne 3.7). Den här mognaden har skiftat kalkylen för många organisationer mot att köpa åtminstone det grundläggande lagret, men den har inte eliminerat bygg-alternativets genuina fördelar för specifika, anpassade behov, särskilt runt den utfallstelemetri ämne 7.4 argumenterar nu är det nödvändiga centret av ett mätetalsprogram, vilket ofta är den minst standardiserade, mest organisationsspecifika kategorin av mätning den här boken täcker.

För stora team har det här beslutet verkliga, löpande budget- och ingenjörskapacitetskonsekvenser. Stora företag behöver ofta integrera mätetalsverktyg över ett genuint heterogent landskap av legacy- och moderna system, vilket formar bygg-kontra-köp-kalkylen betydligt; myndigheter möter ofta upphandlingsbegränsningar och datasuveränitets- eller säkerhetskrav som materiellt påverkar vilka kommersiella alternativ som till och med är genomförbara, ibland lutande beslutet mot att bygga eller mot specifika, granskade leverantörer oavsett vad en ren kostnads-nytta-analys ensam skulle föreslå.

Nyckelprinciper

Det här är sällan ett allt-eller-inget-beslut. De flesta mogna mätetalsprogram kombinerar köpta verktyg för väl standardiserade mätetal med byggda verktyg för organisationsspecifik utfallstelemetri.
Köp för väl standardiserade, brett behövda mätetal; bygg för genuint organisationsspecifika sådana. DORA-mätetal och pull-request-analys är varuterritorium; er specifika affärsutfallskorrelation (ämne 5.3) är vanligtvis inte det.
Dataägarskap och portabilitet spelar lika mycket roll som funktionsjämförelse. Ett verktyg som låser in er mätetalsdata är en varaktig risk, inte bara en olägenhet.
Integrationskostnad underskattas ofta i en bygg-kontra-köp-analys, för båda alternativen.
Upphandlings-, säkerhets-, och datasuveränitetsbegränsningar kan överrida en ren kostnads-nytta-beräkning, särskilt för myndigheter.

Rekommendationer

Köp för varulagret: DORA-, gransknings-, och enkätinfrastruktur

För mätetalsfamiljer med mogna, brett tillgängliga kommersiella verktyg, DORA-mätetalsinstrumentering (del 2), pull-request- och kodgranskningsanalys (ämne 2.9), och utvecklarupplevelseenkätplattformar (ämne 3.7), är att köpa vanligtvis det bättre ekonomiska valet för de flesta organisationer under en viss skala, eftersom att bygga motsvarande infrastruktur duplicerar ingenjörsinsats många leverantörer redan har investerat tungt i, med begränsad genuin differentiering tillgänglig från att bygga er egen version.

Bygg för genuint organisationsspecifik utfallstelemetri

För utfallsmätetalen ämne 7.4 argumenterar borde vara er mätetalsprograms tyngdpunkt, affärsutfallskorrelation (ämne 5.3), funktionsadoption knuten till er specifika produkt (ämne 5.2), enhetsekonomi knuten till er specifika kostnadsstruktur (ämne 5.4), är kommersiella verktyg mycket mindre standardiserade och kan ofta inte fånga er organisations specifika affärslogik och datamodell utan omfattande, dyr anpassning som kan sluta kosta mer än att bygga motsvarande förmåga internt med full kontroll över resultatet.

Utvärdera dataägarskap och portabilitet innan ni åtar er till en leverantör

Innan ni signerar ett kommersiellt kontrakt, bekräfta att ni kan exportera er fulla historiska mätetalsdata i ett användbart, standardiserat format, och förstå vad som händer med den datan och dess historik om ni byter leverantör eller avslutar tjänsten. Ett leverantörsförhållande som blir svårt att lämna på grund av datainlåsning är en varaktig organisatorisk risk, inte bara en olägenhet, och den här utvärderingen förtjänar samma allvar som varje annat betydande, flerårigt infrastrukturåtagande.

Budgetera realistiskt för integrationskostnad på båda sidor av beslutet

Vare sig ni bygger eller köper, underskattas integrationskostnad, att koppla verktyget till er faktiska versionskontroll, CI/CD, incidentspårning, och affärssystem, ofta i den initiala planeringen för endera vägen. Budgetera explicit för den här integrationsinsatsen som en distinkt, betydande post i er bygg-kontra-köp-analys, snarare än att anta att ett kommersiellt verktyg kommer fungera ur lådan med minimal uppsättning, eller att en hemmaodlad lösnings integrationskostnad är ett mindre tillägg till dess utvecklingskostnad.

Redovisa upphandlings-, säkerhets-, och suveränitetsbegränsningar explicit och tidigt

För myndigheter och reglerade stora företag kan datasuveränitetskrav, säkerhetscertifieringsbehov, och upphandlingsprocesser materiellt begränsa eller eliminera vissa kommersiella alternativ oavsett deras funktionskvalitet, ibland lutande beslutet mot att bygga eller mot en mindre uppsättning specifikt granskade leverantörer. Identifiera de här begränsningarna explicit och tidigt i utvärderingsprocessen, snarare än att upptäcka dem bara efter betydande utvärderingsinsats redan har gått in i ett alternativ som visar sig vara ogenomförbart för orsaker orelaterade till dess faktiska förmåga.

Avvägningar: fördelar och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
Köp kommersiella verktyg	Snabbt att driftsätta, moget funktionsutbud, leverantörsunderhållet	Mindre anpassningsbart för organisationsspecifika utfallsmätetal; potentiell inlåsning
Bygg interna verktyg	Fullt anpassat, full dataägarskap och kontroll	Betydande, löpande ingenjörsinvestering; duplicerar insats för varumätetal
Hybrid: köp varulagret, bygg utfallslagret	Balanserar kostnadseffektivitet med genuin anpassning där det spelar mest roll	Kräver integrationsarbete för att koppla köpta och byggda komponenter sammanhängande
Köp allt, inklusive utfallstelemetri, via omfattande leverantörsanpassning	Enda leverantörsförhållande, potentiellt enklare upphandling	Kan bli lika dyrt som att bygga, med mindre slutlig kontroll över resultatet

Den centrala spänningen är anpassningsbehov kontra utvecklingskostnad. Mätetalen som mest gynnas av anpassning, utfallstelemetri knuten specifikt till er verksamhet, är också de dyraste att bygga väl; mätetalen som är billigast att köpa, DORA- och granskningsanalys, är också de där genuin anpassning spelar minst roll. Lös spänningen genom att matcha beslutet till det här mönstret direkt: köp där standardisering tjänar er väl, bygg där er specifika kontext genuint kräver det, och budgetera integrationskostnad realistiskt på båda sidor av den uppdelningen.

Frågor att diskutera med ditt team

För varje mätetalsfamilj den här boken täcker, skulle vi genuint gynnas av anpassning, eller skulle ett standardiserat kommersiellt verktyg tjäna oss lika väl? Gå igenom del 2 till 6 explicit och sortera varje mätetalsfamilj i en köp- eller bygg-kolumn baserat på det här specifika testet.
Har vi utvärderat vår nuvarande eller tilltänkta leverantörs dataexport- och portabilitetsalternativ, eller antar vi att vi lätt skulle kunna lämna om vi behövde? Kontrollera det här direkt snarare än att anta; datainlåsning upptäcks ofta bara när en organisation faktiskt försöker byta.
Redovisade vår ursprungliga bygg-kontra-köp-analys realistiskt integrationskostnad, eller fokuserade den primärt på licensavgifter kontra utvecklingstimmar? Återbesök ett nyligt verktygsbeslut och kontrollera om integrationskostnad genuint uppskattades eller betydligt underskattades.
Möter vi upphandlings-, säkerhets-, eller datasuveränitetsbegränsningar som skulle eliminera vissa kommersiella alternativ oavsett deras funktionskvalitet? Identifiera de här begränsningarna explicit före, inte efter, att investera betydande utvärderingsinsats i alternativ som kan visa sig vara ogenomförbara.
Är vårt nuvarande verktygslandskap en medveten hybrid, matchande bygg och köp till där var och en är vettig, eller ackumulerades det genom ad hoc, individuellt rimliga beslut över tid? Var ärliga om vilket mönster som faktiskt beskriver er nuvarande situation.
Vad skulle det kosta oss, i insats och risk, att byta vår nuvarande mätetalsverktygsleverantör idag om vi behövde? Den här konkreta frågan testar er faktiska nuvarande exponering för inlåsningsrisk, bortom vad leverantörens kontraktsvillkor nominellt lovar.

Sektorperspektiv

Startup. Köp varuverktyg som standard på den här skalan; att bygga anpassad mätetalsinfrastruktur är sällan en god användning av knapp tidig ingenjörskapacitet när mogna, billiga kommersiella alternativ existerar för DORA- och granskningsmätetal specifikt. Reservera varje byggansträngning för det enskilda utfallsmätetalet (ämne 5.3) som mest direkt reflekterar er produkts kärnvärde.

Litet företag. De flesta kommersiella verktygsalternativ skalar ner rimligt väl och är prissatta åtkomligt för mindre organisationer; att köpa varulagret är nästan alltid rätt val, och att bygga något anpassat är sällan motiverat innan er organisation har växt betydligt och utvecklat genuint specifika behov.

Stort företag. Hybridtillvägagångssättet det här ämnet rekommenderar förtjänar sin komplexitet här: köp varulagret i skala (ofta med meningsfull förhandlingskraft för gynnsamma villkor), och investera medvetet i att bygga det organisationsspecifika utfallstelemetrilagret, eftersom er affärslogik och datamodellkomplexitet på den här skalan vanligtvis överstiger vad generiska kommersiella verktyg kan tillgodose utan omfattande, dyr anpassning.

Myndighet. Upphandlingsprocesser, säkerhetscertifieringskrav, och datasuveränitetsbegränsningar dominerar ofta det här beslutet mer än ren funktions- eller kostnadsjämförelse skulle antyda. Engagera upphandlings- och säkerhetsintressenter tidigt i utvärderingsprocessen, och var beredda på att byggalternativet är genuint mer attraktivt här än i ett jämförbart privat-sektor-sammanhang, specifikt på grund av de här begränsningarna snarare än eftersom att bygga inherent är bättre.

Exempel

Stort företag. Ett mjukvarubolag försökte initialt bygga en helt anpassad mätetalsplattform som täckte varje mätetalsfamilj från del 2 till del 6, en flerårig insats som konsumerade betydande ingenjörskapacitet och fortfarande låg efter mogna kommersiella erbjudanden för de standardiserade DORA- och granskningsmätetalen specifikt. En reviderad strategi antog en kommersiell plattform för de här varumätetalen, frigörande det interna plattformsteamet att fokusera uteslutande på att bygga affärsutfallskorrelationen och enhetsekonomitelemetrin (ämnen 5.3, 5.4) genuint specifik för företagets affärsmodell, vilket inget kommersiellt verktyg kunde ha tillhandahållit ur lådan. Det här hybridtillvägagångssättet levererade ett mer komplett, mer genuint användbart mätetalsprogram inom ett enda år än allt-bygg-strategin hade uppnått efter två.

Myndighet. En federal myndighets initiala utvärdering av kommersiella ingenjörsanalysplattformar fann att ingen av de tillgängliga leverantörerna kunde möta myndighetens datasuveränitetskrav, som mandaterade att all ingenjörsmätetalsdata förblir inom specifika, certifierade myndighetsdatacenter. Snarare än att överge köpalternativet helt identifierade myndigheten en mindre delmängd av leverantörer som erbjöd myndighetscertifierade, suverän-moln-driftsättningsalternativ, till en blygsam kostnadspremie över standard kommersiell prissättning, och lyckades driftsätta ett hybridprogram: köpta verktyg för varumätetalslagret inom den krävda suveränitetsgränsen, och byggda interna verktyg för myndighetens specifika medborgarutfallstelemetribehov, som ingen tillgänglig kommersiell leverantör adresserade oavsett suveränitetsöverväganden.

Verksamhetsnytta: motiv, ROI och TCO

Avkastningen på en medveten, hybrid bygg-kontra-köp-strategi är att undvika båda felmönstren det här ämnets exempel illustrerar: den slösade, fleråriga ingenjörsinvesteringen av att bygga varuförmåga som redan existerar billigt på marknaden, och frustrationen och den eventuella anpassningskostnaden av att tvinga ett genuint organisationsspecifikt behov in i ett dåligt passande kommersiellt verktyg. Stora-företag-exemplet ovan visar det här konkret: hybridtillvägagångssättet levererade mer genuint värde på ett år än allt-bygg-strategin hade på två.

Den totala ägandekostnaden för endera vägen inkluderar integrationskostnad, ofta underskattad, och, för köpta verktyg specifikt, den löpande riskkostnaden av potentiell leverantörsinlåsning om inte dataportabilitet bekräftas och skyddas kontraktuellt i förväg. Att budgetera för båda de här realistiskt, snarare än att fokusera smalt på licensavgifter eller utvecklingstimmar ensamt, producerar en mycket mer korrekt total kostnadsbild för endera alternativet.

Antimönster och fallgropar

Att bygga anpassade verktyg för väl standardiserade, varumätetal: duplicerar ingenjörsinsats många leverantörer redan har investerat tungt i.
Att köpa kommersiella verktyg för genuint organisationsspecifik utfallstelemetri utan att kontrollera passform först: riskerar dyr, dåligt passande anpassning eller ett ouppfyllt behov.
Ingen utvärdering av dataexport och portabilitet innan ni åtar er till en leverantör: riskerar varaktig, dyr inlåsning upptäckt bara när ni försöker lämna.
Att underskatta integrationskostnad på endera sidan av beslutet: producerar en felaktig total kostnadsjämförelse och orealistiska tidslinjer.
Att ignorera upphandlings-, säkerhets-, eller suveränitetsbegränsningar tills sent i utvärderingsprocessen: slösar utvärderingsinsats på alternativ som visar sig vara ogenomförbara för orsaker orelaterade till förmåga.
Att behandla det här som ett enda, allt-eller-inget-beslut: missar hybridtillvägagångssättet som bäst matchar de flesta organisationers faktiska, blandade behov.

Mognadsmodell

Nivå 1, Initiera: Verktygsbeslut fattas ad hoc, utan medveten bygg-kontra-köp-analys eller övervägande av dataportabilitet.
Nivå 2, Utveckla: Viss analys sker, men integrationskostnad underskattas rutinmässigt och hybridtillvägagångssättet övervägs inte medvetet.
Nivå 3, Standardisera: En medveten, hybrid bygg-kontra-köp-strategi matchar varumätetal till köpta verktyg och organisationsspecifik utfallstelemetri till byggda verktyg, konsekvent.
Nivå 4, Hantera: Dataportabilitet bekräftas och skyddas kontraktuellt för alla köpta verktyg, och upphandlings-, säkerhets-, och suveränitetsbegränsningar redovisas explicit och tidigt.
Nivå 5, Orkestrera: Organisationens verktygslandskap reflekterar en mogen, medveten hybridstrategi, regelbundet granskad när kommersiella erbjudanden och organisatoriska behov utvecklas, med demonstrerat värde från både de köpta och byggda komponenterna.

Diskussionsidéer

Vilket av våra nuvarande mätetal skulle gynnas mest av anpassning vi för närvarande inte får?
Har vi bekräftat att vi kunde exportera vår fulla historiska mätetalsdata om vi behövde byta leverantör?
Redovisade vårt senaste verktygsbeslut realistiskt integrationskostnad?
Vilken upphandlings-, säkerhets-, eller suveränitetsbegränsning kan vi underskatta?
Hur skulle en medveten hybridstrategi se ut för vår specifika mätetalsuppsättning?

Viktiga slutsatser

Det här är sällan allt-eller-inget; de flesta mogna program kombinerar köpta verktyg för varumätetal med byggda verktyg för organisationsspecifik utfallstelemetri.
Köp för standardiserade mätetal (DORA, granskningsanalys, enkätinfrastruktur); bygg för genuint organisationsspecifik utfallsmätning.
Utvärdera dataägarskap och portabilitet innan ni åtar er till en leverantör; inlåsning är en varaktig risk, inte bara en olägenhet.
Budgetera realistiskt för integrationskostnad på båda sidor av beslutet; den underskattas ofta.
Upphandlings-, säkerhets-, och suveränitetsbegränsningar kan överrida en ren kostnads-nytta-beräkning, särskilt för myndigheter.

Källor och vidare läsning

Accelerate: The Science of Lean Software and DevOps, av Nicole Forsgren, Jez Humble, och Gene Kim (mätetalsfamiljerna det här ämnets bygg-kontra-köp-analys tillämpas på).
Cloud FinOps, av J.R. Storment och Mike Fuller (kostnadsanalysprinciper tillämpliga på verktygsinvesteringsbeslut).
FinOps Foundations FinOps-ramverk, finops.org (praktikervägledning om att utvärdera och hantera moln- och SaaS-verktygskostnader).
U.S. Federal Risk and Authorization Management Program (FedRAMP)-dokumentation: auktoritativ vägledning om myndighetsmolnverktygssäkerhet och suveränitetskrav.