Innehåll
Källa: Maksym Yemelyanov / Dreamstime.com
Hämtmat:
Washington Post kallade HealthCare.gov "en av de mest komplexa programvara som någonsin skrivits för den federala regeringen." Ur ett IT-perspektiv är det exakt varför webbplatsen inte fungerade.
Först skada inte! Denna edikt - som omskriven från Hippokratiska ed - genomgår professionell hälsovård, som den har gjort sedan västmedicinens början för cirka 2500 år sedan. Vem som helst kan uppskatta enkelheten och betydelsen av denna mantra. Om du inte gör något annat som sjukvårdspersonal ska du åtminstone inte skada din patient.Skrivet i underströmmen av den frasen kan du hitta en obestridlig ödmjukhet. För alla vetenskapens olika och olika vägar finns det faktiskt en kritisk axiom: var alltid villig att ifrågasätta dina antaganden. Vi vet bara vad vi vet, och vi vet säkert inte allt ännu, och vi kommer inte heller någonsin. Låt den visdomen tjäna som en varning till dina starkaste recept.
Då är det det som gör. I alla livsåtgärder hoppas man veta något om import och sedan vidta lämpliga åtgärder. Försiktighet är lika försiktig, och när man tar hand om andras liv krävs allvar. Med detta perspektiv som vår duk och en förståelse av informationsteknologi (IT) under våra bälten, låt oss ta en titt på utrullningen av HealthCare.gov, det ofta karakteriserade flaggskeppet i Affordable Care Act, alias "Obamacare."
Livsuppehållande
Hur trubbig kan jag vara? HealthCare.gov var död vid ankomst. Den kollektiva transparensen säger nu att alla sex personer anmälde sig den första dagen, 1 oktober. Sex. Endast 32.994 kort än det 33.000 dagliga målet. Och medan "kapacitets" -frågor prövades som backhanded utmärkelser av efterfrågan, visste alla med kunskap om webbdynamik bättre."Detta är inte ett olöst problem", konstaterar Dr. Robin Bloor, en datavetare och medstifter av The Bloor Group. "Holland har ett sådant utbyte."
I själva verket har holländarna varit i spelet i två decennier nu, med många lärdomar. Schweizarna har också viss erfarenhet, och Massachusetts har givetvis MAHealthConnector.org, så kallad "RomneyCare."
Bloor fortsatte med att säga att 40 års IT-erfarenhet har visat att stora projekt alltid har stora risker.
"Gör ett stort projekt, hög risk hög risk för misslyckande. Att ha tre och ett halvt år låter som i en modern tid det skulle räcka, men här är ett projekt med hög risk och allt visade sig dåligt, "Sa Bloor.
Han var mest uppriktig om hur integrationstest genomfördes för HealthCare.gov.
"Det sista som gjorde mig, nästan fick mig att skratta av skratt, är ingen integreringstest förrän två veckor innan du går live - och det är precis, hur kunde du någonsin göra det med något liknande? Hur kunde du?" Bloor sa.
Delar det perspektivet är en veteran federala entreprenör och kolleger datavetare, Dr. Geoffrey Malafsky från Phasic Systems Inc. . Framför allt pekar han fingret på den federala regerings förvärvsprotokoll.
"En av de kritiska misslyckandepunkterna som genomsyrar särskilt statliga IT-projekt är denna arv, arkaiska, föråldrade uppfattning om att du kan formulera all nödvändig affärslogik med någon linjär kravprocess. Det grundläggande fungerar inte med stora IT-system," sade han.
Hans poäng är att stora IT-system kommer att bedöva även de smartaste planerarna. Du vet bara aldrig varifrån problem kommer, var du behöver extra support, eller vilken typ av felsökning du kommer att engagera dig i. Följaktligen är det en dålig idé att begränsa designprocessen genom att tvinga projektingenjörer att förutse allt de behöver på förhand.
Komplicera frågor, säger Malafsky, är det faktum att upphandlingsansvariga i den federala regeringen nu har blivit så kraftfulla - på grund av de enorma mängder pengar som de kontrollerar - att de i huvudsak har kontroll över hur stora IT-projekt går framåt. Detta sätter avdelningstjänstemän i rollen som anmodande, och sätter in ett riskelement i ett avgörande förfarande i centrum för alla viktiga IT-initiativ: att välja rätt verktyg, teknik och entreprenörer.
"De människor som är mest okända med det uttalandet kallas förvärvsproffs, och jag uppmuntrar dem att dyka upp hos mig och vi kommer att sitta och diskutera detta, för jag har en hel del empiriska bevis för att stödja det," Malafsky sa.
Webbplatsstrategi
En stor fråga att ställa är varför regeringen omfamnade en så omfattande arkitektur för denna webbplats."Om det övergripande regeringsprogrammet är inrättat så att försäkringsbolagen faktiskt äger klienten efter att de har fått ett åtagande, varför inte bara skjuta trafiken till den befintliga kanalen för klientinteraktion som försäkringsbolagen redan har? Ja, de kanske behöver förstärka sina egna, men det skulle vara ett giltigt affärsskäl eftersom de nu kommer att få nya kunder, ”sade Malafsky.
Den världsberömda (och nu något ökända) säkerhetsprogramvarupionjären John McAfee kommenterade också nyligen denna strategi och gjorde några kontroversiella kommentarer om "Neil Cavuto Show" på Fox News:
"Åh, det är allvarligt dåligt," sa McAfee. "Någon gjorde ett allvarligt fel, inte i att utforma programmet utan bara genomföra webbaspekten av det. Jag menar, till exempel, vem som helst kan sätta upp en webbsida och hävda att vara en mäklare för det här systemet ... varje hacker kan sätta en webbplats upp, få det att se extremt konkurrenskraftigt ut, och på grund av systemets natur - och det är ju vård, trots allt - kan de ställa dig de mest intima frågorna, och du kommer fritt att svara på dem. "
När det gäller själva webbarkitekturen pekar Malafsky på det uppenbara - att Internet inte byggdes för att köra komplexa applikationer. Det var jobbet för stordatoren tillbaka på de dagar då webben var i sin barndom. Snarare var designpunkten för Internet för enkel informationsdelning via enskilda sidor distribuerade över ett brett nätverk av datorer. I systemdesign är målet att bygga något som fungerar. Att införliva komplexiteten för sin egen skull är dåligt rådgivande, rent heligt och nästan alltid ett recept på katastrof.
I sitt eget djupdyk om vad som gick fel med HealthCare.gov publicerade The Washington Post en nu berömd grafik som skildrade de olika utmaningarna som webbplatsen upplever. Det språk som pappret använder för att beskriva webbplatsen är faktiskt ganska avslöjande, särskilt när du anser att det här är den etablerade tidningen Washington, D.C., episoden för den amerikanska federala regeringen:
HealthCare.gov, byggt av 55 entreprenörer, är en av de mest komplexa programvaror som någonsin skapats för den federala regeringen. Det kommunicerar i realtid med minst 112 olika datorsystem över hela landet. Under de första tio dagarna fick den 14,6 miljoner unika besök, enligt Obama-administrationen.
Källa: The Washington Post
Det kan antagligen, per definition, att någon hävdar att de har en mjukvara måste det vara så att programvaran faktiskt fungerar. Annars har du en sammanställning av kod som ännu inte utgör en mjukvara. I den här biten åt sidan, notera de listade siffrorna, särskilt delen om att kommunicera "i realtid" med 112 olika datorsystem runt om i landet. Detta är ett perfekt exempel på att förhärliga komplexiteten för sin egen skull.
"Vi vet att en annan möjlighet är att ha skapat ett enkelt, väldigt enkelt webbmäklarsystem, att allt det gör är genom mycket enkel appserverkod och ännu enklare klientsida Javascript, skapar ett mycket trevligt gränssnitt som producerar upprullade data till människor , "Sade Malafsky. "Här är vad du kan göra: gå igenom detta; gå igenom detta. Sedan kan alla åtgärder som sker göras vid valpunkten och skickas till någon som faktiskt kommer att äga programmet." Naturligtvis hänvisar den "någon" till försäkringsbolagen som kommer att äga försäkringarna ändå.
Den grafiska grafiken
Systemdesignare över hela världen måste ha krympt efter att ha sett den grafiken. Låt oss titta på de olika stegen som beskrivs, och i synnerhet de allvarliga frågor som uppstår med en så ambitiös arkitektur. Först och främst kommer vi att ta hänsyn till antalet potentiella transaktioner som hittills har misslyckats, de flesta av dem på grund av tidsgränser för programvara - fall då en del av transaktionsprocessen inte får de nödvändiga uppgifterna inom en acceptabel tidsperiod.
"Varje programvara i den grafiken hade sina egna timeouts och inte ens en timeout. Det kan vara mer," sade Malafsy. "Utgången för någon av dessa kommer att döda hela transaktionen. Vissa av dessa är lätta att konfigurera och övervaka, som loggfiler. De är som timeouts på webbservern och appservern. Vissa är mer ogenomskinliga. Du har databaser med samtidighet och triggers, men de är flera interaktioner. Om du verkligen gör ett djupt dyk i hur databaser fungerar är det inte ett vackert syn. " (Lär dig grunderna i hur databaser fungerar i vår databashandledning.)
"Dataservrarna älskar att säga: Vi håller allt ordnat." Inte riktigt, "sade Malafsky. Det enda sättet att de kan få upp prestandan och verkligen hantera det är att det finns en serie tidsstämplade filer som skapas på lagring, ihållande lagring, och de rullas inte upp till en omfattande noggrann uppsättning data som är tillgängliga för alla när som helst eftersom det tar för lång tid.Det skulle döda transaktionsfördröjningen.Du måste titta i dessa detaljer och sedan rullas det upp genom ett hanteringsgränssnitt - och det går av mycket trevligt sofistikerat namn som triggers och samtidighet - men det innebär i princip att det tar en massa tid att hämta data, uppdatera uppgifterna och om jag inte kan göra det innan en annan begäran kommer in, ska jag bara säga dig, glöm det. Jag stängde för affärer."
- "Huvuddörren"
Washington Posts-grafiken innehåller en mycket nyfiken information precis vid tippy-toppen i sitt första "problem" -avsnitt, där det står att "Obama-administrationen beslutade i slutet av september att utesluta en funktion som skulle ha låtit folk shoppa för hälsoplaner utan att först skapa ett onlinekonto. "
Wow. Först av allt, är det verkligen en "funktion" som utesluts? Vi pratar om grundläggande webbplatsflöde. Ursprungligen var planen att låta människor shoppa runt, sedan vid rätt tidpunkt, överväga att registrera ett konto.
Vissa kritiker har spekulerat i att denna förändring i sista minuten (i sig själv ett otroligt riskabelt drag med ett så stort projekt), visar att administrationen visste att webbplatsen inte fungerade bra under de senaste veckorna fram till första oktober-lanseringen . Istället blev idén att fånga all information från dem som behövde försäkring, så att marknadsföringsinsatser kunde göras dem någonstans längs linjen när webbplatsen var funktionell.
Från ett användbarhets- och kapacitetsperspektiv satte detta drag i sista minuten en enorm påfrestning på vilken databasfundament webbplatsen hade. Detta förklarar alla anekdoter om personer som inte kan registrera sig eller tvingas ändra sina lösenord. Och låt oss vara ärliga här. Finns det något problem som löses mer noggrant över hela världen än att skapa ett användarkonto? Yahoo, Google, Microsoft, YouTube,, LinkedIn - till och med din mormors stickningsklass - har sin egen dynamiska anmälningsform idag, med inbakade prenumeration, framåt och andra grundläggande funktioner.
- Registrering
När det var dags att registrera sig på HealthCare.gov, säger entreprenörerna, "Kommunikationen mellan några av dessa system fungerade inte korrekt, vilket innebär att många användare inte lyckades skapa ett konto."
Vad? Vilka system? Vi pratar om en kunddatabas! "Systemen" skulle då vara webbklienten och kunddatabasen. Vilka andra system var involverade? Denna speciella "förklaring" har ingen mening.
- Bevis för identitet
Nästa upp, bevis på identitet. För detta steg anges inga problem, vilket också är nyfiken. Experian listas som tredjepartsagent som "verifierar" någons identitet. Utan tvekan är identitetslösning en allvarlig fråga som måste tas upp. De flesta försäkringsbolag använder ditt personnummer, såväl som tredjepartsleverantörer som Experian. Finns det verkligen inga problem med detta steg?
Vi vet med säkerhet från många anekdoter, verifierade med framlagd dokumentation, att HealthCare.gov definitivt har upplevt broschyrer med konfidentiell information. Malafsky påpekar att datakvalitetsfrågorna är de mycket allvarligare än kapacitetsfrågorna. (Och Bloor konstaterar att om kapacitetsfrågor verkligen var problemen, borde de ha lösts på dagar, inte veckor. Du kan lägga till hårdvara, virtualisera, göra valfritt antal saker för kapacitetsproblem.)
Nej, datakvalitetsfrågorna är verkligen farliga. Och den mest oroande aspekten av allt är de typer av datakvalitetsfrågor som har uppstått. Det finns historier om personer som registrerar sig och sedan fått konfidentiella behörighetshandlingar som tillhör andra registranter! Detta lugnar av en helt fruktansvärd design under omslagen. Använder de inte någon slags universell identifieringskod för varje person?
"Det smarta steget skulle vara att skapa en universellt unik identifierare (UUID), lagra krypterade värden - notera plural - av vad som kan vara unik information (SSN, DOB, ålder, biometri) och sedan utvärdera dessa för bevis på unik personlighet," Sa Malafsky.
Att någon kan ta emot en annan persons konfidentiella dokument är otänkbart dåligt och visar några mycket allvarliga kartläggningsfrågor djupt i djurets mage.
- behörighet
OK, folkens. Här blir livet intressant! Om din transaktion inte hade avslutats nu, gjorde den nästan säkert i detta steg. Enligt grafik från The Washington Posts: "Systemet måste fastställa berättigande för ekonomisk hjälp genom att lägga in konsumentens personliga information till en Data Hub som kontrakterar dussintals federala och statliga myndigheter."
Att försöka genomföra en transaktion över tre eller fyra nyckelsystem är en verklig utmaning. Att försöka träffa "dussintals" av statliga och federala byråer "i realtid" är av listorna och helt onödigt. Malafsky tog bara en interaktionspunkt för att göra sitt fall:
"En av de uppenbara här är att få ekonomiska uppgifter per person för att avgöra om de förtjänar en subvention eller vad deras pris skulle vara, så vi går till IRS. Nu har vi en länk där borta, men den länken är live Det betyder att när användaren sitter där och väntar på sin datorskärm måste det göra en länk till IRS-systemen. I en perfekt värld händer den länken, datorerna pratar, jag får mitt resultat och jag kommer tillbaka.
"Vad sägs om i den verkliga världen? Vad sägs om när IRS-systemen är överbelastade? Vad sägs om när de är på kapacitet? Vad sägs om när de kanske gör underhåll? Vad är det med ett nätverk mellan nätverksoperationscentret på ingångswebbsidan att klienten ser till IRS-centret? Kanske finns det några problem där. Kanske finns det ett virus. Kanske finns det en trojansk häst som springer runt och telekom har stängt av saker för att lösa det problemet. Det kommer att döda transaktionen ur synvinkeln användaren. Det är bara en av många sådana punkter i denna arkitektur, "sade Malafsky.
Hans poäng är att vart och ett av dessa system - som denna webbarkitektur designades för HealthCare.gov - var och en av dem är en potentiell Achilles-häl. Det är en situation utan vinnare. Och igen, det är onödigt ur ett arbetsflödesperspektiv. Det finns ett antal punkter längs vägen där arbetsflödet kan kompletteras med nästan realtidsdatamarter, höghastighetsdatamarter, till och med mänsklig intervention för att hantera de viktigaste felpunkterna för automatisering.
Det stora strategiska felet var därför att försöka uppnå en så otroligt komplex webbplats.
- Shopping för en plan
Kom ihåg: Detta skulle vara det ursprungliga webbplatsflödet. Webbsurfarare skulle först handla efter en försäkringsplan. Sedan, när de hittade något av intresse, kunde de registrera sig för ett konto, leta efter subventioner om de ville och i slutändan köpa en plan.
Enligt grafiken berättas "vissa individer med låga inkomster att de inte är berättigade till subventioner eller inte kvalificerar sig för Medicaid, även om de borde göra det." Frågan här blir: Varför listas problemet upp under steg 5 istället för steg 4? Detta är ett problem förknippat med att det föregående steget inte beräknades på lämpligt sätt och därmed inte korrekt tas upp i steg 5.
- Försäkringsöversättning
I vår värld kallar vi denna del ETL. Det är lika löst ett problem som webbplatsregistrering.
- Försäkringsregistrering
Den heliga gralen! Men vänta, det finns en sista "glitch" enligt HealthCare.govs entreprenörer: "Rapporterna, kända som 834s, är ibland förvirrande och duplicativa, vilket gör det svårt för försäkringsbolagen att veta vilka deras nya kunder verkligen är."
Låt oss ta en stund av tystnad för att uppskatta den här ...
Så ja, faktiskt måste ett försäkringsbolag veta vem det verkligen försäkrar. Det är en ganska kritisk komponent. Detsamma gäller för en akutarbetare som vet vilken person som ska behandlas eller en läkare som vet i vars bröst ett hjärta ska transplanteras. I mediebranschen kan vi kanske karakterisera den här lilla dinen som ett fall där våra federala entreprenörer ganska framgångsrikt begravde folken.
- Rapportering
Sist men inte minst anger grafiken att "administrationstjänstemän säger att shoppare har lämnat in mer än 700 000 ansökningar om sjukförsäkring. Vissa av dem har kommit genom HealthCare.gov och andra genom statliga marknadsplatser. Men tjänstemän vägrar att säga hur många som har anmält sig till en planen."
Manuell åsidosättning
Kanske den mest skarpa kurvan som kastades in i blandningen just nyligen var flytten att marknadsföra pappersapplikationer på grund av webbplatsens funktionsutmaningar. Tyvärr måste även pappersformuläret skickas in på den icke fungerande webbplatsen. Per definition är det inte en manuell åsidosättning. Per definition måste en manuell åsidosättning låta någon eller något manuellt åsidosätta det automatiserade systemet.Och nu, när denna artikel publiceras, hör vi att administrationen förlitar sig hårdare på försäkringsbolagen för att lösa problemen vid relanceringen av HealthCare.gov. Gissa vad det betyder - jag slår vad om att du donuts till dollar (ja, det brukade vara tvärtom), att det som händer just nu är ett fall av utbredd rip-and-byte.Specifikt har programmerare och ingenjörer troligtvis rippat ut många av "realtidsanslutningarna" och andra intensivt dyra mellanvaror som fick Postens redaktörer så upphetsade. Att ersätta alla den komplexa koden är mycket enklare, anslutningar med högre latens som matas av en rad datamarter som är kopplade till mer av en batchmiljö till de olika statliga och federala systemen.
Med andra ord, den typ av lösning som Malafsky, Bloor och McAfee föreslår är vart vi ska. Och all den snygga spagettikoden som dessa federala entreprenörer spenderade en halv miljard dollar för att bygga under de senaste tre och ett halvt åren? I skarpbehållaren.