Spisu treści:
Po pierwsze nie szkodzić! Ten edykt - parafrazowany z Przysięgi Hipokratesa - przenika profesjonalną opiekę zdrowotną, tak jak ma to miejsce od zarania zachodniej medycyny około 2500 lat temu. Każdy może docenić prostotę i znaczenie tej mantry. Jeśli nie robisz nic innego jako lekarz, przynajmniej nie rób krzywdy swojemu pacjentowi.
Zapisane w nurt tej frazy, można znaleźć niezaprzeczalną pokorę. W rzeczywistości dla wszystkich różnych i różnorodnych dziedzin nauki istnieje krytyczny aksjomat: zawsze bądź gotów kwestionować swoje założenia. Wiemy tylko to, co wiemy i na pewno jeszcze nie wiemy wszystkiego, i nigdy nie będziemy. Niech ta mądrość będzie ostrzeżeniem dla waszych najsilniejszych zaleceń.
Potem jest część do zrobienia. W każdym przedsięwzięciu życiowym liczy się wiedza na temat znaczenia, a następnie podjęcie odpowiednich działań. Ostrożność jest tak samo ostrożna, jak w trosce o życie innych, powaga jest niezbędna. Z tą perspektywą jako naszym płótnem i zrozumieniem technologii informatycznych (IT) pod naszymi paskami, rzućmy okiem na wprowadzenie HealthCare.gov, często charakteryzowanego sztandarowego projektu Affordable Care Act, znanego również jako „Obamacare”.
Podtrzymywania życia
Jak mogę być tępy? HealthCare.gov nie żył w dniu przyjazdu. Zbiorowa przejrzystość mówi teraz, że wszystkie sześć osób zapisało się pierwszego dnia, 1 października. Sześć. Tylko 32 994 mniej niż 33 000 dzienny cel. I chociaż problemy z „pojemnością” były reklamowane jako odradzane wyróżnienia popytu, każdy, kto znał się na dynamice sieci, wiedział lepiej.
„To nie jest nierozwiązany problem”, zauważa dr Robin Bloor, naukowiec i współzałożyciel The Bloor Group. „Holandia ma taką wymianę”.
W rzeczywistości Holendrzy wyprzedzają grę już od dwóch dziesięcioleci, wyciągając wiele wniosków. Szwajcarzy mają również pewne doświadczenie i oczywiście Massachusetts ma MAHealthConnector.org, tzw. „RomneyCare”.
Bloor powiedział dalej, że 40 lat doświadczenia w branży IT udowodniło, że duże projekty zawsze wiążą się z dużym ryzykiem.
„Wykonaj duży projekt, wysokie ryzyko, wysokie ryzyko niepowodzenia. Trzy i pół roku brzmi jak w dzisiejszych czasach, to by wystarczyło, ale tutaj jest projekt wysokiego ryzyka i wszystko okazało się źle, - powiedział Bloor.
Był najbardziej szczery w kwestii sposobu przeprowadzania testów integracyjnych dla HealthCare.gov.
„Ostatnią rzeczą, która mnie zrobiła, prawie wybuchając śmiechem, były testy integracyjne dopiero na dwa tygodnie przed uruchomieniem - i po prostu, jak mogłeś to zrobić z czymś takim? Jak mogłeś?” Powiedział Bloor.
Dr Geoffrey Malafsky z Phasic Systems Inc., dzieląc się tą perspektywą, jest doświadczonym federalnym wykonawcą i innym badaczem danych. Ostatnio Malafsky przedstawił godzinną, szczegółową ocenę wdrożenia HeathCare.gov i skomentował zarówno podjęte strategiczne, jak i taktyczne decyzje . Przede wszystkim wskazuje palcem na protokół przejęcia rządu federalnego.
„Jednym z krytycznych punktów awarii, które przenikają szczególnie rządowe projekty IT, jest to starodawne, archaiczne, przestarzałe pojęcie, że można sformułować całą niezbędną logikę biznesową za pomocą procesu liniowych wymagań. To zasadniczo nie działa w przypadku dużych systemów informatycznych” - powiedział.
Chodzi mu o to, że duże systemy informatyczne będą pochłaniać nawet najmądrzejszych planistów. Po prostu nigdy nie wiadomo, skąd pojawią się problemy, gdzie trzeba zapewnić dodatkowe wsparcie lub w jaki sposób rozwiązywać problemy, w które się zaangażujesz. W związku z tym złym pomysłem jest ograniczenie procesu projektowania przez zmuszenie inżynierów projektu do przewidywania wszystkiego. będą potrzebować z góry.
Sprawą komplikuje się, jak mówi Malafsky, fakt, że urzędnicy odpowiedzialni za zamówienia publiczne w rządzie federalnym stali się teraz tak potężni - z powodu ogromnych kwot pieniędzy, które kontrolują - że w zasadzie kontrolują przebieg dużych projektów informatycznych. To stawia urzędników departamentów w roli suplikanta i wprowadza element ryzyka do kluczowej procedury w centrum każdej znaczącej inicjatywy informatycznej: wyboru odpowiednich narzędzi, technologii i kontrahentów.
„Ludzie, którzy najmocniej nie zgodzą się z tym stwierdzeniem, nazywani są specjalistami ds. Akwizycji i zachęcam ich, aby pojawili się w moim domu, a my będziemy siedzieć i dyskutować o tym, ponieważ mam wiele dowodów empirycznych na poparcie tego”, Malafsky powiedziany.
Strategia strony
Jednym z ważnych pytań jest to, dlaczego rząd zastosował tak kompleksową architekturę dla tej strony internetowej.
„Jeśli nadrzędny program rządowy jest skonfigurowany w taki sposób, że firmy ubezpieczeniowe faktycznie są klientami po otrzymaniu zobowiązania, to dlaczego nie po prostu zepchnąć ruchu do istniejącego kanału środowiska interakcji z klientami, który już mają firmy ubezpieczeniowe? Tak, mogą muszą zwiększyć swoje, ale byłby to uzasadniony powód biznesowy, ponieważ teraz będą zdobywać nowych klientów ”- powiedział Malafsky.
Znany na całym świecie (a teraz nieco niesławny) pionier oprogramowania zabezpieczającego John McAfee również niedawno skomentował tę strategię, robiąc kilka kontrowersyjnych uwag na temat „Neil Cavuto Show” w Fox News:
„Och, to jest naprawdę złe” - powiedział McAfee. „Ktoś popełnił poważny błąd, nie projektując programu, ale po prostu wdrażając jego aspekt internetowy. Mam na myśli, że na przykład każdy może założyć stronę internetową i twierdzić, że jest brokerem dla tego systemu… każdy haker może umieścić strona internetowa sprawi, że będzie wyglądać niezwykle konkurencyjnie, a ze względu na charakter systemu - a przecież jest to opieka zdrowotna - mogą zadawać najbardziej intymne pytania, a ty swobodnie na nie odpowiesz ”.
W odniesieniu do samej architektury sieciowej Malafsky wskazuje na oczywiste - że Internet nie został zbudowany do uruchamiania złożonych aplikacji. Takie było zadanie komputera mainframe w czasach, gdy sieć była w powijakach. Zamiast tego punktem projektu Internetu było proste dzielenie się informacjami za pośrednictwem poszczególnych stron rozproszonych w szerokiej sieci komputerów. W projektowaniu systemów celem jest zbudowanie czegoś, co działa. Włączanie złożoności dla samego siebie jest nierozsądne, wręcz świętokradzkie i prawie zawsze stanowi przepis na katastrofę.
W swoim własnym głębokim spojrzeniu na to, co poszło nie tak z HealthCare.gov, Washington Post opublikował słynną grafikę, która przedstawiała różne wyzwania, przed którymi stoi strona. Język używany przez gazetę do opisania strony jest w rzeczywistości dość odkrywczy, zwłaszcza jeśli weźmie się pod uwagę, że jest to ustalona gazeta w Waszyngtonie, epicentrum rządu federalnego USA:
HealthCare.gov, zbudowany przez 55 kontrahentów, jest jednym z najbardziej złożonych programów, jakie kiedykolwiek stworzono dla rządu federalnego. Komunikuje się w czasie rzeczywistym z co najmniej 112 różnymi systemami komputerowymi w całym kraju. Według pierwszych danych Obamy w ciągu pierwszych 10 dni odwiedziło 14, 6 miliona niepowtarzalnych wizyt.
Źródło: The Washington Post
Prawdopodobnie z definicji ktoś, kto twierdzi, że ma oprogramowanie, to musi być tak, że oprogramowanie faktycznie działa. W przeciwnym razie masz kompilację kodu, która nie stanowi jeszcze oprogramowania. Pomijając tę ciekawostkę, zwróć uwagę na podane liczby, zwłaszcza część dotyczącą komunikacji „w czasie rzeczywistym” ze 112 różnymi systemami komputerowymi w całym kraju. To doskonały przykład chwalącej złożoności dla samej siebie.
„Wiemy, że inną możliwością jest stworzenie prostego, bardzo prostego systemu brokera internetowego, wszystko to, co robi, to bardzo prosty kod serwera aplikacji i jeszcze prostszy JavaScript po stronie klienta, tworzy bardzo przyjemny interfejs, który generuje zbiorcze dane dla ludzi - powiedział Malafsky. „Oto, co możesz zrobić: krok po kroku; krok po kroku. Następnie można wykonać dowolną akcję w punkcie wyboru i wysłać do kogoś, kto faktycznie będzie właścicielem programu”. Oczywiście, że „ktoś” odnosi się do firm ubezpieczeniowych, które i tak będą właścicielami polis.
Grafika graficzna
Projektanci systemów na całym świecie musieli skulić się na widok tej grafiki. Rzućmy okiem na różne przedstawione kroki, w szczególności na poważne problemy, które pojawiają się przy tak ambitnej architekturze. Przede wszystkim rozważymy liczbę potencjalnych transakcji, które do tej pory zakończyły się niepowodzeniem, większość z nich z powodu przekroczenia limitu czasu oprogramowania - przypadki, gdy jedna część procesu transakcji nie otrzyma niezbędnych danych w dopuszczalnym okresie.
„Każde oprogramowanie na tej grafice miało swoje własne limity czasu i nie ma nawet jednego limitu czasu. Może być więcej”, powiedział Malafsy. „Wygaśnięcie któregokolwiek z nich zabije całą transakcję. Niektóre z nich są łatwe do skonfigurowania i monitorowania, jak pliki dziennika. Są to jak limity czasu na serwerze sieci Web i serwerze aplikacji. Niektóre są bardziej nieprzejrzyste. Masz bazy danych ze współbieżnością i wyzwalaczami, ale są to interakcje wielokrotne. Jeśli naprawdę zagłębisz się w działanie baz danych, nie jest to ładny widok ”. (Poznaj podstawy działania baz danych w naszym samouczku o bazach danych).
„Serwery baz danych uwielbiają mówić:„ Utrzymujemy wszystko w porządku ”. Niezupełnie - powiedział Malafsky. Jedynym sposobem, aby zwiększyć wydajność i naprawdę nią zarządzać, jest to, że istnieje szereg plików ze znacznikami czasu, które są tworzone w pamięci, pamięci trwałej i nie są one łączone w jeden kompleksowy dokładny zestaw danych, który jest dostępny dla każdego w dowolnym momencie, ponieważ zajmuje to zbyt dużo czasu. Zabiłoby to opóźnienie transakcyjne. Musisz przyjrzeć się tym szczegółom, a następnie zebrać je za pomocą interfejsu zarządzania - i to bardzo fajnie wyrafinowane nazwy takie jak wyzwalacze i współbieżność - ale w zasadzie oznacza to, że potrzeba dużo czasu, aby uzyskać dane, zaktualizować dane, a jeśli nie będę mógł tego zrobić, zanim nadejdzie kolejne żądanie, powiem ci: Zapomnij o tym. Jestem zamknięty w interesach. ”
- "Drzwi frontowe"
Grafika „Washington Post” zawiera bardzo ciekawą informację na tippy-top w pierwszej sekcji „problem”, w której napisano, że „administracja Obamy pod koniec września zdecydowała się wykluczyć na razie funkcję, która pozwoliłaby ludziom na zakupy plany zdrowotne bez uprzedniego utworzenia konta online ”.
Łał. Przede wszystkim, czy to naprawdę „funkcja”, która została wykluczona? Mówimy o podstawowym przepływie witryny. Pierwotnie planowano pozwolić ludziom na zakupy, a następnie w odpowiednim czasie rozważyć założenie konta.
Niektórzy krytycy spekulują, że ta zmiana wprowadzona w ostatniej chwili (sama w sobie jest niezwykle ryzykownym posunięciem przy tak dużym projekcie), pokazuje, że administracja wiedziała, że witryna nie działała dobrze w ciągu ostatnich kilku tygodni poprzedzających uruchomienie 1 października . Zamiast tego postanowiono uchwycić wszystkie informacje o tych, którzy potrzebowali ubezpieczenia, tak aby działania marketingowe mogły być podejmowane gdzieś po linii, gdy strona będzie funkcjonować.
Z punktu widzenia użyteczności i pojemności ten ruch w ostatniej chwili ogromnie obciążył podstawy bazy danych, jaką miała strona. To wyjaśnia wszystkie anegdoty o niemożności rejestracji lub zmuszeniu do zmiany hasła. I bądźmy szczerzy tutaj. Czy jest jakiś problem dokładniej rozwiązany w sieci WWW niż proces zakładania konta użytkownika? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - nawet klasa dziewiarska twojej babci - ma teraz własną dynamiczną rejestrację, z wypisanymi funkcjami rezygnacji z subskrypcji, przesyłania dalej i innymi podstawowymi funkcjami. - Rejestracja
Kiedy przyszedł czas na rejestrację na HealthCare.gov, wykonawcy mówią: „Komunikacja między niektórymi z tych systemów nie działała prawidłowo, co oznacza, że wielu użytkowników nie było w stanie pomyślnie utworzyć konta”.
Co? Które systemy? Mówimy o bazie danych klientów! „Systemami” byłby wówczas klient sieciowy i baza danych klientów. Jakie inne systemy były zaangażowane? To konkretne „wyjaśnienie” nie ma sensu. - Dowód tożsamości
Następnie dowód tożsamości. Na tym etapie nie ma żadnych problemów, co również jest ciekawe. Experian jest wymieniony jako zewnętrzny agent, który „zweryfikuje” czyjąś tożsamość. Bez wątpienia rozwiązanie problemu tożsamości to poważny problem, którym należy się zająć. Większość firm ubezpieczeniowych używa Twojego numeru ubezpieczenia społecznego, a także zewnętrznych dostawców, takich jak Experian. Czy naprawdę nie ma żadnych problemów z tym krokiem?
Z licznych anegdot, potwierdzonych przedstawioną dokumentacją, wiemy na pewno, że HealthCare.gov z pewnością doświadczył naruszenia poufnych informacji. Malafsky zwraca uwagę, że problemy z jakością danych są znacznie poważniejsze niż problemy z pojemnością. (I Bloor zauważa, że jeśli problemy z pojemnością naprawdę były problemami, powinny zostać rozwiązane w ciągu kilku dni, a nie tygodni. Możesz dodawać sprzęt, wirtualizować i robić dowolną liczbę rzeczy w przypadku problemów z pojemnością.)
Nie, problemy z jakością danych są naprawdę niebezpieczne. Najbardziej niepokojącym aspektem są rodzaje problemów z jakością danych, które się pojawiły. Są historie ludzi, którzy rejestrują się, a następnie otrzymują poufne dokumenty kwalifikacyjne należące do innych rejestrujących! Pod przykryciem uderza to absolutnie okropnym projektem. Czy nie używają jakiegoś uniwersalnego kodu identyfikacyjnego dla każdej osoby?
„Mądrym posunięciem byłoby stworzenie uniwersalnie unikalnego identyfikatora (UUID), przechowywanie zaszyfrowanych wartości - notatka w liczbie mnogiej - które mogą być unikatowymi informacjami (SSN, DOB, wiek, dane biometryczne), a następnie ich ocena pod kątem wyjątkowej osobowości” Powiedział Malafsky.
To, że ktoś może otrzymać poufne dokumenty innej osoby, jest niewiarygodnie złe i pokazuje kilka bardzo poważnych problemów z mapowaniem głęboko w brzuchu bestii. - Kwalifikowalność
OK, ludzie. Tutaj życie staje się interesujące! Jeśli Twoja transakcja nie przekroczyła limitu czasu, prawie na pewno zrobiła to na tym etapie. Zgodnie z grafiką „Washington Post”: „System musi określić, czy przysługuje pomoc finansowa, wysyłając dane osobowe konsumenta do centrum danych, które zawiera umowy z dziesiątkami agencji federalnych i stanowych”.
Próba przeprowadzenia transakcji w trzech lub czterech kluczowych systemach jest prawdziwym wyzwaniem. Próba trafienia w „dziesiątki” agencji stanowych i federalnych „w czasie rzeczywistym” nie wchodzi w grę i jest całkowicie niepotrzebna. Malafsky zajął tylko jeden punkt interakcji, aby przedstawić swój przypadek:
„Jednym z oczywistych jest uzyskanie danych finansowych na osobę w celu ustalenia, czy zasługują na dotację lub jaka byłaby ich cena, więc przechodzimy do IRS. Teraz mamy tam link, ale ten link jest aktywny Oznacza to, że gdy użytkownik siedzi tam i czeka na ekranie komputera, musi nawiązać połączenie z systemami IRS. W idealnym świecie połączenie to się dzieje, komputery mówią, dostaję wynik i wracam.
„A co w prawdziwym świecie? Co z tym, kiedy systemy IRS są przeciążone? Co z tym, kiedy są na pełnych obrotach? Co powiesz, kiedy wykonują konserwację? Co to jest sieć między centrum obsługi sieci klasy podstawowej Strona internetowa, którą klient widzi w centrum IRS? Może są tam jakieś problemy. Może jest wirus. Może krąży koń trojański, a telekomunikacja wyłączyła rozwiązania tego problemu. To zabije transakcję z punktu widzenia widok użytkownika. To tylko jeden z wielu takich punktów w tej architekturze - powiedział Malafsky.
Chodzi o to, że każdy z tych systemów - ponieważ to archiwum internetowe zostało zaprojektowane dla HealthCare.gov - każdy z nich jest potencjalną piętą achillesową. To sytuacja, w której nie można wygrać. I znowu nie jest to konieczne z punktu widzenia przepływu pracy. Po drodze jest wiele punktów, w których przepływ pracy może być rozszerzony za pomocą rzutników danych w czasie zbliżonym do rzeczywistego, rzutników danych we właściwym czasie, a nawet interwencji człowieka w celu usunięcia głównych punktów awarii automatyzacji.
Dlatego dużym błędem strategicznym była próba osiągnięcia tak niezwykle złożonej witryny. - Kupowanie planu
Pamiętaj: to miał być oryginalny przepływ witryny. Internauci najpierw kupiliby plan ubezpieczenia. Następnie, gdy znajdą coś interesującego, mogą zarejestrować konto, sprawdzić, czy chcą otrzymać dotacje, i ostatecznie zakupić plan.
Zgodnie z grafiką „niektórym osobom o niskich dochodach mówi się, że nie kwalifikują się do dotacji lub nie kwalifikują się do Medicaid, nawet jeśli powinny”. Tutaj pojawia się pytanie: dlaczego ten problem jest wymieniony w kroku 5 zamiast w kroku 4? Jest to problem związany z tym, że poprzedni krok nie został odpowiednio obliczony, a zatem nie został poprawnie uwzględniony w kroku 5. - Tłumaczenie ubezpieczeń
W naszym świecie nazywamy tę część ETL. Jest to tak samo rozwiązany problem jak rejestracja strony.
- Rejestracja do ubezpieczenia
Święty Gral! Ale poczekaj, jest jeszcze jedna „usterka”, według kontrahentów HealthCare.gov: „Raporty, znane jako 834, są czasem mylące i powielają się, co utrudnia firmom ubezpieczeniowym ustalenie, kim naprawdę są ich nowi klienci”.
Poświęćmy chwilę ciszy, aby docenić ten…
Tak, tak naprawdę, firma ubezpieczeniowa musi wiedzieć, kto jest naprawdę ubezpieczony. To dość krytyczny element. To samo dotyczy ratownika, który wie, którą osobę leczyć, lub lekarza, do którego klatki piersiowej należy przeszczepić serce. W branży medialnej możemy scharakteryzować ten mały przypadek jako przypadek naszych federalnych kontrahentów całkiem skutecznie zakopujących lede. - Pokrycie
I na koniec, grafika mówi, że „urzędnicy administracji twierdzą, że kupujący złożyli ponad 700 000 wniosków o ubezpieczenie zdrowotne. Niektóre z nich dotarły przez HealthCare.gov, a inne przez państwowe targowiska. Ale urzędnicy nie chcą powiedzieć, ile osób zapisało się na plan."
Sterowanie ręczne
Być może najostrzejszym zakrzywieniem wrzuconym do mieszanki był ostatnio ruch promujący aplikacje papierowe ze względu na wyzwania funkcjonalne strony. Niestety, nawet formularze papierowe muszą zostać przesłane na niedziałającą stronę. Z definicji nie jest to ręczne zastąpienie. Z definicji ręczne zastąpienie musi pozwolić komuś lub czemuś na ręczne zastąpienie automatycznego systemu.
A teraz, w momencie publikacji tego artykułu, słyszymy, że przy ponownym uruchomieniu HealthCare.gov administracja w większym stopniu polega na firmach ubezpieczeniowych w celu rozwiązania problemów. Zgadnij, co to oznacza - założę się, że masz pączki na dolary (tak, kiedyś było na odwrót), że to, co się teraz dzieje, jest przypadkiem powszechnego zgrywania i zamiany. W szczególności programiści i inżynierowie prawdopodobnie wyszarpali wiele „połączeń w czasie rzeczywistym” i inne bardzo drogie oprogramowanie pośrednie, które tak podekscytowało redaktorów Washington Post. Zastąpienie całego tego złożonego kodu jest znacznie prostszym połączeniem o większym opóźnieniu, które jest zasilane przez szereg obiektów danych połączonych poprzez więcej środowiska wsadowego z różnymi systemami stanowymi i federalnymi.
Innymi słowy, rozwiązaniem proponowanym przez Malafsky'ego, Bloora i McAfee jest to, dokąd zmierzamy. I cały ten wymyślny kod spaghetti, który ci federalni kontrahenci wydali na budowanie pół miliarda dolarów przez ostatnie trzy i pół roku? Do pojemnika na ostre przedmioty.
Pochowany Ołów
I jeszcze jedna ostatnia uwaga: według zeznań przed Kongresem Henry Chao, zastępcy dyrektora ds. Informacji w Centrach Medicare i Medicaid Services, systemu płatności, który zwróci firmom ubezpieczeniowym wszystkie te federalne dotacje? Nie został jeszcze zbudowany! Oznacza to, że może to być pierwsza uruchomiona na szeroką skalę witryna e-commerce bez działających środków do przesyłania pieniędzy.
