Enhver organisation ved, at den har skygge-IT. Det tal, der konkretiserer problemet: De fleste organisationer kører mere end 1,000 cloud-applikationer, og IT har typisk indsigt i færre end 10 procent af dem. Store virksomheder har i gennemsnit 473 SaaS-applikationer; IT administrerer kun en brøkdel direkte. Firs procent af medarbejderne bruger ikke-godkendte applikationer til at få deres arbejde udført. Tallene er ensartede på tværs af alle undersøgelser, fordi den dynamik, de afspejler, er ensartet: medarbejdere og forretningsenheder anvender værktøjer, der løser umiddelbare problemer hurtigere, end IT-styringsprocesser kan evaluere og godkende dem.
Samtalen om skygge-IT i 2026 er domineret af SaaS-opdagelsesværktøjer, der scanner DNS-logs, analyserer SSO OAuth-tokens, reviderer udgiftsrapporter og fingeraftryksnetværkstrafik for at finde cloud-applikationer, som medarbejdere bruger uden autorisation. Disse værktøjer løser SaaS-laget af problemet, og de løser det rimeligt godt. Hvad de ikke løser, og som intet SaaS-opdagelsesværktøj adresserer, er det andet skygge-IT-problem: de specialbyggede applikationer, udokumenterede batchprogrammer, uformelle datapipelines og ghost-værktøjsprogrammer, der findes i virksomhedsapplikationsporteføljer og aldrig har optrådt i noget aktivstyringssystem, ændringslog eller IT-inventar. Disse er ikke cloud-applikationer, der implementeres af medarbejdere. De er produktionsprogrammer, der kører på mainframes og mellemstore systemer, og som udfører forretningskritiske funktioner, som de organisationer, der ejer dem, ikke fuldt ud kan redegøre for.
De to problemer kræver forskellige tilgange til opdagelse. SaaS-skygge-IT-problemet kræver netværkssynlighed og identitetsintegration. Skygge-IT-problemet på kodeniveau kræver parsing af de faktiske softwareartefakter, kildekode, indlæsningsbiblioteker og JCL-jobstrømme for at opregne, hvilke programmer der findes, og hvad de gør. Denne vejledning dækker begge dele med et specifikt fokus på den anden kategori, som resten af feltet ikke har behandlet.
De to skygge-IT-problemer
Skygge-IT defineres typisk som teknologi, der anvendes i en organisation uden eksplicit IT-godkendelse eller -viden. Denne definition dækker over to fundamentalt forskellige fænomener, der kræver forskellige opdagelsesmetoder og forskellige styringsresponser.
Shadow SaaS og cloud-værktøjer er applikationer og tjenester, der anvendes af medarbejdere eller forretningsenheder uden formel IT-indkøb. Et marketingteam, der bruger et ikke-godkendt AI-skriveværktøj. Et finansteam, der deler regneark via en personlig Dropbox-konto. En udvikler, der bruger en uautoriseret AI-kodningsassistent, der sender proprietær kildekode til en ekstern API. Disse applikationer findes uden for organisationens infrastruktur og kan findes via eksterne signaler: DNS-forespørgsler, OAuth-autorisationer, linjeposter i udgiftsrapporter, fingeraftryk fra netværkstrafik.
Skyggeapplikationssoftware , den kategori som denne artikel fokuserer specifikt på, er specialbyggede programmer og batchprocesser, der blev oprettet i organisationens egen infrastruktur og aldrig korrekt dokumenteret, opgjort eller styret. Et COBOL-program skrevet af en udvikler i finansafdelingen i 1994 til at håndtere en specifik skatteberegningssag. Et RPG-program oprettet af en forretningsanalytiker til at generere EDI-filer til en specifik handelspartner. Et JCL-job, der kører hver månedsslutning og producerer en regulatorisk rapport, som compliance-teamet er afhængig af, bygget af en entreprenør, der forlod organisationen i 2009. Et Java-værktøj skrevet "midlertidigt" under et systemintegrationsprojekt i 2018, der blev en permanent afhængighed uden at nogen besluttede, at det skulle.
Disse programmer er ikke synlige i DNS-logfiler, fordi de kører på intern infrastruktur. De vises ikke i OAuth-godkendelsesposter, fordi de er ældre end OAuth. De er ikke i den officielle programfortegnelse, fordi de aldrig formelt er blevet indsendt til IT-styringsgennemgang. De kan kun findes ved at undersøge selve infrastrukturen, indlæsningsbibliotekerne, kildekodelagrene, jobplanlæggerne og udførelseslogfilerne, der afslører, hvilken software der rent faktisk kører i miljøet.
Grunden til, at dette er vigtigt ud over fuldstændigheden af lagerbeholdningen: 74 procent af organisationer har oplevet sikkerhedshændelser på grund af ukendte eller ikke-administrerede aktiver. Skyggeapplikationssoftware repræsenterer den kategori af ukendte aktiver, som hverken netværksbaserede registreringsværktøjer eller SaaS-synlighedsplatforme kan finde.
Hvorfor skyggeapplikationssoftware akkumuleres
At forstå, hvorfor udokumenterede brugerdefinerede applikationer spreder sig i virksomhedsmiljøer, forklarer, hvorfor standardstyringsprocesser ikke formår at forhindre det, og hvorfor retrospektiv opdagelse er nødvendig.
Den umiddelbare løsning er absolut nødvendig. Forretningsenheder står over for specifikke driftsproblemer, der kræver specifikke løsninger. Den godkendte applikation håndterer ikke edge-casen. IT-anmodningskøen er begrænset af efterslæb. En udvikler, nogle gange i IT, nogle gange integreret i et forretningsteam, skriver en løsning, der fungerer. Løsningen kører, løser problemet og bliver en del af den operationelle arbejdsgang. Den formelle styringsproces finder aldrig sted, fordi problemet allerede er løst.
Det midlertidige-der-blev-permanent-mønster. Den mest lumske form for skyggeapplikationssoftware begynder som en eksplicit midlertidig løsning. "Bare indtil det rigtige system er klar." "En hurtig løsning på dataformatproblemet." "Midlertidig, mens vi venter på, at leverandøren reparerer deres API." Midlertidige løsninger bliver permanente, når de afhængigheder, der akkumuleres omkring dem, aldrig afmonteres. COBOL-datoberegningsrettelsen, der er skrevet til Y2K-afhjælpning, som stadig bliver kaldt 25 år senere, fordi ingen efterfølgende udvikler vidste, hvorfor den eksisterede, eller om det var sikkert at fjerne. Det "midlertidige" databasenormaliseringsscript, der blev en del af den natlige batch, fordi målapplikationen aldrig rent faktisk blev bygget.
Fejl i videnoverførsel. Skyggeapplikationer bygget af specifikke individer forlader organisationens dokumenterede viden, når disse individer forlader organisationen. Programmet fortsætter med at køre, det er integreret i produktionsprocesser, der er afhængige af det, men der findes ingen dokumentation, intet ejerskab er tildelt, og ingen ved, hvad det gør, i tilstrækkelig detaljer til at ændre det sikkert. Det bliver et spøgelse i produktionsmiljøet: synligt i sine effekter, usynligt i sin styring.
Skyggedatapipelinen. Dataintegration er en særlig frugtbar jord for udokumenteret brugerdefineret software. Når det officielle ETL-lag ikke understøtter en nødvendig transformation, eller når en forretningsproces kræver, at data flyttes hurtigere mellem systemer, end den officielle integrationsproces tillader, bygger udviklere uofficielle dataflytningsprogrammer. Et Python-script, der forespørger produktionsdatabasen og skriver resultater til et delt drev, som en downstream-proces henter. Et COBOL-program, der læser fra mainframe DB2 og skriver til en flad fil, som en cloud-applikation indtager. Disse uofficielle datapipelines krydser systemgrænser, håndterer potentielt følsomme data og opererer helt uden for integrationsstyringsrammen.
De fire kategorier af skyggeapplikationssoftware
Kategori 1: Tilpassede forretningsenhedsapplikationer
Programmer bygget af udviklere, der er integreret i forretningsenheder, økonomi, indkøb, drift og compliance, og som løser specifikke domæneproblemer. Disse programmer er typisk:
- Navngives uformelt (TAXCALC, VENDREPT, ADJBATCH) uden at følge virksomhedens navngivningskonventioner
- Ligger i mapper eller biblioteker, der administreres af forretningsenheden i stedet for IT
- Har ingen indgang i konfigurationsstyringsdatabasen (CMDB)
- Har ingen tildelt teknisk ejer i IT's servicestyringssystem
- Manglende formel dokumentation, testdækning og historik for ændringskontrol
Deres kritiske betydning bliver ofte undervurderet, fordi forretningsenheden ved, hvad programmet gør, og anser det for at være "deres". IT-organisationen, som ikke ved, at programmet eksisterer, kan ikke score dets kritiske betydning. Programmets fravær fra IT's applikationsinventar betyder, at det ikke er med i BCP, katastrofeberedskabsplanlægning, sikkerhedsvurderinger og moderniseringsprogrammets omfang.
Kategori 2: Spøgelsesprogrammer
Programmer, der optræder i produktionsudførelse, men hvis oprindelse, formål og ejerskab er ukendt for den aktuelle organisation. De findes i indlæsningsbiblioteker og kildekode-arkiver, de kaldes af andre programmer eller påkaldes af JCL-job, de producerer output, som downstream-processer er afhængige af, men organisationens hukommelse om, hvorfor de eksisterer, og hvem der er ansvarlig for dem, er gået tabt.
Spøgelsesprogrammer er særligt farlige set fra et sikkerheds- og compliance-perspektiv, fordi de ikke kan gennemgås i forhold til gældende standarder, ikke kan inkluderes i sårbarhedsscanningsprogrammer, der kræver tildeling af applikationsejerskab, og ikke kan vurderes for overholdelse af lovgivningen, fordi ingen ved, hvilke data de tilgår, eller hvilken forretningsfunktion de udfører.
Kategori 3: Skyggedatapipeliner
Uofficielle programmer, der flytter data mellem systemer uden for den godkendte integrationsarkitektur. Disse spænder fra sofistikerede ETL-alternativer til simple filoverførselsscripts:
python
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")Dette program, der repræsenterer et mønster, der findes på tværs af virksomhedsmiljøer, bruger hardcodede produktionsdatabaseoplysninger, skriver følsomme faktureringsdata til en delt netværksplacering uden kryptering og har kørt uovervåget i årevis efter, at dets forfatter forlod organisationen. Det ville ikke blive vist i noget SaaS-registreringsværktøj, fordi det kører på intern infrastruktur. Det ville ikke blive vist i netværkstrafikanalyse, fordi det bruger standarddatabaseprotokoller, der ikke producerer nogen skelnbar signatur. Det er kun synligt i selve kildekoden.
Kategori 4: Udokumenterede batchjob
JCL-jobstrømme og planlagte programmer, der kører på produktionsinfrastruktur, men som ikke er inkluderet i den officielle jobplanlægningsdokumentation. Disse akkumuleres gennem:
- Job indsendt uden for standardjobplanlæggeren via direkte indsendelse
- Programmer, der kaldes dynamisk fra andre programmer (og derfor ikke uafhængigt synlige i planlæggernes oversigter)
- Job, der kører sjældent, ved månedens udgang, ved årets udgang eller kun når specifikke forretningsforhold opstår, og som aldrig er blevet registreret i rutinemæssige lagerrevisioner.
- Job arvet fra forgængersystemer, der blev "migreret", men aldrig formelt taget ud af drift
Udokumenterede batchjob bliver kritiske fejlpunkter, når:
- Et vedligeholdelsesvindue påvirker det system, de kører på, og ingen ved, at de skal underrette den forretningsenhed, der er afhængig af deres output
- Der udføres en sikkerhedsvurdering, og disse job kører som uovervågede servicekonti med forhøjede rettigheder.
- Et moderniseringsprogram vurderer migrering baseret på den dokumenterede jobplan og ankommer til målmiljøet uden kritisk batchbehandling
Opdagelsesmetoder efter Shadow Software-kategori
De registreringsmetoder, der er passende til SaaS-skygge-IT, kan i vid udstrækning ikke anvendes til skyggeapplikationssoftware. De nødvendige metoder er:
Analyse af indlæsningsbibliotek. Alle programmer, der nogensinde er blevet kompileret og implementeret på et mainframe- eller mellemstort system, findes i et indlæsningsbibliotek, det eksekverbare arkiv. Sammenligning af programmerne i indlæsningsbiblioteket med programmerne i den officielle programinventar afslører hullet: alle indlæsningsmoduler, der vises i biblioteket, men ikke i inventaret, er et skyggeprogram. Denne analyse kræver ingen kildekode, den fungerer på de kompilerede eksekverbare filer og deres metadata.
Gennemgang af kildekodearkiv. Kildekodearkiv (COBOL-kildekode-PDS'er, Git-arkiv, RPG-kildebiblioteker) indeholder alle programmer, der nogensinde er skrevet, inklusive programmer, der blev skrevet uformelt, implementeret uformelt og aldrig registreret i IT-styringssystemer. Gennemgang af hele kildekodearkivet mod CMDB afslører programmer, der findes i kildekoden, men som ikke har nogen styringsregistrering.
JCL- og scheduler-afstemning. Hver JCL-jobstrøm, der udføres i produktion, uanset om den indsendes via den officielle scheduler, indsendes manuelt eller kaldes af et andet job, efterlader et spor i jobudførelsesloggen (JESLOG, SYSLOG). Sammenligning af de programmer, der vises i produktionsudførelseslogge, med programmerne i den officielle inventarliste identificerer programmer, der kører i produktion uden governance-dækning.
Dynamisk CALL-analyse. Programmer, der kalder andre programmer dynamisk, hvor det kaldte programnavn bestemmes under kørsel i stedet for under kompilering, opretter afhængigheder, der er usynlige for statisk scheduler-analyse. Dynamisk CALL-analyse sporer, hvilke programmer der udsteder CALL-sætninger med variable programnavne, identificerer det udvalg af programmer, der kan kaldes, og markerer programmer, der kan nås via dynamisk dispatch, som muligvis ikke vises i nogen statisk afhængighedskort.
Sporing af dataflow. Skyggedatapipelines kan findes gennem analyse af filsystem- og databaseadgangsmønstre: hvilke programmer læser fra eller skriver til hvilke datasæt, filer eller databasetabeller. Et program, der læser fra en produktionsdatabase og skriver til en filsti uden for standarddatahåndteringshierarki, er en kandidat til en skyggepipeline.
Skygge-AI-dimensionen
Udvidelsen af skygge-IT-problemet i 2026 er skygge-AI, medarbejdere og forretningsenheder, der bruger AI-værktøjer og -agenter uden IT-autorisation. Ifølge IBMs rapport om omkostningerne ved et databrud fra 2026 involverer 43 procent af sikkerhedshændelser medarbejdere, der bruger skygge-AI. Gartner forudsiger, at mere end 40 procent af virksomhederne i 2030 vil opleve en sikkerheds- eller compliance-hændelse forbundet med uautoriseret skygge-AI.
Den specifikke risiko, som skygge-AI introducerer, og som er direkte relevant for skygge-IT på kodeniveau: proprietær kildekode, der går ind i AI-kodningsassistenter. En medarbejder, der bruger en uautoriseret AI-kodningsassistent til at hjælpe med et ældre COBOL-program, har sendt programmets kildekode til en ekstern AI-udbyder. Kildekoden kan indeholde hardcodede legitimationsoplysninger, forretningslogik, der udgør forretningshemmeligheder, eller datastrukturer, hvis eksponering overtræder kravene til dataopbevaring. Opdagelsesmetoden for denne specifikke risiko er ikke analyse af netværkstrafik, men detektering af, hvilke programmer der er blevet tilgået af værktøjer, der kommunikerer med eksterne AI API'er, hvilket kræver overvågning på applikationsniveau snarere end overvågning på netværksniveau.
Problemet med skygge-AI og problemet med skyggeapplikationssoftware deler et vigtigt træk: begge er usynlige for de netværksbaserede opdagelsesværktøjer, der dominerer SaaS-markedet for skygge-IT. Begge kræver enten overvågning på applikationsniveau eller strukturel kodeanalyse for at dukke op.
Opbygning af den komplette applikationsinventar
Outputtet fra et skygge-IT-opdagelsesprogram til virksomhedsapplikationssoftware er en afstemt opgørelse, der dækker fire populationer:
Kendte og dokumenterede: Programmer, der optræder i både den officielle fortegnelse og det faktiske produktionsmiljø. Disse programmer har styringsdækning, tildelte ejere, historik over ændringskontrol og planer for katastrofeberedskab.
Kendte, men ikke implementerede: Programmer, der vises i den officielle fortegnelse, men ikke kan findes i indlæsningsbiblioteker eller produktionsudførelseslogfiler. Disse er kandidater til pensionering, de kan være blevet taget ud af drift uden korrekt formel pensionering, eller de kan være angivet forkert.
Ukendt, men implementeret (skyggeprogrammer): Programmer, der vises i produktionsudførelseslogfiler eller indlæsningsbiblioteker, men som ikke er registreret i den officielle fortegnelse. Disse er de centrale skygge-IT-fund, programmer, der kræver øjeblikkelig ejerskabstildeling, sikkerhedsvurdering og registrering af styring.
Udokumenterede afhængigheder: Programmer, der hverken optræder i den officielle fortegnelse eller i de primære produktionsudførelseslogfiler, men som opdages via dynamisk CALL-analyse eller dataflowsporing som tilgængelige fra produktionsprocesser. Disse er spøgelsesprogrammerne, de sværeste at finde og de farligste at lade være uopdagede.
Afstemningen mellem disse fire populationer resulterer i handlingsplanen: registrer skyggeprogrammerne, vurder deres sikkerhedsstilling, tildel ejerskab og fastlæg deres disposition, styr og vedligehold, moderniser eller trække dem tilbage.
Hvordan SMART TS XL Udfører skygge-IT-opdagelse på kodeniveau
SMART TS XL's tilgang til skygge-IT-opdagelse adresserer de kategorier på kodeniveau, som netværksbaserede værktøjer ikke kan nå.
Den statiske kodeanalysefunktion begynder med en komplet gennemgang af kildekodearkivet: hvert COBOL-program, RPG-modul, PL/I-applikation, Java-tjeneste, Python-script og JCL-jobstrøm i miljøet katalogiseres med kildeplacering, sprog, størrelse og foreløbige kompleksitetsprofil. Denne opgørelse er den baseline, som CMDB'en og det officielle applikationsregister afstemmes imod. De programmer, der vises i kildekodearkivet, men ikke i det officielle opgørelse, er det primære fund i skyggeapplikationen.
Applikationsafhængighedskortlægningen løser problemet med dynamisk CALL: ved at spore hver CALL-sætning i hvert program, inklusive dynamiske kald , hvor programnavnet er en variabel, identificerer afhængighedskortet programmer, der kan nås fra produktionsprocesser, selv når de aldrig vises i statiske planlægningslagre. Et ghost-program, der kaldes dynamisk af ti produktionsprogrammer, vises i afhængighedskortet, selvom det ikke har en uafhængig JCL-jobdefinition.
JCL -udvidelsesfunktionen sporer den komplette udførelseskæde for hver JCL-jobstrøm: løsning af PROC-referencer, udvidelse af symbolske parametre og opbygning af det fulde kort over programmer, som hvert job kalder. Når dette kort sammenlignes med den officielle jobplanlægningsdokumentation, vises de job og programmer, der kører i produktion uden dokumentationsdækning, automatisk.
Effektanalysefunktionen gør opdagelsesresultaterne brugbare: For hvert skyggeprogram, der opdages, skal alle produktionsprocesser, der er afhængige af det , opregnes. Et skyggeprogram uden afhængige er en kandidat til død kode, der er sikker at trække tilbage fra drift. Et skyggeprogram med tyve produktionsafhængige er et kritisk, udokumenteret aktiv, der kræver øjeblikkelig opmærksomhed fra ledelsen. Effektomfanget er det, der bestemmer prioriteten for afhjælpning.
Virksomhedssøgningsfunktionen gør det muligt at forespørge på hele opgørelsen: find alle programmer, der tilgår et specifikt datasæt (potentielle kandidater til skyggedatapipeline), alle programmer , der er skrevet efter en bestemt dato, som ikke har nogen CMDB-post (nylige skyggeapplikationer), og alle programmer, der skriver til eksterne filstier uden for standard datastyringshierarki. Denne søgefunktion understøtter både den indledende opdagelsesindsats og den løbende overvågning, der forhindrer, at akkumulering af skyggeapplikationer genoptages efter den indledende oprydning.
For organisationer, der udfører ældre moderniseringsprogrammer, er opdagelse af skyggeprogrammer et forudsætningstrin. Et moderniseringsprogram, der vurderer omfanget af migrering baseret på den officielle applikationsinventar og opdager skyggeprogrammer midt i udførelsen, er et moderniseringsprogram, hvis omfang, tidslinje og budget alle var forkerte på tidspunktet for forpligtelsen. Den opdagelse, der burde have fundet sted før planlægningen, sker nu under udførelsen, når omkostningerne er højest.
Forvaltningens svar: Ikke blokering, men synlighed
De organisationer, der håndterer skygge-IT effektivt i 2026, har lært, at et generelt forbud ikke virker og skaber perverse incitamenter. Skygge-IT-rapportering mislykkes i de fleste organisationer af én grund: medarbejderne forventer straf. Når et medlem af økonomiteamet bruger en ikke-godkendt udgiftsregistrering og selv rapporterer det, har et sikkerhedsteam, der reagerer med en irettesættelse, trænet den pågældende medarbejder og alle, de taler med, til at tie stille næste gang.
Det samme princip gælder for skyggeapplikationssoftware. En udvikler, der har bygget et forretningskritisk COBOL-værktøj, som organisationen er afhængig af, bør ikke straffes for ikke at have gennemgået en styringsproces, der muligvis ikke var blevet klart kommunikeret på det tidspunkt. Styringsresponsen på opdagelse af skyggeapplikationer bør være:
Registrering, ikke fjernelse. Skyggeprogrammer, der opdages at være i den kritiske sti for forretningsprocesser, er ikke skyggeprogrammer, der skal fjernes, de er udokumenterede produktionsapplikationer, der kræver governance-dækning. Registrer dem, tildel ejere, vurder deres sikkerhedsstatus, og behandl dem med samme governance-disciplin som alle andre produktionsapplikationer.
Amnesti for selvafsløring. Et styringsprogram, der skaber sikre kanaler for forretningsenheder til at afsløre uformelle applikationer, de har bygget, og som afdækker skyggesoftware hurtigere end nogen teknisk afsløringsmetoden. Sikkerheden om, at afsløring fører til styringsstøtte, hjælp til dokumentation, sikkerhedsgennemgang og formel registrering snarere end disciplinær reaktion, fjerner incitamentet til at skjule oplysninger.
Forebyggelse gennem proces. Den grundlæggende årsag til ophobning af skyggeapplikationer er styringsfriktion: den officielle proces for anmodning om ny applikationsudvikling er langsommere end forretningsproblemet kræver. Reduktion af denne friktion, letvægtsstyring med hurtig udvikling, integreret IT-styringssupport i forretningsenheder, strømlinet godkendelse af interne værktøjer med lav risiko reducerer antallet af nye skyggeapplikationer uden at kræve løbende teknisk opdagelse.
Det lagerbeholdning, du tror, du har, er ikke det lagerbeholdning, du har
Forskellen mellem den applikationsbeholdning, som IT vedligeholder, og den applikationssoftware, der rent faktisk kører i virksomhedsmiljøer, er ikke en lille uoverensstemmelse. I store organisationer med årtiers applikationsakkumulering kan forskellen mellem dokumenteret og faktisk programmering nærme sig tredive procent af de samlede programmer. De udokumenterede tredive procent omfatter programmer, der behandler følsomme data, udfører funktioner til overholdelse af regler, befinder sig i den kritiske sti i forretningsprocesser og bærer sikkerhedssårbarheder, som ingen har gennemgået, fordi ingen vidste, at de skulle gennemgås.
SaaS shadow IT-opdagelsesværktøjer adresserer cloud-laget af dette problem effektivt. Shadow IT-problemet på kodeniveau, de brugerdefinerede programmer, ghost-værktøjer, uformelle datapipelines og udokumenterede batchjob, der findes i ældre virksomheders miljøer, kræver en anden tilgang: strukturel analyse af de faktiske softwareartefakter i stedet for overvågning af netværkstrafik. Den opgørelse, der fremkommer af denne analyse, er ofte overraskende i sin fuldstændighed. De organisationer, der udfører dette arbejde, finder konsekvent ud af, at det, de troede, de havde kørende i produktion, og det, der rent faktisk kører, er to meningsfuldt forskellige ting. At lukke dette hul er fundamentet for ethvert styrings-, sikkerheds-, BCP- og moderniseringsprogram, der afhænger af at vide, hvad organisationen rent faktisk driver.
