Zuhause Audio Warum der erste Rollout von healthcare.gov abstürzte, ist eine architektonische Beurteilung

Warum der erste Rollout von healthcare.gov abstürzte, ist eine architektonische Beurteilung

Inhaltsverzeichnis:

Anonim

Erstens, schade nicht! Dieses Edikt - umschrieben aus dem Hippokratischen Eid - durchdringt die professionelle Gesundheitsfürsorge, so wie es seit den Anfängen der westlichen Medizin vor etwa 2.500 Jahren der Fall war. Jeder kann die Einfachheit und Bedeutung dieses Mantras schätzen. Wenn Sie als Heilpraktiker nichts anderes tun, verletzen Sie Ihren Patienten zumindest nicht.


In die Unterströmung dieses Satzes geschrieben, findet man eine unbestreitbare Demut. Tatsächlich gibt es für all die verschiedenen Wege der Wissenschaft ein kritisches Axiom: Seien Sie immer bereit, Ihre Annahmen in Frage zu stellen. Wir wissen nur, was wir wissen, und wir wissen noch nicht alles und werden es auch nie tun. Lassen Sie diese Weisheit als Warnung für Ihre stärksten Rezepte dienen.


Dann ist da noch der erledigende Teil. In jedem Leben hofft man etwas Wichtiges zu wissen und dann geeignete Maßnahmen zu ergreifen. Vorsicht ist genauso vorsichtig, und wenn man sich um das Leben anderer kümmert, ist Ernsthaftigkeit erforderlich. Mit dieser Perspektive als Grundlage und dem Verständnis der Informationstechnologie (IT) werfen wir einen Blick auf die Einführung von HealthCare.gov, dem vielbeschriebenen Flaggschiff des Affordable Care Act, auch bekannt als "Obamacare".

Lebenserhaltung

Wie stumpf kann ich sein? HealthCare.gov war bei der Ankunft tot. Die kollektive Transparenz besagt nun, dass sich alle sechs Personen am ersten Tag, dem 1. Oktober, angemeldet haben. Sechs. Nur 32.994 unterschritten das tägliche Ziel von 33.000. Und während "Kapazitäts" -Probleme als rückständige Auszeichnung für die Nachfrage angepriesen wurden, wusste jeder, der sich mit Webdynamik auskennt, es besser.


"Dies ist kein ungelöstes Problem", bemerkt Dr. Robin Bloor, Datenwissenschaftler und Mitbegründer der The Bloor Group. "Holland hat so einen Austausch."


Tatsächlich haben die Niederländer seit zwei Jahrzehnten die Nase vorn und viele Lektionen gelernt. Die Schweizer haben auch einige Erfahrungen, und natürlich hat Massachusetts MAHealthConnector.org, sogenannte "RomneyCare".


Bloor sagte weiter, dass 40 Jahre IT-Erfahrung bewiesen haben, dass große Projekte immer ein großes Risiko bergen.


"Machen Sie ein großes Projekt, hohes Risiko, hohes Risiko des Scheiterns. Dreieinhalb Jahre zu haben, klingt wie in einem modernen Tag, das wäre genug, aber hier ist ein Projekt mit hohem Risiko und es hat sich alles als schlecht herausgestellt, "Sagte Bloor.


In Bezug auf die Art und Weise, wie Integrationstests für HealthCare.gov durchgeführt wurden, war er äußerst ehrlich.


"Das Letzte, was mich fast zum Lachen gebracht hätte, sind keine Integrationstests bis zwei Wochen bevor Sie live gehen - und das ist nur so, wie könnten Sie das jemals mit so etwas machen? Wie könnten Sie?" Sagte Bloor.


Dr. Geoffrey Malafsky von Phasic Systems Inc., ein erfahrener Bundesunternehmer und Datenwissenschaftler, teilte diese Sichtweise mit. Er gab kürzlich eine einstündige, detaillierte Bewertung der Einführung von HeathCare.gov und äußerte sich sowohl zu den strategischen als auch zu den taktischen Entscheidungen . Er deutet vor allem auf das Erfassungsprotokoll der Bundesregierung.


"Eine der kritischen Schwachstellen, die insbesondere bei staatlichen IT-Projekten auftritt, ist die veraltete, archaische Vorstellung, dass Sie die gesamte erforderliche Geschäftslogik mit einem linearen Anforderungsprozess artikulieren können. Dies funktioniert grundsätzlich nicht mit großen IT-Systemen", sagte er.


Sein Punkt ist, dass große IT-Systeme selbst die klügsten Planer überraschen werden. Sie wissen einfach nie, woher Probleme kommen, wo Sie zusätzlichen Support benötigen oder welche Art von Fehlerbehebung Sie vornehmen müssen. Daher ist es eine schlechte Idee, den Entwurfsprozess einzuschränken, indem Sie die Projektingenieure dazu zwingen, alles zu antizipieren Sie werden im Voraus brauchen.


Erschwerend kommt hinzu, sagt Malafsky, dass die Beschaffungsbeamten der Bundesregierung aufgrund der enormen Geldsummen, die sie kontrollieren, inzwischen so mächtig geworden sind, dass sie im Wesentlichen die Kontrolle darüber haben, wie große IT-Projekte voranschreiten. Dies versetzt Abteilungsbeamte in die Rolle eines Supplikanten und fügt ein Risikofaktor in ein entscheidendes Verfahren ein, das im Mittelpunkt jeder bedeutenden IT-Initiative steht: die Auswahl der richtigen Tools, Technologien und Auftragnehmer.


"Die Leute, die mit dieser Aussage am lautesten nicht einverstanden sind, werden Akquisitionsprofis genannt, und ich ermutige sie, zu mir nach Hause zu kommen, und wir werden uns zusammensetzen und darüber diskutieren, weil ich viele empirische Beweise dafür habe", sagte Malafsky sagte.

Website-Strategie

Eine große Frage ist, warum die Regierung eine so umfassende Architektur für diese Website angenommen hat.


"Wenn das übergeordnete Regierungsprogramm so eingerichtet ist, dass die Versicherungsunternehmen den Kunden tatsächlich besitzen, nachdem sie eine Zusage erhalten haben, warum dann nicht einfach den Datenverkehr auf den vorhandenen Kanal für die Interaktion mit Kunden, über den die Versicherungsunternehmen bereits verfügen, verlagern? Ja, vielleicht müssen ihre eigenen erweitern, aber das wäre ein triftiger Geschäftsgrund, weil sie jetzt neue Kunden gewinnen werden ", sagte Malafsky.


Der weltberühmte (und mittlerweile etwas berüchtigte) Sicherheitssoftware-Pionier John McAfee äußerte sich kürzlich ebenfalls zu dieser Strategie und machte einige kontroverse Bemerkungen zur "Neil Cavuto Show" in Fox News:


"Oh, es ist wirklich schlimm", sagte McAfee. "Jemand hat einen schwerwiegenden Fehler gemacht, nicht beim Entwerfen des Programms, sondern beim einfachen Implementieren des Web-Aspekts. Ich meine, zum Beispiel, jeder kann eine Webseite erstellen und behaupten, ein Broker für dieses System zu sein … jeder Hacker kann eine Wenn Sie eine Website einrichten, sehen sie äußerst wettbewerbsfähig aus, und aufgrund der Art des Systems - und schließlich handelt es sich hierbei um Gesundheitsfürsorge - können sie Ihnen die intimsten Fragen stellen, und Sie werden sie frei beantworten. "


In Bezug auf die Webarchitektur selbst weist Malafsky auf die offensichtliche Tatsache hin, dass das Internet nicht für die Ausführung komplexer Anwendungen ausgelegt ist. Das war die Aufgabe des Großrechners in den Tagen, als das Web noch in den Kinderschuhen steckte. Der Entwurfspunkt für das Internet war vielmehr der einfache Informationsaustausch über einzelne Seiten, die über ein weites Computernetz verteilt sind. Beim Systemdesign ist das Ziel, etwas zu erstellen, das funktioniert. Komplexität um ihrer selbst willen einzubeziehen, ist schlecht beraten, geradezu sakrilegiert und fast immer ein Rezept für eine Katastrophe.


Die Washington Post hat in einer eigenen Untersuchung, was mit HealthCare.gov schief gelaufen ist, eine mittlerweile berühmte Grafik veröffentlicht, die die verschiedenen Herausforderungen der Website darstellt. Die Sprache, die das Papier zur Beschreibung der Site verwendet, ist tatsächlich ziemlich aufschlussreich, besonders wenn man bedenkt, dass dies die etablierte Zeitung von Washington, DC, dem Epizentrum der US-Bundesregierung, ist:


HealthCare.gov wurde von 55 Vertragspartnern entwickelt und ist eine der komplexesten Softwarekomponenten, die jemals für die Bundesregierung entwickelt wurden. Es kommuniziert in Echtzeit mit mindestens 112 verschiedenen Computersystemen im ganzen Land. In den ersten 10 Tagen wurden nach Angaben der Obama-Administration 14, 6 Millionen Besucher gezählt.


Quelle: Die Washington Post


Definitionsgemäß muss es der Fall sein, dass die Software tatsächlich funktioniert, damit jemand behaupten kann, dass er über eine Software verfügt. Andernfalls verfügen Sie über eine Codekompilierung, die noch keine Software darstellt. Abgesehen davon, notieren Sie sich die aufgelisteten Nummern, insbesondere den Teil über die Kommunikation "in Echtzeit" mit 112 verschiedenen Computersystemen im ganzen Land. Dies ist ein perfektes Beispiel für die Verherrlichung der Komplexität um ihrer selbst willen.


"Wir wissen, dass eine andere Möglichkeit darin besteht, ein einfaches, sehr einfaches Web-Brokering-System zu schaffen, das nur durch sehr einfachen App-Server-Code und noch einfacheres clientseitiges Javascript eine sehr angenehme Schnittstelle schafft, die gerollte Daten für Menschen erzeugt ", Sagte Malafsky. "Hier ist, was Sie tun können: Schritt für Schritt, Schritt für Schritt. Dann kann jede Aktion, die auftritt, am Auswahlpunkt ausgeführt und an jemanden gesendet werden, der das Programm tatsächlich besitzen wird." Natürlich bezieht sich "jemand" auf die Versicherungsunternehmen, denen die Policen sowieso gehören.

Die Grafik Grafik

Systementwickler auf der ganzen Welt müssen sich zusammengekauert haben, als sie diese Grafik gesehen haben. Werfen wir einen Blick auf die verschiedenen beschriebenen Schritte und insbesondere auf die schwerwiegenden Probleme, die bei einer so ehrgeizigen Architektur auftreten. In erster Linie betrachten wir die Anzahl der potenziellen Transaktionen, die bisher fehlgeschlagen sind, die meisten davon aufgrund von Software-Zeitüberschreitungen - Fälle, in denen ein Teil des Transaktionsprozesses die erforderlichen Daten nicht innerhalb eines akzeptablen Zeitraums erhält.


"Jede einzelne Software in dieser Grafik hatte ihre eigenen Timeouts, und es ist nicht einmal ein Timeout. Es kann mehr sein", sagte Malafsy. "Das Ablaufen einer dieser Optionen führt zum Abbruch der gesamten Transaktion. Einige davon sind einfach einzurichten und zu überwachen, z. B. Protokolldateien. Das sind Zeitüberschreitungen auf dem Webserver und dem App-Server. Einige sind undurchsichtiger. Das haben Sie." Datenbanken mit Parallelität und Triggern, aber mehreren Interaktionen. Wenn Sie sich wirklich eingehend mit der Funktionsweise von Datenbanken befassen, ist dies kein schöner Anblick. " (Lernen Sie in unserem Datenbank-Tutorial die Grundlagen der Funktionsweise von Datenbanken kennen.)


"Die Datenbankserver sagen gerne:" Wir halten alles in Ordnung. " Nicht wirklich ", sagte Malafsky. Die einzige Möglichkeit, die Leistung zu steigern und sie wirklich zu verwalten, besteht darin, dass auf dem Speicher eine Reihe von mit Zeitstempel versehenen Dateien erstellt wird, die dauerhaft gespeichert werden und nicht zu einer zusammengefasst werden Ein umfassender, genauer Datensatz, der für jeden jederzeit verfügbar ist, da dies zu lange dauert. Dies würde die Transaktionslatenz verkürzen. Sie müssen diese Details überprüfen und dann über eine Verwaltungsschnittstelle aufrollen Namen wie Auslöser und Nebenläufigkeit - aber das bedeutet im Grunde, dass es eine Menge Zeit braucht, um die Daten abzurufen und zu aktualisieren. Wenn ich es nicht tun kann, bevor eine andere Anfrage eingeht, sage ich Ihnen einfach: Vergiss es. Ich bin geschäftlich geschlossen. '"

  1. "Die Vordertür"

    Die Grafik der Washington Post enthält eine sehr merkwürdige Information direkt am oberen Rand ihres ersten "Problem" -Bereichs. Dort heißt es, dass "die Obama-Administration Ende September beschlossen hat, ein Feature, nach dem die Leute hätten suchen können, vorerst auszuschließen Krankenversicherungen, ohne zuerst ein Online-Konto zu erstellen. "


    Beeindruckend. Ist das wirklich ein "Merkmal", das ausgeschlossen wurde? Es handelt sich um einen grundlegenden Site-Flow. Ursprünglich war geplant, die Leute herumtollen zu lassen und dann zum richtigen Zeitpunkt ein Konto zu registrieren.


    Einige Kritiker haben spekuliert, dass diese kurzfristige Änderung (an sich ein unglaublich riskanter Schritt bei einem so großen Projekt) zeigt, dass die Verwaltung wusste, dass die Website in den letzten Wochen vor dem Start am 1. Oktober nicht gut funktioniert hat . Stattdessen wurde die Idee geboren, alle Informationen derjenigen zu erfassen, die eine Versicherung benötigten, so dass Marketinganstrengungen irgendwann durchgeführt werden konnten, sobald die Site funktionsfähig war.


    Unter dem Gesichtspunkt der Benutzerfreundlichkeit und Kapazität stellte dieser kurzfristige Schritt eine enorme Belastung für die Datenbank dar, auf der die Site basiert. Dies erklärt alle Anekdoten von Personen, die sich nicht registrieren können oder gezwungen sind, ihre Passwörter zu ändern. Und seien wir ehrlich hier. Gibt es ein Problem, das im gesamten World Wide Web gründlicher gelöst wurde als das Einrichten eines Benutzerkontos? Yahoo, Google, Microsoft, YouTube, Twitter und LinkedIn - sogar die Strickklasse Ihrer Großmutter - haben heutzutage ihre eigene dynamische Anmeldeform mit eingebauten Funktionen zum Abbestellen, Weiterleiten und anderen grundlegenden Funktionen.

  2. Anmeldung

    Als es Zeit wurde, sich bei HealthCare.gov zu registrieren, sagten die Vertragspartner: "Die Kommunikation zwischen einigen dieser Systeme funktionierte nicht richtig, was bedeutete, dass viele Benutzer kein Konto erfolgreich erstellen konnten."


    Was? Welche Systeme? Es handelt sich um eine Kundendatenbank! Die "Systeme" wären dann der Web-Client und die Kundendatenbank. Welche anderen Systeme waren beteiligt? Diese besondere "Erklärung" macht keinen Sinn.

  3. Identitätsnachweis

    Als nächstes Identitätsnachweis. Für diesen Schritt sind keine Probleme aufgeführt, was auch merkwürdig ist. Experian wird als Drittanbieter-Agent aufgeführt, der die Identität einer Person "überprüft". Zweifellos ist die Auflösung der Identität ein ernstes Problem, das angegangen werden muss. Die meisten Versicherungsunternehmen verwenden Ihre Sozialversicherungsnummer sowie Drittanbieter wie Experian. Gibt es wirklich keine Probleme mit diesem Schritt?


    Aus zahlreichen Anekdoten, die anhand der vorgelegten Dokumentation überprüft wurden, wissen wir mit Sicherheit, dass HealthCare.gov auf jeden Fall von einer Vielzahl vertraulicher Informationen betroffen ist. Malafsky weist darauf hin, dass die Datenqualitätsprobleme weitaus schwerwiegender sind als die Kapazitätsprobleme. (Und Bloor merkt an, dass Kapazitätsprobleme, wenn sie tatsächlich die Probleme waren, in Tagen und nicht in Wochen hätten gelöst werden müssen. Sie können Hardware hinzufügen, virtualisieren und eine beliebige Anzahl von Dingen für Kapazitätsprobleme ausführen.)


    Nein, die Datenqualitätsprobleme sind wirklich gefährlich. Und der beunruhigendste Aspekt ist die Art der Datenqualitätsprobleme, die aufgetreten sind. Es gibt Geschichten von Personen, die sich anmelden und dann vertrauliche Zulassungsdokumente von anderen Registranten erhalten! Dies riecht nach einem absolut schrecklichen Design unter der Decke. Verwenden sie nicht für jede Person einen universellen Identifikationscode?


    "Der kluge Schachzug besteht darin, eine universell eindeutige Kennung (UUID) zu erstellen, verschlüsselte Werte (Note Plural) der möglicherweise eindeutigen Informationen (SSN, DOB, Alter, Biometrie) zu speichern und diese dann auf Beweise für eine eindeutige Persönlichkeit zu untersuchen." Malafsky sagte.


    Dass jemand die vertraulichen Dokumente einer anderen Person erhalten könnte, ist unbeschreiblich schlecht und zeigt einige sehr schwerwiegende Kartierungsprobleme tief im Bauch des Tieres.

  4. Teilnahmeberechtigung

    OK Leute. Hier wird das Leben interessant! Wenn Ihre Transaktion zu diesem Zeitpunkt noch nicht abgelaufen war, war dies bei diesem Schritt mit ziemlicher Sicherheit der Fall. Laut der Grafik der Washington Post "muss das System die Berechtigung zur finanziellen Unterstützung bestimmen, indem die persönlichen Daten des Verbrauchers an einen Daten-Hub gesendet werden, der Dutzende von Bundes- und Landesbehörden unter Vertrag nimmt."


    Der Versuch, eine Transaktion über drei oder vier Schlüsselsysteme auszuführen, ist eine echte Herausforderung. Der Versuch, "Dutzende" von staatlichen und bundesstaatlichen Behörden "in Echtzeit" zu treffen, ist aus den Charts verschwunden und völlig unnötig. Malafsky nahm nur einen Interaktionspunkt, um seinen Fall zu machen:


    "Einer der offensichtlichen Gründe ist, dass die Finanzdaten pro Person abgefragt werden, um festzustellen, ob sie eine Subvention verdienen oder welchen Preis sie haben. Wir begeben uns zum IRS. Jetzt haben wir da drüben einen Link, aber dieser Link ist aktiv Das heißt, wenn der Benutzer dort sitzt und auf seinen Computerbildschirm wartet, muss eine Verbindung zu den IRS-Systemen hergestellt werden. In einer perfekten Welt geschieht diese Verbindung, die Computer sprechen, ich erhalte mein Ergebnis und komme zurück.


    "Was ist in der realen Welt? Was ist, wenn die IRS-Systeme überlastet sind? Was ist, wenn sie voll ausgelastet sind? Was ist, wenn sie möglicherweise Wartungsarbeiten ausführen? Was ist mit einem Netzwerk zwischen dem Netzwerkbetriebszentrum der Einstiegsebene Webseite, die der Kunde für das IRS-Center sieht? Vielleicht gibt es dort einige Probleme. Vielleicht gibt es einen Virus. Vielleicht läuft ein Trojanisches Pferd herum und die Telekommunikation hat die Dinge heruntergefahren, um dieses Problem zu lösen. Das wird die Transaktion von Anfang an beenden Sicht des Benutzers. Das ist nur einer von vielen solcher Punkte in dieser Architektur ", sagte Malafsky.


    Sein Punkt ist, dass jedes einzelne dieser Systeme - wie diese Webarchitektur für HealthCare.gov entworfen wurde - eine potenzielle Achillesferse ist. Das ist eine No-Win-Situation. Auch aus Workflow-Sicht ist dies nicht erforderlich. Es gibt eine beliebige Anzahl von Punkten auf dem Weg, an denen der Workflow durch zeitnahe Datenmarts, zeitnahe Datenmarts und sogar menschliche Eingriffe zur Behebung der Hauptfehlerpunkte der Automatisierung erweitert werden kann.


    Der große strategische Fehler bestand daher darin, eine so unglaublich komplexe Website zu erstellen.

  5. Nach einem Plan einkaufen

    Denken Sie daran: Dies sollte der ursprüngliche Site-Flow sein. Web-Surfer würden zuerst nach einer Versicherung suchen. Wenn sie dann etwas Interessantes fanden, konnten sie sich für ein Konto registrieren, nach Subventionen suchen und letztendlich einen Plan kaufen.


    Der Grafik zufolge wird "einigen Personen mit niedrigem Einkommen mitgeteilt, dass sie keinen Anspruch auf Subventionen haben oder sich nicht für Medicaid qualifizieren, obwohl sie dies sollten". Hier stellt sich die Frage: Warum wird dieses Problem unter Schritt 5 anstelle von Schritt 4 aufgeführt? Dies ist ein Problem, das damit zusammenhängt, dass der vorherige Schritt nicht angemessen berechnet und daher in Schritt 5 nicht korrekt berücksichtigt wurde.

  6. Versicherungsübersetzung

    In unserer Welt nennen wir diesen Teil ETL. Es ist so ein Problem gelöst wie die Registrierung auf der Website.

  7. Einschreibung in die Versicherung

    Der Heilige Gral! Aber warten Sie, laut HealthCare.govs Auftragnehmern gibt es einen letzten "Fehler": "Die Berichte, die als 834s bekannt sind, sind manchmal verwirrend und doppelt, was es für Versicherungsunternehmen schwierig macht, zu wissen, wer ihre neuen Kunden wirklich sind."


    Nehmen wir uns einen Moment Zeit zum Schweigen, um diesen zu würdigen …


    Tatsächlich muss eine Versicherungsgesellschaft also wissen, wen sie wirklich versichert. Das ist eine ziemlich kritische Komponente. Das gleiche gilt für einen Notarzt, der weiß, welche Person er behandeln soll, oder für einen Arzt, der weiß, in wessen Brust ein Herz verpflanzt werden soll. In der Medienbranche könnten wir dieses kleine Lied als einen Fall bezeichnen, in dem es unseren Auftragnehmern recht gut gelingt, die Lede zu begraben.

  8. Berichterstattung

    Last but not least heißt es in der Grafik, dass "Regierungsbeamte sagen, Käufer hätten mehr als 700.000 Krankenversicherungsanträge eingereicht. Einige von ihnen sind über HealthCare.gov und andere über staatliche Marktplätze eingegangen. Aber Beamte lehnen es ab, anzugeben, wie viele Personen sich in a eingeschrieben haben planen."

Manuelle Übersteuerung

Der vielleicht schärfste Curveball, der erst kürzlich in den Mix geworfen wurde, war der Versuch, Papieranwendungen aufgrund der funktionalen Herausforderungen der Site zu fördern. Leider müssen auch die Papierformulare bei der nicht funktionierenden Site eingereicht werden. Per Definition ist das keine manuelle Übersteuerung. Per Definition muss eine manuelle Übersteuerung es jemandem oder etwas ermöglichen, das automatisierte System manuell zu übersteuern.


Und jetzt, zum Zeitpunkt der Veröffentlichung dieses Artikels, hören wir, dass sich die Verwaltung beim Relaunch von HealthCare.gov stärker auf Versicherungsunternehmen verlässt, um die Probleme zu beheben. Ratet mal, was das bedeutet - ich wette, ihr kriegt Donuts in Dollar (ja, früher war es umgekehrt). Was gerade passiert, ist ein weitverbreitetes Rip-and-Replace. Insbesondere haben Programmierer und Ingenieure wahrscheinlich viele der "Echtzeitverbindungen" und andere sehr teure Middleware herausgerissen, auf die sich die Redakteure der Washington Post so gefreut haben. Ersetzen Sie all diesen komplexen Code durch viel einfachere Verbindungen mit höherer Latenz, die von einer Reihe von Data Marts gespeist werden, die über eine Batch-Umgebung mit den verschiedenen staatlichen und föderalen Systemen verbunden sind.


Mit anderen Worten, die Art von Lösung, die Malafsky, Bloor und McAfee vorschlagen, ist, wohin wir gehen. Und all der schicke Spaghetti-Code, den diese Bundesunternehmer in den letzten dreieinhalb Jahren für den Bau einer halben Milliarde Dollar ausgegeben haben? In den Behälter für scharfe Gegenstände.

Vergrabenes Blei

Und noch eine letzte Bemerkung: Laut Aussage vor dem Kongress von Henry Chao, dem stellvertretenden Informationsbeauftragten der Zentren für Medicare und Medicaid Services, das Zahlungssystem, das die Versicherungsunternehmen mit all diesen Bundeszuschüssen erstatten wird? Es wurde noch nicht gebaut! Das bedeutet, dass dies möglicherweise die erste große E-Commerce-Website ist, die überhaupt ohne ein funktionierendes Mittel für den Geldtransfer gestartet wurde.
Warum der erste Rollout von healthcare.gov abstürzte, ist eine architektonische Beurteilung