Innholdsfortegnelse:
Først, ikke gjør skade! Denne edikaten - parafrasert fra Hippokratisk ed - gjennomsyrer profesjonell helsehjelp, slik den har gjort siden Western Medicine for omtrent 2500 år siden. Hvem som helst kan sette pris på enkelheten og betydningen av denne mantraen. Hvis du ikke gjør noe annet som helsepersonell, skal du i det minste ikke skade pasienten din.
Skrevet i understrømmen av den frasen, kan du finne en ubestridelig ydmykhet. For alle vitenskapens forskjellige og forskjellige veier er det faktisk et kritisk aksiom: vær alltid villig til å stille spørsmål ved forutsetningene dine. Vi vet bare hva vi vet, og vi vet helt sikkert ikke ennå, og vi vil heller aldri. La den visdommen fungere som en advarsel for dine sterkeste resepter.
Så er det gjør-delen. I enhver livsoppgave håper man å vite noe om import, og deretter ta passende tiltak. Forsiktig er like nøye, og når du tar vare på andres liv, er det nødvendig med alvor. Med dette perspektivet som vårt lerret, og en forståelse av informasjonsteknologi (IT) under beltene, la oss se på utrullingen av HealthCare.gov, det ofte karakteriserte flaggskipet til Affordable Care Act, også kalt "Obamacare."
Livsstøtte
Hvor sløv kan jeg være? HealthCare.gov var død ved ankomst. Den kollektive åpenheten sier nå at alle seks personer meldte seg på sin første dag, 1. oktober. Seks. Bare 32.994 kort av det 33.000 daglige målet. Og mens "kapasitets" -spørsmål ble utpekt som bakhåndstildeling av etterspørsel, visste alle med kunnskap om webdynamikk bedre.
"Dette er ikke et uløst problem, " bemerker Dr. Robin Bloor, en dataforsker og medgründer av The Bloor Group. "Holland har en slik utveksling."
Faktisk har nederlenderne vært foran spillet i to tiår nå, med mange erfaringer. Sveitserne har også litt erfaring, og Massachusetts har selvfølgelig MAHealthConnector.org, såkalt "RomneyCare."
Bloor fortsatte med å si at 40 års IT-erfaring har bevist at store prosjekter alltid har stor risiko.
"Gjør et stort prosjekt, høy risiko og høy risiko for å mislykkes. Å ha tre og et halvt år høres ut som i en moderne tid, det ville være nok, men her er et høyrisikoprosjekt og det hele viste seg dårlig, "Sa Bloor.
Han var mest åpenhjertig om måten integrasjonstesting ble utført for HealthCare.gov.
"Den siste tingen som gjorde meg, nesten fikk meg til å sprekke av latter, er ingen integrasjonstesting før to uker før du går live - og det er akkurat som, hvordan kunne du noen gang gjøre det med noe sånt? Hvordan kunne du det?" Bloor sa.
Han delte det perspektivet er en veteran føderal entreprenør og stipendiat dataforsker, Dr. Geoffrey Malafsky fra Phasic Systems Inc. . Fremfor alt peker han fingeren på anskaffelsesprotokollen til den føderale regjeringen.
"Et av de kritiske sviktpunktene som gjennomsyrer spesielt offentlige IT-prosjekter er denne arvete, arkaiske, foreldede forestillingen om at du kan artikulere all nødvendig forretningslogikk med en viss lineær kravprosess. Det grunnleggende fungerer ikke med store IT-systemer, " sa han.
Poenget hans er at store IT-systemer vil ødelegge selv de smarteste planleggerne. Du vet bare aldri hvor problemer vil komme, hvor du trenger ekstra støtte, eller hva slags feilsøking du vil finne deg selv engasjert i. Derfor er det en dårlig idé å begrense designprosessen ved å tvinge prosjektingeniører til å forutse alt de trenger forhånd.
Å komplisere saker, sier Malafsky, er det faktum at anskaffelsesfunksjonærer i den føderale regjeringen nå er blitt så mektige - på grunn av de enorme mengder penger de kontrollerer - at de i det vesentlige har kontroll over hvordan store IT-prosjekter går fremover. Dette setter avdelingsfunksjonærer i rollen som anmodende, og setter inn et element av risiko i en avgjørende prosedyre i sentrum for ethvert betydelig IT-initiativ: valg av riktige verktøy, teknologier og entreprenører.
"Menneskene som vil være mest uenige med denne uttalelsen kalles profesjonelle anskaffelser, og jeg oppfordrer dem til å dukke opp hjemme hos meg, og vi vil sitte og diskutere dette, fordi jeg har mange empiriske bevis for å støtte det, " sier Malafsky sa.
Nettstedsstrategi
Et stort spørsmål å stille seg er hvorfor regjeringen omfavnet en så omfattende arkitektur for dette nettstedet.
"Hvis det overordnede regjeringsprogrammet er satt opp slik at forsikringsselskapene faktisk eier klienten etter at de har fått en forpliktelse, hvorfor hvorfor ikke bare skyve trafikken til den eksisterende klientinteraksjonskanalitetsmiljøkanalen som forsikringsselskapene allerede har? trenger å utvide sine egne, men det vil være en gyldig forretningsgrunn fordi de nå skal skaffe nye kunder, "sa Malafsky.
Den verdenskjente (og nå litt beryktede) sikkerhetsprogramvarepioneren John McAfee kommenterte også denne strategien nylig, og kom med noen kontroversielle bemerkninger om "Neil Cavuto Show" på Fox News:
"Å, det er alvorlig ille, " sa McAfee. "Noen gjorde en alvorlig feil, ikke i utformingen av programmet, men bare ved å implementere Web-aspektet av det. Jeg mener, for eksempel hvem som helst kan sette opp en webside og hevde å være en megler for dette systemet … enhver hacker kan sette en nettstedet opp, få det til å se ekstremt konkurransedyktig ut, og på grunn av systemets natur - og dette er tross alt helsehjelp - kan de stille deg de mest intime spørsmålene, og du kommer til å svare fritt på dem. "
Når det gjelder selve nettarkitekturen, peker Malafsky på det åpenbare - at Internett ikke var bygget for å kjøre komplekse applikasjoner. Det var jobben til stordatoren i dagene da nettet var i sin spede begynnelse. Snarere var designpunktet for Internett for enkel informasjonsdeling via individuelle sider distribuert over et bredt datamaskinnettverk. I systemdesign er målet å bygge noe som fungerer. Å innlemme kompleksitet for sin egen skyld er dårlig råd, rett og slett hellig, og nesten alltid en oppskrift på katastrofe.
I sitt eget dypdykk om hva som gikk galt med HealthCare.gov, publiserte The Washington Post en nå berømt grafikk som skildret de forskjellige utfordringene nettstedet har opplevd. Språket som papiret bruker for å beskrive nettstedet, er faktisk ganske avslørende, spesielt når du tenker på at dette er den etablerte avisen Washington, DC, episenteret for den amerikanske føderale regjeringen:
HealthCare.gov, bygd av 55 entreprenører, er en av de mest komplekse programvareutstyrene som noensinne er laget for den føderale regjeringen. Den kommuniserer i sanntid med minst 112 forskjellige datasystemer over hele landet. I løpet av de første 10 dagene fikk den 14, 6 millioner unike besøk, ifølge Obama-administrasjonen.
Kilde: The Washington Post
Uten tvil, for at noen kan hevde at de har et programvare, per definisjon, må det være slik at programvaren faktisk fungerer. Ellers har du en kildesamling som ennå ikke utgjør et programvare. Når det går til side, legg merke til tallene som er oppført, spesielt delen om å kommunisere "i sanntid" med 112 forskjellige datasystemer rundt om i landet. Dette er et perfekt eksempel på å glorifisere kompleksiteten for sin egen skyld.
"Vi vet at en annen mulighet er å ha opprettet et enkelt, veldig enkelt nettmeglingssystem, at alt det gjør er ved veldig enkel appserverkode og enda enklere klientside Javascript, skaper et veldig hyggelig grensesnitt som produserer sammenrullede data til folk, "Sa Malafsky. "Her er hva du kan gjøre: gå gjennom dette; gå gjennom dette. Så kan alle handlinger som oppstår gjøres på utvelgelsesstedet og sendes til noen som faktisk vil eie programmet." At "noen" refererer selvfølgelig til forsikringsselskapene som uansett vil eie forsikringene.
Den grafiske grafikken
Systemdesignere over hele verden må ha slynget seg etter å ha sett den grafikken. La oss se på de forskjellige trinnene som er skissert, og spesielt de alvorlige problemene som oppstår med en så ambisiøs arkitektur. Først og fremst vil vi vurdere antall potensielle transaksjoner som har mislyktes så langt, de fleste av dem på grunn av tidsavbrudd for programvare - tilfeller når en del av transaksjonsprosessen ikke mottar nødvendige data innen en akseptabel tidsperiode.
"Hver enkelt programvare i den grafikken hadde egne timeouts, og den er ikke en gang en timeout. Det kan være mer, " sa Malafsy. "Utløpet av en av disse vil drepe hele transaksjonen. Noen av dem er enkle å sette opp og overvåke, som loggfiler. De er som timeouts på webserveren og appserveren. Noen er mer ugjennomsiktige. Du har databaser med samtidighet og triggere, men de er flersamarbeid. Hvis du virkelig gjør et dypt dykk i hvordan databaser fungerer, er det ikke et vakkert syn. " (Lær det grunnleggende om hvordan databaser fungerer i opplæringen til databaser.)
"Dataserverne elsker å si: 'Vi holder alt ordnet.' Egentlig ikke, "sa Malafsky. Den eneste måten de kan få ytelsen opp og virkelig administrere det på er at det er en serie med tidsstemplede filer som er opprettet på lagring, vedvarende lagring, og de blir ikke rullet opp til en omfattende, nøyaktig sett med data som er tilgjengelig for alle når som helst, fordi det tar for lang tid.Det vil drepe transaksjonsforsinkelsen. Du må se på disse detaljene, og så rulles den opp gjennom et administrasjonsgrensesnitt - og det går av veldig fin sofistikert navn som triggere og samtidighet - men det betyr i utgangspunktet at det tar mye tid å hente dataene, oppdatere dataene, og hvis jeg ikke kan gjøre det før en annen forespørsel kommer inn, vil jeg bare si deg, ' Glem det. Jeg er stengt for forretninger. '"
- "Inngangsdøren"
Washington Posts grafikk inkluderer et veldig nysgjerrig informasjonsmateriale rett ved tippy-toppen i sin første "problem" -del, der det står at "Obama-administrasjonen besluttet i slutten av september å utelukke en funksjon som ville ha latt folk handle etter helseplaner uten først å opprette en online konto. "
Wow. For det første, er det virkelig en "funksjon" som ble ekskludert? Vi snakker om grunnleggende nettstedsflyt. Opprinnelig var planen å la folk shoppe rundt, og deretter til riktig tid vurdere å registrere en konto.
Noen kritikere har spekulert i at denne endringen i siste øyeblikk (i seg selv et utrolig risikabelt trekk med et så stort prosjekt), viser at administrasjonen visste at nettstedet ikke fungerte godt de siste par ukene frem til 1. oktober-lanseringen . I stedet ble ideen å fange opp all informasjonen til de som trengte forsikring, slik at markedsføringsinnsats kunne gjøres dem et sted nede på siden når nettstedet var i funksjon.
Fra et brukervennlighets- og kapasitetsperspektiv, satte dette trekket i siste øyeblikk en enorm belastning for hva databasegrunnlaget nettstedet hadde. Dette forklarer alle anekdotene om at folk ikke kan registrere eller blir tvunget til å endre passord. Og la oss være ærlige her. Er det noe problem som er grundigere løst over hele verden enn prosessen med å sette opp en brukerkonto? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - til og med bestemorens strikkeklasse - har sin egen dynamiske påmeldingsform i disse dager, med innbakken avmelding, fremover og andre grunnleggende funksjoner. - Registrering
Da det var på tide å registrere seg på HealthCare.gov, sa entreprenørene: "Kommunikasjonen mellom noen av disse systemene fungerte ikke ordentlig, noe som betyr at mange brukere ikke klarte å opprette en konto."
Hva? Hvilke systemer? Vi snakker om en kundedatabase! "Systemene" vil da være Web-klienten og kundedatabasen. Hvilke andre systemer var involvert? Denne spesielle "forklaringen" gir ingen mening. - Identifikasjon
Neste opp, bevis på identitet. For dette trinnet er ingen problemer listet, noe som også er nysgjerrig. Experian er oppført som tredjepartsagent som vil "bekrefte" noens identitet. Ingen tvil, identitetsløsning er et alvorlig spørsmål som må løses. De fleste forsikringsselskaper bruker personnummer, så vel som tredjepartsleverandører som Experian. Er det virkelig ingen problemer med dette trinnet?
Vi vet med sikkerhet fra en rekke anekdoter, bekreftet med dokumentasjon som er presentert, at HealthCare.gov definitivt har opplevd fortrolige opplysninger. Malafsky påpeker at problemene med datakvalitet er de mye mer alvorlige enn kapasitetsproblemene. (Og Bloor bemerker at hvis kapasitetsproblemer virkelig var problemene, burde de vært løst i løpet av dager, ikke uker. Du kan legge til maskinvare, virtualisere, gjøre et antall ting for kapasitetsproblemer.)
Nei, datakvalitetsproblemene er de virkelig farlige. Og det mest urovekkende aspektet av alt er hva slags datakvalitetsproblemer som har oppstått. Det er historier om folk som melder seg på og deretter mottar fortrolige kvalifikasjonsdokumenter som tilhører andre påmeldte! Dette lukter til et helt fryktelig design under dekslene. Bruker de ikke en slags universell identifikasjonskode for hver person?
"Det smarte trekket ville være å lage en universelt unik identifikator (UUID), lagre krypterte verdier - noter flertall - av hva som kan være unik informasjon (SSN, DOB, alder, biometri), og deretter vurdere disse for bevis på unik personlighet, " Sa Malafsky.
At noen kunne motta en annen persons konfidensielle dokumenter, er usigelig dårlig, og demonstrerer noen svært alvorlige kartleggingsproblemer dypt inne i dyrets mage. - valgbarhet
OK, folkens. Her blir livet interessant! Hvis transaksjonen ikke hadde utløpt nå, gjorde den nesten sikkert på dette trinnet. I følge The Washington Posts grafikk, "Systemet må bestemme kvalifiseringen for økonomisk hjelp ved å sende forbrukerens personlige informasjon til en Data Hub som kontrakter dusinvis av føderale og statlige byråer."
Å prøve å utføre en transaksjon på tre eller fire viktige systemer er en genuin utfordring. Å prøve å treffe "dusinvis" av statlige og føderale byråer "i sanntid" er utenfor listene, og helt unødvendig. Malafsky tok bare ett samspillspunkt for å lage sin sak:
"En av de åpenbare her er å få økonomiske data per person for å avgjøre om de fortjener et tilskudd eller hva deres prispoeng ville være, så vi går til IRS. Nå har vi en kobling der borte, men den koblingen er live Det betyr at når brukeren sitter der og venter på dataskjermen sin, må det være en lenke til IRS-systemene. I en perfekt verden skjer den koblingen, datamaskinene snakker, jeg får resultatet, og jeg kommer tilbake.
"Hva med i den virkelige verden? Hva med når IRS-systemene er overbelastet? Hva med når de har kapasitet? Hva med når de kanskje gjør vedlikehold? Hva med det er et nettverk mellom nettverksoperasjonssenteret på inngangsnivået Nettside som klienten ser til IRS-senteret? Kanskje det er noen problemer der. Kanskje det er et virus. Kanskje er det en trojansk hest som løper rundt og telekomene har lagt ned ting for å løse det problemet. Det vil drepe transaksjonen fra det punktet brukerens syn. Det er bare ett av mange slike punkter i denne arkitekturen, "sa Malafsky.
Poenget hans er at hvert eneste av disse systemene - som denne nettarkitekturen ble designet for HealthCare.gov - hver og en av dem er en potensiell akilleshæl. Det er en situasjon uten vinn. Og igjen er det unødvendig fra et arbeidsflytperspektiv. Det er et hvilket som helst antall punkter underveis der arbeidsflyten kan forsterkes med datatilpasninger i sanntid, datamars til rett tid, til og med menneskelig intervensjon for å løse de viktigste feilpunktene for automatisering.
Den store strategiske feilen prøvde derfor å oppnå et så utrolig komplekst nettsted. - Handle etter en plan
Husk: Dette skulle være den opprinnelige nettstrømmen. Nett surfere ville først handle for en forsikringsplan. Da de fant noe av interesse, kunne de registrere seg for en konto, se etter subsidier om de ønsket det og til slutt kjøpe en plan.
I følge grafikken "blir noen enkeltpersoner med lave inntekter fortalt at de ikke er kvalifisert for subsidier eller ikke kvalifiserer for Medicaid, selv om de burde." Spørsmålet her blir: Hvorfor er dette problemet oppført under trinn 5 i stedet for trinn 4? Dette er et problem assosiert med at det forrige trinn ikke ble beregnet på riktig måte, og dermed ikke blir korrekt innarbeidet i trinn 5. - Forsikring Oversettelse
I vår verden kaller vi denne delen ETL. Det er like løst et problem som registrering av nettsteder.
- Påmelding til forsikring
Den hellige gral! Men vent, det er en siste "feil", ifølge HealthCare.govs entreprenører: "Rapportene, kjent som 834-tallet, er noen ganger forvirrende og duplikative, noe som gjør det vanskelig for forsikringsselskapene å vite hvem de nye kundene virkelig er."
La oss ta et øyeblikk av stillhet for å sette pris på denne …
Så ja, faktisk må et forsikringsselskap vite hvem det virkelig forsikrer. Det er en ganske kritisk komponent. Det samme gjelder en akuttarbeider som vet hvilken person han skal behandle, eller en lege som vet inn i brystet et hjerte skal transplanteres. I mediebransjen karakteriserer vi kanskje denne lille dinen som et tilfelle av våre føderale entreprenører ganske vellykket begravet folket. - Dekning
Sist, men ikke minst, sier grafikken at "administrasjonspersoner sier at kjøpere har sendt inn mer enn 700 000 helseforsikringssøknader. Noen av dem har kommet gjennom HealthCare.gov og andre gjennom statlige markedsplasser. Men tjenestemenn nekter å si hvor mange som har meldt seg inn i en plan."
Manuell overstyring
Kanskje den skarpeste kurveballen som ble kastet i miksen for nylig, var trekket å markedsføre papirapplikasjoner på grunn av nettstedets funksjonalitetsutfordringer. Dessverre må selv papirskjemaene sendes inn på det ikke-fungerende nettstedet. Per definisjon er det ikke en manuell overstyring. Per definisjon må en manuell overstyring tillate at noen eller noe manuelt overstyrer det automatiserte systemet.
Og nå, på tidspunktet for denne artikkelen som publiseres, hører vi at for relanseringen av HealthCare.gov, er administrasjonen mer avhengig av forsikringsselskaper for å fikse problemene. Gjett hva det betyr - jeg vil satse deg donuts til dollar (ja, det pleide å være omvendt), at det som skjer akkurat nå er et tilfelle av utbredt rip-and-erstatning. Spesifikt har programmerere og ingeniører sannsynligvis dratt ut mange av "sanntidsforbindelsene" og andre intenst dyre mellomvare som fikk Washington Posts redaktører så begeistret. Å bytte ut alle den komplekse koden er mye enklere forbindelser med høyere latens som blir matet av en rekke datamarkter koblet via mer av et batch-miljø til de forskjellige statlige og føderale systemene.
Med andre ord, den typen løsning som Malafsky, Bloor og McAfee foreslår er hvor vi skal. Og all den fancy spaghettikoden som disse føderale entreprenørene brukte en halv milliard dollar på å bygge de siste tre og et halvt årene? Inn i skarpe beholderen.
Begravet bly
Og en siste merknad: I følge vitnesbyrd fra Henry Chao, Center for Medicare og Medicaid Services, informasjonssjef for kongressen, kongressen, betalingssystemet som vil godtgjøre forsikringsselskaper med alle de føderale subsidiene? Den har ikke blitt bygget enda! Det betyr at dette kanskje bare er det første storskala e-handelsnettsted som noensinne er lansert uten et virkemiddel for å overføre penger.
