Disappointedly, the U.S. Dept of Health and Human Services did not implement the prototype architecture I developed for them, while on detail to MITRE. Instead, they opted for a Canadian firm's approach. (One wonders, why does the U.S. need to go "off-shore" for IT architecture when we have such talent widely available here?) CGI Group Inc, the Canadian contractor that built HealthCare.gov, is "declining to comment at this time," said spokeswoman Linda Odorisio. According to one analyst,
One possible cause of the problems is that hitting "apply" on HealthCare.gov causes 92 separate files, plug-ins and other mammoth swarms of data to stream between the user's computer and the servers powering the government website, said Matthew Hancock, an independent expert in website design. He was able to track the files being requested through a feature in the Firefox browser.
Of the 92 he found, 56 were JavaScript files, including plug-ins that make it easier for code to work on multiple browsers (such as Microsoft Corp's Internet Explorer and Google Inc's Chrome) and let users upload files to HealthCare.gov. It is not clear why the upload function was included.
Hancock's analysis suggested that the security questions were coming from a separate server and that better system architecture would have cached the questions on the main HealthCare.gov server. In the architecture I developed over a six-month engagement, the front-end web site was streamlined with minimal Javascript, and was served up via a WebObjects application handling the back-end connectivity to various data services.
I had applied my expertise in service oriented architecture — particularly how to apply SOA for cloud efforts — to come up with a prototype that could support 10's of thousands of concurrent users. I leveraged my expertise to demonstrate:
• How SOA 'automatically' improves end-to-end visibility and responsiveness.
• How to massively scale SOA in the cloud for extreme high-traffic, high-bandwidth applications.
• How current on-premises SOA can foster cloud architectures and deployments.
• How WebObjects frameworks will make web services and web-based user interface efforts more productive.
• How 'intelligent ESBs' help the cloud solution react in real-time.
• What SOA 'best practices' today offer the best ways to improve a cloud strategy, at little cost.
SLASHDOT:
ReplyDelete"In theory, the federal government's Health Insurance Marketplace was supposed to make things easy for anyone in the market for health insurance. But fourteen days after the Website made its debut, the online initiative—an integral part of the Obama administration's Affordable Care Act—has metastasized into a disaster. Despite costing $400 million (so far) and employing an army of experienced IT contractors (such as Booz Allen Hamilton and CGI Group), the Website is prone to glitches and frequent crashes, frustrating many of those seeking to sign up for a health-insurance policy. Unless you're the head of a major federal agency or a huge company launching an online initiative targeted at millions of users, it's unlikely you'll be the one responsible for a project (and problems) on the scale of the Health Insurance Marketplace. Nonetheless, the debacle offers some handy lessons in project management for Websites and portals of any size: know your IT specifications (federal contractors reportedly didn't receive theirs until a few months ago), choose management capable of recognizing the problems that arise (management of Healthcare.gov was entrusted to the Medicare and Medicaid agency, which didn't have the technical chops), roll out small if possible, and test, test, test. The Health Insurance Marketplace fiasco speaks to an unfortunate truth about Web development: even when an entity (whether public or private, corporation or federal government) has keen minds and millions of dollars at its disposal, forgetting or mishandling the basics of successful Web construction can lead to embarrassing problems."
Read more: http://slashdot.org/topic/bi/lessons-from-the-feds-healthcare-gov-fiasco/
Seriously, Aquilent was the company doing the web work? Sheesh.
ReplyDelete"The White House press office, the Centers for Medicare & Medicaid services — which is overseeing the building of the site — and Aquilent, one of the main contractors, did not respond to interview requests"
http://www.theverge.com/2013/10/14/4838100/why-did-healthcare-govs-source-code-mysteriously-vanish-from-view